|
|
Posted by Markus Ernst on 09/08/05 17:01
Jerry Stuckle wrote:
[...]
> But herein lies the problem. Inheritance is not applicable here. A
> text element is not a "type of" a page. Rather, a page "contains" one
> or more text elements.
>
> A biography is a "type of" a book, so it would be applicable to derive
> biography from book. The book also "has an" author, but the author is
> not a "type of" text element (or vice versa).
[...]
Thank you for your detailled and understandable example! If I understand
everything correctly, my problem is rather to make myself understandable (I
am not a native English speaker and not an educated IT professional either,
so I may have chosen the wrong words and also poor or too much simplified
examples). I did the following classes (each of which has a corresponding
MySQL table):
entity -> rubric -> page [1]
entity -> contents element (such as text or picture or text and picture...)
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.
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. Or assign a text element not
only to a page (which is the natural container for text elements), but also
to an author. 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.
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.
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.
Markus
Navigation:
[Reply to this message]
|