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/