You will have to send the entire page I think. I certainly don't have
any trouble with stuff like this.
BTW1: You said that you are doing: selectedPhone =
displayGroup.selectedObject()
I wonder where you are doing this. If you do it in awake() then keep in
mind this will get called BEFORE anything else happens on the page...
so, even if you change something in the popup list, you will be just
resetting it right back to displayGroup.selectedObject() before
takeValuesFromRequest occurs. Better places to put an initialization
would be your constructor or init method (unless you run with zero
pageCache); OR into appendToResponse() before you call super.
BTW2: the Java and WO name convention for attributes and methods is
lowercase. Only Class names should be uppercase.
d
Michael Xenakis wrote:
>
> Well, we're almost there. Peter Adams, per your suggestion, I've sub'd
>'selectedValue' for 'selection' and each yields similar results. Also, Craig, per
>your previous mail, yes, it was a typo, and I had already figured out preventing the
>empty text fields by setting selectedPhone = displayGroup.selectedObject() prior to
>rendering the page. As selectedPhone is, in turn, bound to the [selection |
>selectedValue] attribute - I've been testing w/ one and the other - the text fields
>properly display the info for the displayGroup's selected object which is also
>represented in by the object in focus in the popup button.
>
> ...However... and this seems to be the final piece at present, when updateView is
>submitted, the currently selected item in the popup is _never_ propogated back to
>selectedPhone. It's as if the [selection | selectedValue] attribute is only working
>one way, i.e. into the popup.
>
> Does this make sense? Everyone I've spoken w/ here says the code looks right... and
>I agree. I can't find anything wrong - where wrong is defined by the doc.s usage,
>etc. Further the release notes have nothing on popups other than #2282335, which
>deals w/ incorrect generation of keypath properties, but I don't think that's related.
>
> <sadness>
> Continued thanks to all... I hope I haven't exhausted your suggestions yet.
> mx.
>
> Craig Miskell <[EMAIL PROTECTED]> wisely stated:
> > > Looking forward to a slap in the face when I learn how easy the solution is...
>any takers?
> > I'll take another crack :)
> > Just been pointed out to me by a colleague that you might be having
> > problems because your textfields are bound to attributes of
> > selectedPhone. If these are null when the form is submitted, then it's
> > very possible that selectedPhone will take these values back
> > (WOTextFields are 2-way). How to get around this I can't quite figure
> > out as I type, but this info should help you
> >
> > Craig Miskell
> > Programmer, Black Albatross, Otago University, NZ
> >
> Michael G Xenakis PLATINUM technology, inc
> [EMAIL PROTECTED] 800.365.7528 x43007
>
> "Anyone who isn't confused here doesn't really understand what's going on!"
> Michael G Xenakis PLATINUM technology, inc
> [EMAIL PROTECTED] 800.365.7528 x43007
>
> "Anyone who isn't confused here doesn't really understand what's going on!"
