Thanks Sylvain,
Seems good for CForms, i just imagine what it would be to have for
instance Struct/Union widget updated in the model and client-side !
Specially because Google started the rush using XHR everywhere.
For the xhr sample, i just don't put the submit-on-change on the car
model, and that's ok for my use.
Regards,
Phil
Sylvain Wallez wrote:
> Philippe Guillard wrote:
>
>> Hi
>>
>> I was happy/surprised to discover the xhr_carselector in 2.1.7
>> samples, and just want to get news about it (Sorry i can't access
>> Bugzilla today, and before didn't find much on bug 34077).
>> I imagine this feature needs lots of work, maybe CForms re-work, so i
>> just wonder what is the situation.
>
>
>
> The current situation is just this nice sample, but I had some
> background thinking about Ajax-ifying CForms for some times now and
> this is itching me more and more :-)
>
> Basically, the idea is that widget stylings can be "ajax-aware". This
> means two things:
> 1 - the styling can send some events back to the form
> 2 - the various elements of the styling can be asynchronously updated,
>
> The first item can be bound to the fact that a widget has an
> on-value-changed or on-action event handler, sending form values back
> to the server using XHR, and waiting for some update actions from the
> server.
>
> When receiving an XHR-originated post, the form tracks all changes
> made to widgets as a reaction to this post (i.e.
> values/selection-lists/labels/errors/repeater-sizes, etc) and sends
> back this event list to the client (we will need a special generator
> for this).
>
> The client sends these changes to the individual widget stylings in
> the page, which updates the display.
>
> If some non-ajax-enabled styling needs to be updated (e.g. a repeater
> table), then a full page reload is triggered. This allows for the
> coexistence of "passive" stylings (the current ones) and ajax-aware
> stylings in a single page.
>
> Just some rough ideas for now...
>
> Sylvain
>
|