Hidden component semantics changed (was Re: [5.3.4] Ordering of Actions...)

[robert baker <le...@gmail.com>]

Howard (and list),

After doing some more research, I found the issue, and it didn't have
anything to do with the ordering of render phases (I apologize for
that).

What happened was that the ValueEncoder in question was coded to
create a blank object (i.e. "null object" pattern) on a null value in
its toValue implementation. Due to the fix for issue TAP5-832 [1] the
data flow was changed to include NullFieldStrategy, like the TextField
does, and bypass the ValueEncoder if the Strategy returns null. The
bypass caused the null value and the resulting "null term in property"
exception, and the fix was to pass a "blank string" NullFieldStrategy
(returns "") to the Hidden component.

Hopefully, a brief note could be included in the 5.3 migration notes
to check one's ValueEncoders that participate in Hidden component
persistence.

(Yes, I definitely am looking forward to what's coming in 5.4 even
just based on the "JavaScript Rewrite" document that was posted.)

Thanks,
Les Baker

[1] https://issues.apache.org/jira/browse/TAP5-832

On Fri, Aug 3, 2012 at 1:43 PM, Howard Lewis Ship <hl...@gmail.com> wrote:
> 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 <hl...@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 <le...@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 <le...@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-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@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-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org