Hi David!
Ok... so for example, how would you create the addressesDisplayGroup?
I used to do this kind of stuff loong ago when I used to write EOF/
AppKit applications. But I was just reading the documentation and got
a bit confusing, specially since I don't see any examples.
On Mar 17, 2009, at 6:28 PM, David Holt wrote:
On 17-Mar-09, at 3:11 PM, David Holt wrote:
Hola Ricardo!
On 17-Mar-09, at 2:10 PM, Ricardo J. Parada wrote:
I noticed that the component editor lets you edit the .woo file.
You can add display groups there and a detail display group. Then
it has a Source view that lets you see the .woo's contents in
plist format.
I never use that but I'm wondering if I'm missing anything. Who
reads the .woo file and when are those display groups created?
From the wiki entry:
* The .woo file is optional if all the information required to
initialize the display group is contained in the Java file. This is
the key to being able to create a display group programatically and
leave the automatic initialization behind. By doing this, you will
free yourself from several limitations that an automatically
initialized WODisplayGroup is forcing on you behind the scenes. The
real aim of this document is to show you where the limitations are,
and how you can get around them by initializing the WODisplayGroup
yourself in the .java file. This will allow you to configure your
display groups in a much more powerful and flexible manner for use
in your components. The drawback, as with everything in WebObjects,
is that as you get further away from the "default" implementation,
your need to understand what you are doing increases significantly.
With the Apple tools, dragging an EO from EOModeler to your
component would automatically generate a corresponding displayGroup
in the .woo. Behind the scenes, the displayGroup would be
initialized (i.e. not in code) when your page loads. The same
functionality still exists that will generate any displayGroup
specified in the .woo file. I have since switched to creating my
displayGroups in code since it gives you much more power and
flexibility for setting the fetches, sorts, fetch limits and what
is displayed, etc. I have written up my experiences (briefly) on
the wiki:
http://wiki.objectstyle.org/confluence/display/WO/Web+Applications-Development-WODisplayGroup
Which now reminds me that I never did put the "doing it in code"
version up on the wiki. I'll try to get to it soon.
Also, I have a master object (i.e. Parent) and I'm interested in
creating a display group that gets its object from the parent's
children relationship.
The master object is already in memory, no need to fetch it. Can
this be used to create my childrenDisplayGroup?
Sure, lets say you have a person with many addresses, you can do
something like this in code:
person = (Person) peopleDisplayGroup.selectedObject();
addressesDisplayGroup.setMasterObject(person);
I should probably add reference to the docs: (addressesDisplayGroup
needs to be a detail display group set to fetch on load for the
above code to work).
setMasterObject
public void setMasterObject(Object masterObject)
Changes the master object to masterObject for detail display groups
and then performs a fetch if the display group is set to fetch on
load. The master object owns the objects controlled by this display
group.
Before this method is used, you should use the setDetailKey to set
the key to this relationship. A detail display group is typically
created by dragging a to-Many relationship from EOModeler to an open
component in WebObjects Builder. Doing so sets the master object and
detail key, so typically you don't have to use this method.
If the WODisplayGroup is not a detail display group, this method has
no effect.
David
Thanks,
Ricardo
_______________________________________________
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/programmingosx%40mac.com
This email sent to [email protected]
_______________________________________________
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/programmingosx%40mac.com
This email sent to [email protected]
_______________________________________________
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]
