cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antonio Gallardo <>
Subject Re: [CForms] Streaming out widget attributes?
Date Thu, 10 Aug 2006 04:17:25 GMT
Matthias Epheser escribió:
> Antonio Gallardo schrieb:
>> Sylvain Wallez escribió:
>>> - since only CForms has Ajax integration, people are over-using it 
>>> for presentation purposes (e.g. paginated repeater)
>> I agree with you, mixing binding with form definition is not good. We 
>> want to keep it separated. However, I think it is a first 
>> implementation wich show us a way to implement a paginated repeater 
>> after all it is not released yet. It is a work in progress. Is not 
>> fair to blame to a first draft implementation.
> I had my thoughts whether the mixing is appropriate or not from the 
> start, so thank you for your feedback.

I am sorry for to things:

1. The way you got the feedback
2. The late of my reply.
> As Simone mentioned in his reply, our main goal was to achieve the 
> lazy-loading of pages. I agree that using the standard binding to 
> fetch all rows and just display a subset (page) of them could be 
> easily done with some simple xsl and without changes in the repeater 
> implementation at all. But we are not focused just on presentation. 
> Our implementation is a try to load only the row-data we need to 
> support persistency frameworks and large collections in general. 
> Currently lazy loading could be achieved without changes in the 
> controller except using the advanced collection. Editing data is also 
> possible yet, adding and deleting of rows will follow.
> So concerning this I think pageSave/pageLoad has to be done in the 
> binding because we have to control the doLoad()-method and prevent it 
> from fetching and creating all rows from the start. To ensure 
> seperation of concerns we can maybe try to move everything to the 
> binding.
A RT: We may extend the repeater with an interface to fetch and store 
data in different O/R tools. ie: OJB [1], JDO, ibatis [3], etc.
> Currently the form-definition is used to enable pagination and and 
> setting pageSize and so on. This configuration tag could be easily 
> moved to the binding definition file without problems.
> The binding registers its pageStorage object in the repeater object 
> just for one purpose. In the change-page-action I need to call 
> pageSave and pageLoad.
Yep. This is also the same as for an ajax enabled application when you 
try to stay in ajax mode as long as possible. By now, we are bundling as 
a form attribute, the javascript flow formModel. This model allows us in 
the form definition access the form binding framework. ie: in the 
definition we wrote something like the next code to allow user to save 
changes without living the form:

<fd:action id="save" validate="true">
          var formModel = form.getAttribute("process").form;  // Get the 
javascript form model
          var facade = form.getAttribute("process").facade;  // a bean 

This way we are able to access the binding framework without a mix. I 
don't know if this is the ugliest hack, but solved our needs. :-)
> If I manage to access these methods there directly without 
> repeater.getStorage().doPageLoad() in a decent way, everything would 
> work just using the binding and without touching the definition and 
> the repeater itself.
> Please let me know what you think about it or if I'm getting something 
> completely wrong.
Unfortunately, right now, I don't have an opinion out of hand. I think 
AJAX form handling is a different beast than traditional MVC form 
handling, hence we need to address it in a different way. Your effort 
are well appreciated and we expect to help as much as is possible.
> Matthias

Best Regards,

Antonio Gallardo


View raw message