ez Publish methodology

Friday 12 August 2005 2:27:04 am

I would like here to discuss about some methodologies and best practicies when creating an ez Publish site with lot of business logic.

I will begin with a (general?) question about the class model.

Let me first explain the purposes of the site we are creating.

The site will be a portal to <b>several</b> companies with own products, orders, promotions, events, job infos,... All this information will have an apropriate content class (Company, Product, Order, Promo, Event, ...)

Information will be reachable in different ways sometimes with lot of business logic. ex: A page that display the list of <i>users</i> having purchased <i>products</i> of a specified <i>company</i>.

I would like to have some comments about: When to create an (enhanced?) objectrelation attribute and when to create a child object using nodes ?

In my opinion, it should be much easier to create a logic in the placement of nodes than a template that will do a lot of complicated fetches !

Continuing with the example above, it is probably easier to have this structure:

-- Company One
 +-- Buyers
   +-- Person One
-- Company Two
 +-- Buyers
   +-- Person One
   +-- Person Three
-- Company Three
 +-- Buyers
   +-- Person Two
   +-- Person Three

And the day the <i>Person Two</i> buy a product of <i>Company One</i> an additional node on <i>Person Two</i> is created under <i>Company One/Buyers</i>.

This may be probably implemented by a workflow.

Now add some "categories of products" with the class <i>Category</i> that is general for all companies. How do I manage the relation between a category, a product, a buyer,... ?

What about displaying all products under a specific category ? Or all products of a company in a specific category ?

What about displaying all products (of every companies) that have been bought on the portal.

Following my opinion, will I have to create as much directories structure and workflows as "views" ?

In a OO model I will have some functions like:

Company {

Persons[] getBuyers() {
...
}

Persons[] getProductBuyers(Product p) {
...
}

}

What is your methodology to create such behaviors ?

Thanks for your help :)

Patrick ALLAERT
http://www.dixite.com/
http://users.pandora.be/patrick_allaert/

Tuesday 16 August 2005 7:51:55 am

Thanks for your suggestion Paul, I think object relation is effectively the right way to implement direct relation between two objects or when the <i>logic</i> is simple. But in my case (we have more than 60 classes) it is really time consuming to do so...

An order is <b>related</b> to a <i>customer</i> and made of several <i>order_detail</i>'s.
An <i>order_detail</i> is related to a <i>product</i>.
The <i>product</i> is under an object of type <i>company</i>.
And I am under a specific <i>company</i> (only one) because I am a responsible of it.

What I need to do here is: <b>Give me the list of persons that have bought something of my company!</b>

With standards <i>object relations</i> and parent/child relations I have to do this:

1. Retrieve the <i>company</i> (<b>C</b>) I belong to.
2. Retrieve the <i>products</i> (<b>P</b>) of <b>C</b>.
3. Retrieve the <i>order details</i> (<b>OD</b>) having a link with <b>P</b>'s.
4. Retrieve the <i>orders</i> (<b>O</b>) the <b>OD</b>'s belong to.
5. Retrieve the <i>persons</i> (buyer: <b>B</b>) linked with <b>O</b>'s.
6. <b>B</b> is the list I want...

In case I want some stats on <i>orders</i> I will have to repeat step 1 to 4.

In a OO language, I will have a strong <b>class model</b> and several methods like
a) <i>Company::getBuyers()</i>: return a list of persons having bought something of this company.
b) <i>Company::getProducts()</i>: return the list of product of this company.
c) <i>Product::getBuyers()</i>: return a list of persons having bought this product.
d) ...

Where method a) will be built using b) and c)

Still waiting for an eZ Publish OO guru... ;)

Patrick ALLAERT
http://www.dixite.com/
http://users.pandora.be/patrick_allaert/

Friday 19 August 2005 1:10:25 am

I don't think that creating a business logic (or API) behind classes is a <i>specific need</i>...
I think that for now they are still no <b>best practicies</b> for doing this! Of course when your are creating 3 -> 10 custom classes you may always use fetch's functions. But when you reach more than 60 classes, you just can't!

Maybe this approach may be used:
Creating a set of templates that do some <b>core business logic</b> and other templates for the presentation.

Example:

{include uri='api/company/getProducts.tpl'
         company_id=125
}
{* Looping through results *}
{section loop=$results}
  ...
{/section}

This way I don't worry if products and companies are linked with <b>object relations</b> or <b>parent/child relations</b>!

IMHO, this addresses the most disadvantage of eZ templates, business logic is far to often in the template!

Patrick ALLAERT
http://www.dixite.com/
http://users.pandora.be/patrick_allaert/