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 (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to archive@mail-archive.com
