TIP: Ajax form submission and hidden input field

[Robert Marcano]

This is something took me a few hours to detect, so I am posting it here
in order to be available for searches

Submitting an Ajax form, Simply Lift book says there is a need for a
hidden input field in order to be the trigger of the submission
processing code on the server. I was having problems because the process
form function was being called before all fields values were stored. I
played moving the hidden field to the many places inside the form.
Results that the position of that hidden field on the form has no
relevance on the order the function on the server are called. It looks
like it is the creation order of each field on the server.

Having an CSS transformation like

"#dynamicFields *" #> (ns: NodeSeq => createFields(ns)) &
#fixedFields * #> S.text(....) ++ S.hidden(...)

cause the problem I was experiencing, The hidden field is created first
than the contents for #dynamicFields, So those fields are generated
later because it is using NodeSeq => NodeSeq and that is delayed until
the selector is really evaluated. Changing to

"#dynamicFields *" #> (ns: NodeSeq => createFields(ns)) &
#fixedFields * #> (ns: NodeSeq => S.text(....) ++ S.hidden(...))

Solves the problem.

[Antonio Salazar Cardozo]

If you're using Lift's ajaxForm and ajaxSubmit helpers, they should automatically append the submit button's name to the request so that you don't need a hidden field to trigger the submit. Additionally, the ajaxSubmit helper I believe is set up in a priority category so that unless you make an explicit attempt to do otherwise, it will run after any other form handlers in the form. Could be wrong about that last part, I haven't looked at it in a while, but that's what I remember seeing.

Thanks,

Antonio

[Robert Marcano]

On 03/21/2012 03:38 PM, Antonio Salazar Cardozo wrote:
> If you're using Lift's ajaxForm and ajaxSubmit helpers, they should
> automatically append the submit button's name to the request so that you
> don't need a hidden field to trigger the submit. Additionally, the
> ajaxSubmit helper I believe is set up in a priority category so that
> unless you make an explicit attempt to do otherwise, it will run after
> any other form handlers in the form. Could be wrong about that last
> part, I haven't looked at it in a while, but that's what I remember seeing.
> Thanks,
> Antonio

I see, I am using JavaScript form.submit(), no button inside the form
available. But checking the implementation of "ajaxSubmit" I see a
pattern of how the handlers order is selected

"ajaxSubmit" add a "z" prefix to the nextFuncName, trying to move it to
the end of the handler processing order I think. nextFuncName has some
sequence too that is way my fix helped.

Thanks for the ajaxSubmit reference

>
> On Tuesday, March 20, 2012 4:39:34 PM UTC-4, Robert Marcano wrote:
>
> This is something took me a few hours to detect, so I am posting it
> here
> in order to be available for searches
>
> Submitting an Ajax form, Simply Lift book says there is a need for a
> hidden input field in order to be the trigger of the submission
> processing code on the server. I was having problems because the
> process
> form function was being called before all fields values were stored. I
> played moving the hidden field to the many places inside the form.
> Results that the position of that hidden field on the form has no
> relevance on the order the function on the server are called. It looks
> like it is the creation order of each field on the server.
>
> Having an CSS transformation like
>
> "#dynamicFields *" #> (ns: NodeSeq => createFields(ns)) &
> #fixedFields * #> S.text(....) ++ S.hidden(...)
>
> cause the problem I was experiencing, The hidden field is created first
> than the contents for #dynamicFields, So those fields are generated
> later because it is using NodeSeq => NodeSeq and that is delayed until
> the selector is really evaluated. Changing to
>
> "#dynamicFields *" #> (ns: NodeSeq => createFields(ns)) &
> #fixedFields * #> (ns: NodeSeq => S.text(....) ++ S.hidden(...))
>
> Solves the problem.
>

> --
> Lift, the simply functional web framework: http://liftweb.net
> Code: http://github.com/lift
> Discussion: http://groups.google.com/group/liftweb
> Stuck? Help us help you:
> https://www.assembla.com/wiki/show/liftweb/Posting_example_code

[Antonio Salazar Cardozo]

Cool, no problem. I thought there was a more formal mechanism in Lift to prioritize the funcs associated with fields, but it looks like that may not be the case after all.

Thanks,

Antonio

[Diego Medina]

Is this what you are looking for:

http://www.assembla.com/spaces/liftweb/wiki/cool_tips
"Server side function order."

Regards,

Diego

--
Diego Medina
Lift/Scala Developer
di...@fmpwizard.com
http://www.fmpwizard.com

[Antonio Salazar Cardozo]

S.formGroup, that's the one! Knew I'd seen something for that :)

Thanks,

Antonio

[Robert Marcano]

On 03/22/2012 01:43 PM, Diego Medina wrote:
> Is this what you are looking for:
>
> http://www.assembla.com/spaces/liftweb/wiki/cool_tips
> "Server side function order."
>
> Regards,

Ohh that is better, thanks. I wish form groups have a little more
features than ordering. I think I need some way to free a group of
callback functions when needed. That should help with single page
interfaces talked on previous threads

I am building dynamic forms on a page, I wish for a way to free those
callbacks when I know the form was dismissed. I know I will get some
users that will never close that page, not common but can happen, do not
want those people to use all available RAM

[Antonio Salazar Cardozo]

I'd say don't worry about it until you see an actual measurable impact.

That said, I'm working up some stuff on how to use Knockout JS with Lift, and part of that is rendering form elements via comet and sending them down with their own GC id, whose removal from the page would result in the related functions being GCed. Hopefully should have something to post in the next few days.

Thanks,

Antonio