Whoops, spoke to soon on that Element / Persist strategy. Didn't stop to
think that the Element object was completely class side and only would
be as up-to-date as it was at declaration. Any changes in the DOM by
Javascript don't translate so that doesn't quite work. Wanted to make
sure no one ended up trying the same and failing.
I don't have the option of using 5.2 at this point, so that seems to
leave out @RequestParameter and @ActivationRequestParameter. What might
my other options be for passing back the value attribute from an HTML
tag to the Component Event method?
I've tried using Javascript to manipulate the EventLink's context, but
this is really messy. My input value is a comma-separated list and the
context complains on nearly any special character I'd like to separate
the values with. I ended up getting working functionality by replacing
spaces with 'BlAnK' and separating the list with 'SePaRaToR' instead of
','. These two strings look so weird as to avoid any chance someone
might actually match them. Feels like a terrible hack to me though, but
deadlines are deadlines and it works.
Is there anything more elegant that this? I'd surely want to refactor
this code ASAP after my deadline. Would an upgrade to 5.2 and using
@RequestParameter be the best refactor I could do, or is there another
solution, possibly 5.1 compatible?
Thanks,
Rich
On 12/22/2010 11:07 AM, Thiago H. de Paula Figueiredo wrote:
On Wed, 22 Dec 2010 13:57:38 -0200, Rich M <rich...@moremagic.com> wrote:
Thanks for the clarifications, Thiago. Helpful as always.
You're welcome!
At first I didn't see a nice way of actually feeding the values from
the HTML form back into the event method for the EventLink though.
creatEventLink seems to assume I know my context from the Component
class, but the context is only ever known to an HTML element after
some Javascript has its way. But then I realized I can save the form
input Element I made during rendering with the MarkupWriter (last
concept you mentioned) with Persist. Then in the event method read
the value attribute back.
Another option is to add request parameters instead of using the
activation context, something that was made even easier with the new
@RequestParameter and @ActivationRequestParameter annotations in
Tapestry 5.2.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org