Re: Custom PopUp Problems
Re: Custom PopUp Problems
- Subject: Re: Custom PopUp Problems
- From: "Jerry W. Walker" <email@hidden>
- Date: Wed, 26 Apr 2006 17:40:39 -0400
Hi, Scott,
On Apr 26, 2006, at 4:58 PM, Scott Winn wrote:
First off, welcome to WebObjects!\
Thanks! Like I told Chuck. I feel like I am learning WebObjects
from the inside out.
Hi WOList,
I am relatively new to WebObjects (and Java for that matter).
I am trying to create a reusable component that is essentially a
WOPopUpButton with a custom fetch that generates the list
attribute. That part is working. When I put this component in a
page, it will be used to edit a relationship attribute of the
Object the page is displaying. I am not using
WOToOneRelationship because of the custom fetch logic.
I guess my first question is, why are you coupling a UI element
with your model? I would really like to hear more about the
custom fetch logic, and why it makes sense to have the rolled up
into a component.
Apparently Project Wonder has an ERXToOneRelationship with
EODataSource and Qualifier bindings, so it can't be that unusual.
Unfortunately, now is not a good time to see if I can get Wonder
working. For my part, I am pulling a subset of objects that have a
relationship to a particular user. User X sees objects 1, 2, and 3
in the pop-up : User Y sees objects 4, 5, and 6. 1, 2, 3, and 4,
5, 6 are all the same type of thing (so they are in the same
table). There is just different visibility depending on who the
User is.
I have the feeling that Ken Anderson gave you the right advice, but
that's still not completely obvious.
If the subset of objects that you are pulling are related to a
particular user, does your user object have a reciprocal to-many
relationship to those objects? If so, you don't need any explicit
fetch logic. Simply reference the array in the user representing that
set of objects and the magic of EOF will make it so (more
technically, it will fire the necessary faults to fetch those objects
for you). So if you have a user defined as follows:
myUser (instance variable in your WOComponent referencing the User)
...
foobars (NSArray variable of myUser for elements of type foobar
for all the foobars related TO THAT SPECIFIC USER)
selectedFoobar (instance variable of myUser for the foobar that
that user selected)
...
Then simply set up your WOPopUpButton bindings as follows:
list = myUser.foobars
item = aFoobar // this is an arbitrary iVar of type Foobar that
you set up as an index variable
selection = myUser.selectedFoobar
displayString = aFoobar.displayableValue
You don't have to do any explicit fetching and it just works, IF YOU
HAVE A TO-MANY RELATIONSHIP FROM USER TO FOOBAR.
If you don't, then see below...
WOPopUpButton handles all off the necessary selection logic if you
let it. The typical way to bind a pop-up list would be to bind
the 'list' attribute to either an NSArray in your component, or a
method that fetches the correct set of objects. You would bind
'item' to an instance variable that corresponds to a single item
in your array, and 'selection' to the relationship. As an
example, if you have a page that allows you to set the teacher
relationship of a student where the teachers are fetched with
custom logic, you could have java that looks like this:
public Teacher teacher;
public Student student;
private NSArray teachers;
public NSArray teachers() {
if (teachers == null) {
teachers = <ANY CUSTOM LOGIC YOU WANT>;
}
return teachers;
}
Assuming the Student EO has a to-one relationship called
'teacher', your bindings would be:
list = teachers
item = teacher
selection = student.teacher
displayString = teacher.fullName
When entering the page, the pop up would automatically be set to
the correct teacher for the student. When submitting the form it
should be on, whatever teacher was selected would now be connected
to the student's teacher relationship.
The problem I am having is that I want to make the Pop-Up a
reusable component. I don't want to have to include all of the
Fetch and Qualifier logic in every page component that needs this
pop-up. So I made the new WOComponent. It is a partial page. I
included the fetch logic, and the list, item, displayString,
noSelectionString, and selectedValue bindings necessary for the
WOPopUpButton. Then I inserted the Pop-Up component into a page
that does the editing.
At this point, I can run the app and the pop-up will appear on the
editing page with the correct list contents.
My problem is
1) I don't know how to tell the custom pop-up component what the
current object value to edit is (so it can get the
selected="selected" HTML in the option tag)
I suggest taking a look at the following:
http://www.vorlesungen.uni-osnabrueck.de/informatik/c00/Java-UML-
OS-InfC-00/VL4/DevGuide/ReuseTOC.html
I'm sure the same info can be found in a couple other pages, but
that's the first I identified when I Googled for "WebObjects
subcomponents bindings".
Use the information on that set of web pages to wire up your
components. By default, WO will synchronize the values between a
component and its subcomponents six times for each Request-Response
loop. This is not particularly efficient, but in many cases the
inefficiency won't hurt you at all. If it does, then see
WOComponent's methods:
public Object valueForBinding(String aBindingName)
2) I don't know how to get the user selected value out of my custom
component to the page component that is doing the editing.
public void setValueForBinding(Object aValue, String aBindingName)
This is only a problem because I'm trying to build a reusable
component. If I were using a regular WOPopUpButton I would just
bind my objects parameters to the correct pop-up bindings. But
since it is a custom component when I include it on my editing page
it doesn't have any bindings at all.
The two methods I referenced above may not have to be used. They are
typically used when you wish to manually control the synchronization
between the component and its subcomponent. This is true, for
instance, when you want to create stateless components or just reduce
the overhead of synchronization. However, I would suggest that you
wire up your subcomponent first and get it to work before you start
fooling with stateless subcomponents or manually synchronizing them.
And before you even add the complexity of the subcomponent, try
letting EOF do the work for you (if that applies).
HTH.
Regards,
Jerry
<snip>
...
--
__ Jerry W. Walker,
WebObjects Developer/Instructor for High Performance Industrial
Strength Internet Enabled Systems
email@hidden
203 278-4085 office
_______________________________________________
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