Re: extending XMLForms for different kinds of models...opinions?

[Christian Haul]

Josema Alonso wrote:

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.

Yes, that really is a mess when trying to do it from sitemap. From flowscript however, it works nicely.

<snip/>

Do you feel this would be clearer if using two different parameters? One for
the java model and the other for the SourceResolver models?

Indeed, that is my feeling. Given that the necessity to support both at the same time is coming up, it appears even more sensible to separate this. OTOH the two models requirement might as well require two models of the same type...

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?

No ;-)

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'm all in favour of a DOM based model as additional model class. I just don't like prefix approach here.

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...

Well, there's not much to say about them in general. They behave by and large like request parameters but are not limited to them. In addition, some can be layered or stacked upon others. They can be used wherever there's support for them: there's wildcard matcher, a regexp matcher, database actions, transformers for filling in forms or rewriting links, and of course use from sitemap as variable. That's it.

Everything else is very specific to the particular module and documented inside the corresponding javadocs.

One module for example looks up a form by id and uses jxpath to query the model.

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.

Absolutely. I'm not arguing against Castor, OJB & friends. Those are great. (Although I wonder why not use container managed persistence, but that's another story ;-)

Chris.

--
C h r i s t i a n H a u l
[EMAIL PROTECTED]
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08


---------------------------------------------------------------------
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]>