Dynamic forms

We encourage users to post events happening in the community to the community events group on https://www.drupal.org.
chx's picture

One of the biggest problems with form API is that we need the form API array as it was when the form was created so that we can set values for it. And also we need a current form array to be rendered. This will solve upload problems, multipage forms, poll etc etc.

Let's discuss how to handle this problem.

Comments

_SESSION...

dopry's picture

This seems like the kind of stuff php's SESSION exists for, persistence across multiple requests.

Using a SESSION['previous_form'], SESSION['current_form'], and _POST we should have a pretty clear view of what is going on with checkboxes at the least. We could check of options added on a later $form[page][3], changed options in form[page][2], and vice versa... I also like the idea of handling multpage forms as a windowed view of a larger form....

just some thoughts... rip away.

no sessions

chx's picture

it's out of question. you have two windows open and you have some big problem. maybe give some uniqid to forms could solve this.

form keys then...

dopry's picture

If keying forms is an option, then _SESSION isn't out of the question. I doubt we will get the http spec updated to get checkboxes to return t/f... which I believe is the proper solution to the checkbox dilemma, at least.

I don't really understand the distaste people have for sessions. They exist to provider persistence in the stateless world of http. We should not find a a reason to reinvent this wheel. Using it properly to achieve our ends would be better. Especially for data that only needs to be persistant for a few requests.

well ...

moshe weitzman's picture

the distaste comes from some ill experiments we have tried over the years. in this case, chx is right that we need a unique token for every form in order to do the SESSION[previous] thing. even keying on form id is not enough because a browser can have multiple instances of same form open (and imagine if it is a multi-stage form).

you are right that sessions are great at solving certain problems

I can't think of a reason

merlinofchaos's picture

I can't think of a reason why generating unique keys for each form would be a problem, honestly. A key is very easy to track from form to form, and very easy to generate if no previous key existed. There does need to be a way to expire old form data from the session object. Or is that automagic?

My view currently

chx's picture

We create a uniq form key, put it into a hidden, if we get it, we try to retrieve the form array keyed by that value from $_SESSION['forms'] and use this form array as the basis for form_builder. With proper keying I am OK with sessions.

yes

moshe weitzman's picture

sounds good. i should add that if the key is not present, we should default to current behavior. that, the key is optional, not required. it is not a security key. asp.net has such a key called POSTBACK and it is required. we don't want to go down that road.

I think we need to slim down the form though

adrian's picture

Essentially , instead of putting the entire form into the session, just put the parts that have '#input' => TRUE into the session.

This is the reason we traverse the tree in the first place, and this is much simpler to validate against.

--
The future is so Bryght, I have to wear shades.

useful info for me tnx .

pizduk's picture

useful info for me tnx .

i have a plan for it

adrian's picture

I'm trying to figure out a way to make the form more static, and more cacheable.
i need a bit more time to form my thoughts properly, but essentially it all ties into callbacks.

Also. it took me a while to figure out how they work, but i am now 110% convinced that continuations are the correct way to handle multipage forms.

Basically, I don't think we can , or should, try to solve it for the current incarnation of forms api.
But we can design for the future.

--
The future is so Bryght, I have to wear shades.

unique form for all content types

sjeandroz's picture

hello,

I'm not sur if it's the better place for my idea...

My goal is to simplify the users' work on my plateform, saving them the choice of the content type that they create.

So, I would like to have a single form for content's creation, and then, depending on how the user fills out this form, Drupal determines what type of node create with data from this form.

After some research, I have found nothing similar.

According to you, is it a big transformation, or it's not a big development?

Thanks for your responses and your opinions

Sjeandroz

Form API

Group organizers

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds: