And, BTW, because having the server-side figure all this stuff out based on the meager flow of data possible from a HTTP Form submission is impossible (at least, once you add DHTML/Ajax to the picture) ... that's why 5.4 is looking to move away from FormFragment and a lot of the other stuff, to encourage client forms to submit JSON via Ajax and manage what goes to the server more directly, possibly using an MVC framework such as Bootstrap ... and that reasoning came out of our discussion at the training last year!
On Fri, Aug 3, 2012 at 10:42 AM, Howard Lewis Ship <hls...@gmail.com> wrote: > Looks odd; the Hidden field should render first, and write its > ComponentActions into the Form first, and should then be processed > first. > > Is your template really this simple, or is there more FormFragment, > etc., trickiness in there? That might affect the ordering if the > Hidden and the TextField were in different fragments (as each fragment > has its own t:formdata, and order of operations is not well defined). > > On Fri, Aug 3, 2012 at 1:27 AM, robert baker <les.baker1...@gmail.com> wrote: >> It occurred to me after I typed this that my assumptions were probably >> wrong, so please disregard. >> >> Apologies, >> Les Baker >> >> On Fri, Aug 3, 2012 at 4:04 AM, robert baker <les.baker1...@gmail.com> wrote: >>> Hi, >>> >>> I've stumbled on an interesting problem in trying to upgrade to 5.3.4 >>> that I am stumped. I am getting a "null term in property expression" >>> exception with some template markup that looks like the following: >>> >>> ... >>> <t:hidden t:id="primaryCodeKey" value="primaryCode" /> >>> <t:textfield t:id="primaryCode" value="primaryCode.code" /> >>> ... >>> >>> Just to be clear: the "primaryCode" object is wired up in the page >>> class and has a getCode method. There is also an appropriate >>> ValueEncoder contributed to the ValueEncoderSource service, it is >>> getting instantiated, and in its toValue() method, the encoder will >>> try to retrieve the object from a DAO and return a "blank object" >>> (non-null) otherwise. >>> >>> After doing some digging, the toValue method on the above ValueEncoder >>> doesn't get called (in time). Looking at the sources for the TextField >>> and Hidden components: >>> * The ComponentAction in the TextField that writes to its value >>> parameter during form submission gets queued up during the SetupRender >>> phase (see corelib/base/AbstractField.java line 164), however >>> * The ComponentAction in the Hidden component that restores its value >>> parameter gets queued up during BeginRender (see >>> corelib/components/Hidden.java line 121). Therefore, >>> * During form submission, the TextField's Action executes before the >>> Hidden's Action, but it should execute in the opposite order. >>> >>> Is this an unintended consequence, or something that I am missing? >>> This can be worked around, but it seems like it would be a common use >>> case. >>> >>> Thanks, >>> Les Baker >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >> For additional commands, e-mail: users-h...@tapestry.apache.org >> > > > > -- > Howard M. Lewis Ship > > Creator of Apache Tapestry > > The source for Tapestry training, mentoring and support. Contact me to > learn how I can get you up and productive in Tapestry fast! > > (971) 678-5210 > http://howardlewisship.com -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
