cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Haul <h...@informatik.tu-darmstadt.de>
Subject Re: extending XMLForms for different kinds of models...opinions?
Date Tue, 18 Feb 2003 11:46:34 GMT
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
haul@informatik.tu-darmstadt.de
     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:     <cocoon-users-unsubscribe@xml.apache.org>
For additional commands, e-mail:   <cocoon-users-help@xml.apache.org>


Mime
View raw message