Re: Why WOBuilder only displays EOModel attributes and not java properties
Re: Why WOBuilder only displays EOModel attributes and not java properties
- Subject: Re: Why WOBuilder only displays EOModel attributes and not java properties
- From: Art Isbell <email@hidden>
- Date: Fri, 25 Mar 2005 10:17:13 -1000
On Mar 24, 2005, at 11:05 AM, David Sargent wrote:
A few months back, WO Builder quit displaying the java class
attributes and only displayed the attributes of the table as they were
defined in EOModel.
How do I get it to display the attributes I have defined in the java
class also?
Does anyone have this working correctly with packages and frameworks?
I have a configuration very similar to yours with an eomodel in a
framework. All Java classes in this framework are in their own
package. The application project's Java classes are in a different
package. But I didn't notice that custom Java entity class properties
weren't being displayed in WOB although I just confirmed that this is
indeed true.
The reason that this has been a non-issue for me is because I've begun
using a strict Model-View-Controller separation. When I was an
OPENSTEP programmer, I found that maintaining this separation yielded
classes that were more reusable and the expected logic was concentrated
in the expected classes rather than being thrown into a large single
class or strewn about willy-nilly. The major result of this was moving
all business logic out of WOComponent subclasses (Controllers - WO but
no EOF dependencies) into Model classes (EOF but no WO dependencies).
So most of my WOComponent subclasses now have an associated Model
class. The Model classes associated with various WOComponents
frequently form an inheritance hierarchy thus sharing code and data.
Their is usually a top-level Model class whose data are shared among
other Model classes. This top-level Model class frequently contains
data that might have been in my Session object.
All bindings made in WOB are to WOComponent subclass properties.
These properties are typically those types that are bound to
WODynamicElements; e.g., String, NSTimestamp, NSArray, boolean, int,
etc. Any WOComponent properties that are data objects are declared
Object, not an EOCustomObject subclass. This allows me to separate the
WOComponents from their underlying implementations which was the
original thrust of my programming change. I formerly declared a number
of WOComponent properties to be EOCustomObject subclasses, but I
occasionally needed to include more information in these properties
such that making them NSDictionaries was more appropriate. This
required extensive changes in both my WOComponent code and WOB
bindings. By making these WOB properties the opaque Object type, all
implementation changes are now made in the Model class. I find this
approach to be much more satisfying.
In addition to binding only to WOComponent properties in WOB (i.e.,
I'm not following eomodel relationship paths shown in WOB which are no
longer shown anyway because none of my WOComponent properties are
EOCustomObjects), I'm following the advice in WO documentation not to
do much processing in WOComponent property setter and getter methods
because these methods are invoked multiple times during each
request-response cycle. Instead, I set and get the values of these
properties ideally only once during each request-response cycle in
awake(), takeValuesFromRequest(), invokeAction(), appendToResponse(),
and sleep() in addition to the getter and setter methods for the
variables bound to "item" keys in WORepetition, WOPopUpButton, and
their ilk. This reduces repetitive, unnecessary processing which
should result in a more responsive application. Doing so gives me much
more control over when properties are read and written. This added
control makes debugging much easier.
A negative consequence is more Java code. Much of it can be
automatically generated by WOB, but there's quite a bit of
communication between the WOComponent Controller class and its
underlying Model class which means writing more, but usually very
simple, Java code. E.g., the WOComponent doesn't know or care where
the data for each property lives; its associated Model class does all
of the EOF work to get and set property values. So if I want to store
the list for a popup button in an array rather than in a database
table, the WOComponent code and WOB bindings don't change; the only
changes are in the Model class.
So far, I'm quite happy with the changes although I don't get to take
advantage of following long relationship paths in WOB to make bindings.
But this WOB magic certainly must come at a performance cost that I'm
avoiding.
Aloha,
Art
_______________________________________________
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