Posted by Hilarion on 09/08/05 21:27

> entity -> rubric -> page [1]
> entity -> contents element (such as text or picture or text and picture...)

Why not something like that:

entity -> contents element -> rubric
entity -> contents element -> page

> entity -> product category
> entity -> product -> book
> entity -> product -> cd
> entity -> product -> postcard
> entity -> author
> ...
>
> The main properties of entity are id, parent, active/inactive and sort
> order. So for all kinds of common tasks - handle sort order,
> activate/deactivate display... - I have one method at entity level, and I
> can flexibly handle all kinds of 1:n relations at entity level by assigning
> the id value of one object to the parent value of another one, regardless of
> what type the objects are of.

Do you need such general way of referencing? If you do not know the nature
of referenced entities, then the reference is (almost) useless.

> So I can assign a page not only to a rubric (which is the natural container
> for pages), but also for example to an author.

To assign rubric as a part of page you should build collection "visually contains"
of content elements in content element class.


> Or assign a text element not only to a page (which is the natural container
> for text elements),

As above.


> but also to an author.

What for? If the text has an author, then make "author" property in content
element class (from which text element should probably be derived).


> Like that I can reduce the author data record to the very
> basic - name, picture, contact information... - and still freely add
> additional info where appropriate.

By the ways above you could also do it, but without mixing things.


> Of course n:m relations such as the product/author relation are handled
> separately.
>
> [1] I assume that the rubric -> page inheritance in my example (and the
> wrong book -> page example in my original posting) made the impression that
> I used inheritance for every kind of relations. Though it is true that a
> page is not a type of a rubric, this seemed useful to me as below a parent
> rubric there can be pages and sub-rubrics mixed. Thus specially the sort
> order handling and menu composition would be very complicated if pages and
> rubrics were handled separately.

Why do not do it on contents element level? This way many content elements
could have subelements. You could also make more levels of inheritance
by doing it like this:

entity -> contents element -> text element
entity -> contents element -> contents collector -> rubric
entity -> contents element -> contents collector -> page

And create "visually contains" collection of contents elements in contents
collector class and this way separate simple elements (which do not
contain other elements) from complex elements (like rubrics or pages).
The ordering mechanisms would appear in the collection (so on contents
collector class) and rendering mechanisms in contents element class.


> My original question was about how to include the methods needed for
> administration only in order to reduce server load at the front end.
> Actually entity inherited a class with lots of admin methods:
>
> common functions -> entity -> ...
>
> And also every class contains specialized admin functions; for example in
> the postcard class the method delete_postcard() will delete the postcard
> record and then call $this->delete_product(), which will delete the product
> record and call $this->delete_entity().
>
> So now I separated the admin methods into separate classes that are not
> inherited but only called when they are needed.

That should be a bit better. The administrative hierarchy could be
related to logical hierarchy (class responsible for persistance of rubric
class could inherit from class responsible for persistance of contents
collector class or it could contain reference to instance of such class).


Hilarion

[Back to original message]