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

[Christian Haul]

Josema Alonso wrote:

I wonder if it would be easier and cleaner to have different actions
depending on the model (e.g. bean / dom) like you demonstrate on the
wiki page or at least two different parameters for specifying the
model. Automagic is fine but hiding the information whether it is a
class to instantiate or a source to read seems to be wrong IMO.

Well, I'd go further, I just don't like automagic. In fact, I had a working
form where you should not write any Java code but the perform() method.
Connection to the Xindice DB was done by the XMLDBTransformer. I was
thinking about extending it more to some mechanism that would create the
Action, too so you won't need to write the Java code, but I gave up cause I
didn't like it. You end up coding complex logic in XML (XSP and such), and I
don't want XML for that. I like Java for that.

Tastes differ and both have their use. I'd like to second Sylvain on this.

But why do you think the proposed way is hiding the model?

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?

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?)

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.

The model parameter is clearly coded in the sitemap, so the contract between
model and form is declared clearly there.
If you mean the SourceResolver would hide where the model really is, well,
we just take advantage of the Cocoon protocols for locating the model, and I
think that's good and very flexible. You can use this mechanism to do bad
things...maybe, but just don't do it  ;-)

So you are planning to add the "java:" pseudo protocol to source resolver?

If you like more than one parameter for the model can you tell us what for?

No. But perhaps a _different_ parameter depending what type of model it is. Although *I* would prefer different actions.

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.

Chris.


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