Fred,
> >>Hmm that shouldn't be too hard to add.
> >>Maybe you could take a crack at it ;-)
> >
> >Then there really _would_ be bidirectional templates !
> >
> >And there's plenty of Javascript "out there" for clicking
> >to add a new row to a table. Then table/list editing could
> >be done 100% locally before POST'ing it.
>
> Not really sure I'm following you :-/
It's always possible that I'm full of balonie :)
> How does Javascript fit in this picture, or how does this interact
> with bidirectionality?
Rife Forms are truly bidirectional, and can use HTML field validation too.
Rife also makes it easy to append to Value tags, in order to generate HTML
tables with N rows.
But is it possible to generate a Form with N rows, by appending additional
rows, where each row is another instance of the same bean type ? That would
make it possible to have N-record Forms that are bidirectional and that use
HTML field validation. Then the next logical step is to attach some JS that
adds an (N+1)th record at the end of the Form.
Is this making any sense ? Isn't this more or less what is under discussion,
or did I manage to miss the point entirely ?
You are pretty much on the money with what the discussion is about;
it's not possible to 'generate' a form in the manner you mention here,
but you can sort of 'simulate' that; what I am doing on the petstore
app for instance, requires that every cart item be shown as part of
the cart form... this in itself is something rife easily allows you to
do by having a a value placeholder and blocks that you can iteratively
process and append per bean instance... the added complexity comes in
because as per the cart reqts, I have to have a quantity textfield
that allows the user to update qty per item.
rife currently supports a getSubmissionBean(BeanType.class) method
which allows you to easily get an instace of the bean returned from
teh form, and do validation against that... it would be nice (and I
might have to look into this) to be able to make a similar call, only
this time to retrieve a list/array of the beantype you require.
Currently, I am sending back parameters in my submission; like:
<submission name="process">
<param name="id" />
<param name="iid" />
<param name="quantity" />
</submission>
and using getParameterIntValues(paramString) call in my Element
implementation to iterate over these values and recreate the beans
just as I would have expected a call to a proposed getSubmissionBeans
to have worked.
We might hv to think this through and see if it's possible/feasible to
implement something of the sort as a feature of the framework.
Cheers,
Emmanuel
--
Benjamin Disraeli - "Nurture your minds with great thoughts. To
believe in the heroic makes heroes."
_______________________________________________
Rife-users mailing list
[email protected]
http://lists.uwyn.com/mailman/listinfo/rife-users
