[Html-widget] latest formfu developments

[Mario Minati]

Carl Franks schrieb:
> On 24/02/07, Mario Minati <mario at minati.de> wrote:
>>
>> I have an other idea of extending the formfu. Actually It's more a need
>> than an idea.
>> I need forms to submit n-times the same field, e. g. I want to be able
>> to submit telephone numbers, but don't know if it will be only one or 
>> ten.
>> My database is that flexible that it can hold as many numbers as given.
>> Now I would like to create an javascript-supported form which gives me
>> in the beginning one field for a telephone number and a '+'-button which
>> creates an additional field.
>> This concept should not only work for one single field that can be
>> repeated but also for a complete fieldset, so that I could submit
>> multiple address to give an other example.
>
> Having multiple copies of a fieldset definitely causes extra complexity.
> If you just had multiple copies of a telephone field, they could all
> have the same name, and you just make sure you handle multiple values
> for that parameter.
> Having copies of an entire fieldset means that you have to have a
> unique name for every field, because there's no guarantee that the
> input will be sent back in the same order.
Yes, I know that.
>
> The way I imagine this working is something like...
> change id_format() to support some sort of iterator, for generating
> sequential id names.
> also let it accept a subroutine-ref for more advanced generation of id's.
> Add a name_format() method to provide the same capabilities for name 
> generation.
Ok
>
> Add a duplicate() method to fieldsets and fields, which clones the
> element (and all its constraints, etc), generates new ids and names,
> and adds it to the form immediately after the existing element
Ok.

I thought of a capsulating the functionality in a form element, lets 
name it 'Repeatable'.
This could take parameters of min and max number of elements and take 
care of it's child elements.
It could contain a hidden field that stores the number of repetitions, 
which might be needed on parsing the form without making asumptions.
And it could manipulate the id_format in a way that we generate ids / 
names which like 'name__repetition001'.
Inside of repeatable fieldsets we should generate ids / names like 
'fieldset__repetition001__name' than there could be nested 'Repetable' 
fields.

>
> If it's an ajax request that only wants the markup for the new element,
>    print $form->result->field('new-field');
> otherwise, if it's a non-JS request, and you need to render the whole
> page again with the new element, then
>    print $form->result;
> as normal.
The creation of the new elements should be done by an own classso we can 
provide different ways,
either via ajax or via non-js request like said before. Also the layout 
(only a button behind an input element or a more fancy thing) could be 
different through this approach.
> It would also be nice to get nested parameters working with formfu -
> which would help organise these kind of values.
> (nested params are rails-like "address.city" or "address[city]" style)
I am not familiar to rails, so could you explain that a little bit to me?

One thing I would like to helpthe user with is the storage of the data.
If we leave this functionallity  in the Dbix:Class Tree we need to 
provide a way how to tell the fill functions which functions (the 
autogenerated ones when we connect databases, I hope you know what I 
mean ;-) to call to load and save.
By the way we need to store the db id's for editing and have to care 
about unique constraints, at least we have to provide ways for the user 
to do so.
>
> Anyway - that's some thoughts for now - but it undoubtedly needs some
> details filled in.
That is what my brain produced when thinking about it.

Greets,
Mario