> Tastes differ and both have their use. I'd like to second Sylvain on this.
Regarding Sylvain's opinion, please forgive me on this cause it seems I lost the thread somewhere, but I guess you're talking about this: <snip> > Sylvain Wallez wrote: > > > This is a good idea when you need to use the JavaBean for some > > business logic. But there are many cases where you just want to > > populate a database after successful validation, and the average > > Cocoon user quickly becomes reluctant to writing Java code, even for > > storing data in a database ;-) > > > > Sylvain </snip> I'm with Ivelin that the 'average' Cocoon user knows how to write that piece of code efficently. Anyway, as you say, maybe this is a matter of taste. When I tried not to use Java, the hard part was not the CRUD one but the validation against the DB. Mixing both was a nightmare when not using Java. When using Java code and the helper class I only had to write very few lines and everything was working. > How would that work? You either filter the "java:" pseudo protocol from > the parameter or extend the source resolver. If the latter, in what > other context would that make sense? If the former, why lure the user > into the belief that "java:" is a valid pseudo protocol that could be > used anywhere? It's the first case the one I'm considering. I don't think the user would think it could be used anywhere if it's well documented. If you think so, we could go for another type of prefix. I was not thinking on a pseudo protocol and don't think about extending the SourceResolver either. Do you feel this would be clearer if using two different parameters? One for the java model and the other for the SourceResolver models? I do not think those are necessary, that's why we thought about a prefix. > Additionally, the behaviour differs: In case of a class, it is loaded, > instantiated, initialized &c. In case of a DOM, it is retrieved. Does it > make sense to attach a listener to each model? (Should the class > instance be automatically registered as listener if it implements the > right interface?) Good point. I'm not sure about what to think about it yet. Do you have a use for the Listener already? > These are just thoughts without further reflection. They create the BT > (thanks Steven for this new acronym for belly thought ;-) that in the > heart of things a DOM model and a java model differ too much. Yes, they differ. But remember we're just trying to support both easily. Current implementation of xmlforms only allows java models, we propose adding a new kind of models, the pure XML models, that could be solved by the SourceResolver. That was the original idea. I finally got to get the thread in the dev list and see your Input Modules approach. It happens to me the same that happens to Sylvain. It seems cool but too complicated for me right now. I have to learn more about Input Modules and I really hope better documentation about them would exist... Again this seems to try avoiding unnecessary steps, and I think we all would like that. Note that I think we could make some kind of auto-modeling sooner or later but I think validation for that auto-models will be harder to accomplish. > > ps: OT: I'm not getting some of the messages from the list while I get some > > of them twice or more, anybody else? > Nope. Only when CC'ed additionally. Mind you that ivelin CC'ed > cocoon-users and cocoon-dev. Thanks. Maybe that's the case. I should be subscribing to the dev list the sooner the better... --------------------------------------------------------------------- Please check that your question has not already been answered in the FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html> To unsubscribe, e-mail: <[EMAIL PROTECTED]> For additional commands, e-mail: <[EMAIL PROTECTED]>
