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.
Hi,
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.
Sure.
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">
<fd:label>Save</fd:label>
<fd:on-action>
<fd:javascript>
var formModel = form.getAttribute("process").form; // Get the
javascript form model
var facade = form.getAttribute("process").facade; // a bean
facade
formModel.save(facade);
facade.save();
}
</fd:javascript>
</fd:on-action>
</fd:action>
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
[1] http://db.apache.org/ojb/
[2] http://db.apache.org/jdo/
[3] http://ibatis.apache.org/
