Re: Entity inheritance and sorting: Bug or my fault?
Re: Entity inheritance and sorting: Bug or my fault?
- Subject: Re: Entity inheritance and sorting: Bug or my fault?
- From: Ian Joyner <email@hidden>
- Date: Tue, 11 Jul 2006 11:39:25 +1000
OK, I think the original implication ("Entity inheritance") was that
your lists were actually DB entities defined in your EOModel, but now
it looks like they are WOComponents, so actually, your list
components are controller objects mirroring your model objects. So at
least that rules out problems in the EOModel design (I do too much
Java-client stuff, where this pops up) due to interdependent
inheritance hierarchies.
Ian
On 10/07/2006, at 6:34 PM, Guido Neitzer wrote:
On 10.07.2006, at 2:34 Uhr, Ian Joyner wrote:
I'm a bit uneasy about your design having as types CONTACT, USER,
LIST and then CONTACT_LIST and USER_LIST. This does not suggest
inheritance, ...
Let me explain that:
I have a situation where in most situations I want to see all types
of contacts in one list. A contact may be a company or a person. An
internal user is nothing else but a person with some additional
stuff (for login/password and a pretty complex rights management).
A ContactList is a component which can be used to display contacts
very generically. Each entity has a subcomponent for the "row level
display" and this is dynamically set by a WOSwitchComponent.
A UserList is nothing else but a subclass of ContactList with
completely different HTML.
So, the complete page could be like this:
<PageWrapper>
<MainNavigation />
<ComponentContent>
<Subnavigation />
<Some context sensitive stuff />
<ContactList />
</ComponentContent>
<Footer />
</PageWrapper>
where ContactList is a subclass of EmbeddedList. EmbeddedList is a
very generic component for displaying lists - I can use it directly
and configure it with some rules (which properties to display, some
stuff how to display the column headers, the columns itself and so
on - think of a customized D2W list component) or I can subclass it
to use its functions (sorting, fetching, limiting result sets,
paging, ... a lot of stuff I use in each and every list I show to
the user) and only use customized HTML.
So you can think of "EmbeddedList" as a controller component with a
generic but not often used integrated view and and all the other
lists just use the functionality, add some custom stuff and use
often very different HTML.
Example: I have components in the context sensitive stuff, that are
also based on EmbeddedList, and display e.g. "Recently seen
contacts" or "Recently changed activities" or whatever - they only
push a different set of qualifiers to EmbeddedList and use
different HTML. EmbeddedList decides whether to use a
ERXBatchingDisplayGroup, a standard display group, applies
SortOrderings, gives a generic method for inspecting objects and
more. Most of this stuff is configured by rules or by overriden
methods in the subclass.
This concept works VERY well for me at the moment, the whole
application works this way (with edit pages, search pages, ...).
Most of the stuff is based on KeyValueCoding, GenericRecords and
some rules to decide what page to use if an object is selected.
cug
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden