Allow up-target on form submit buttons (input type submit and button type submit)

[Francesco Belladonna]

Hello!

I found extremely useful the ability to specify a different `up-target` for different submit buttons of the same form.

For example, I have a 2 buttons on my form, one saves the whole thing, another adds a new form field with some data populated and validated from the server.

I wasn't able to achieve this with a simple link (I needed the full form data) and just wished I could specify `up-target` on each button (along with a default one on the form).

Unfortunately is not supported but I was able to implement it with a simple `up.compiler` (thanks!!). I figured it would be a very nice addition to the framework.

The combination of a custom `up-target` plus a name+value on the button will easily allow the form to behave in entirely different ways, while staying integrated with the unpoly approach.

Cheers!

[OvermindDL1]

I'm curious if just specifying a different form path would work though, or distinguish from the buttons by their name on the server side, or just use a normal anchor to append the fields to the form without overwriting it?

[Francesco Belladonna]

That's an interesting suggestion.

I do distinguish buttons by their name on the server side, however with the actual "submit" button (save the entire thing) I **need to re-render the whole form**, because I expect to actually change page, but if it fails it means there has been a validation issue somewhere and I don't know which field has the error, so I need to render the entire thing again.

This means that no matter what, if I use an up-target in the form with (e.g.) "form.myclass, place-to-append:append", it will always re-render the whole form.

I'm thinking: what happens if I render only an HTML element for the `place-to-append`, would it still re-render the whole form or would it ignore the first selector? If it ignores the first selector it can work, but from my understanding unpoly always goes back to "default", which means all the way up to `body`.

I can't handle it entirely from JS because I need some stuff that's in the form to determine if you can add more input fields (there is a limit, plus some pre-populated data).

--
You received this message because you are subscribed to a topic in the Google Groups "unpoly" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/unpoly/8Zgm0f52ezQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to unpoly+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/unpoly/1bf92b9c-58d6-4a4f-8a8c-4b62b74a2b85%40googlegroups.com.

[OvermindDL1]

Personally, I don't intend to change the 'content' of the form, but to render errors I just add something like a `form-errors` class to the error div's of each input (invisible and text-less by default when no validation error but always rendered otherwise) and just have those update'd by unpoly.  I try to keep the updating of the DOM to a minimum when possible, and I try to never swap any DOM element that holds user input since it very often will reset the cursor (at best).

To unsubscribe from this group and all its topics, send an email to unp...@googlegroups.com.

[Francesco Belladonna]

I totally agree with you and it is my target too.

I tested this as first thing, however it wasn't replacing just the divs, but the whole form instead (or the whole body, I don't remember).

It might have been a bug in my code!

I'll test this again and let you know, if it works, it addresses my problem.

Cheers!

To unsubscribe from this group and all its topics, send an email to unpoly+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/unpoly/7787fd1a-6066-431c-938b-d09ef29b6518%40googlegroups.com.