On 16.06.2006, at 10:24 Uhr, Paul Lynch wrote:
There is only an artificial distinction between "Dynamic Element"
and WOComponent. All dynamic elements are view classes, and they
are also WOComponent subclasses. So yes, WOComponent fills both
roles.
Nope. WODynamicElement and WOComponent inherit both from WOElement.
I tend to use page level WOComponent subclasses as "controllers" and
build views as an addition to these "page level" components. So I
have mainly page level objects that control the workflow, the
navigation, validation and so on and I have "drop in" components that
take some information as bindings but nevertheless do only display
things.
So, I mostly have a strict distinction of controllers and views with
the exception that both inherit from WOComponent (or sometimes views
inherit from WOElement). But I see "views" a bit more complex - they
often have java code to build paths to images, css-files, css-classes
and so on. But they never have any "high level" controller logic.
That works very well for me now. But I have to say: I should have
made this distinction much earlier. Currently I have to work on my
first larger scale WO app and everyday I could bite in the table when
I see what I have done a couple of years ago. Not enough inheritance
[1], not enough abstraction [2] and not enough splitting in small
pieces[3]. But I think this is normal ...
cug
[1] to [3]
Today I always try to follow my own rules when doing WebObjects
programming:
Rule 0 - don't fight the tool. Rule 0b - dont fight the tool! Rule 0c
- don't write lots of code.
Rule 1 - Make a common subclass for your page level components.
Rule 2 - Make subclasses for common tasks (list, edit, inspect,
search ... - "controllers") and build subclasses as the "real pages
to display" ("views").
Rule 3 - Use Direct To Web and/or learn from it.
Rule 4 - Use key value coding. YES, KVC rules!
Rule 5 - Use ERXThreadStorage instead of the session to have not so
much dependencies there.
Rule 6 - DRY. Whenever you do copy&paste --> Undo it! Make a small
component, a helper class, a common base class, whatever. Don't do
copy&paste. Never.
Rule 7 - don't build too much frameworks. Collect useful things in
one or two frameworks - you will add another dozen to have external
functionality (db connection, lucene integration, ERX... and so on).
Rule 8 - A page cannot have too much subcomponents ... ;-)
After playing around with Ruby I also tend to use "conventions" for
common things. It works out very well if it is well-documented.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [email protected]
