Ivelin, That sounds very very good. I was not sure about all the possibilities when using the SourceResolver. If all of that can be accomplished using the SourceResolver, it's more powerful than I expected and we should take the "java:" as the only way for Javabeans.
But... Since I started with Cocoon, one of the features I don't like is this kind of abruptly changes. If we go for the prefix way, forms currently working should be coded again (at least their sitemap snippets). I think the best solution would be: - Go with the "java:" prefix for beans - Any other prefix -> solved by the SourceResolver - Implicitly assume java, so no prefix means model bean (only by now) At a later stage (maybe for 2.1beta), we could change it so the java models should be called only explicitly and all of the other resources would be solved by the SourceResolver. This way, the transition would be easier to accomplish for users with working xmlforms. Ivelin, I think we talked about something like this? Hope all of you like this approach. I'd like to go ahead and try to patch the AbstractXMLFormAction. Best. ----- Original Message ----- From: "ivelin" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Saturday, February 15, 2003 5:53 PM Subject: Re: extending XMLForms for different kinds of models...opinions? > > This sounds good. > As you suggest the "java:" prefix can be used for instantiating JavaBeans. > For all other cases though, I was hoping to reuse the standard > SourceResolver. > This will immediately allow support for a lot of different sources. > Here is a snippet from the Sitemap document. > http://xml.apache.org/cocoon/userdocs/concepts/sitemap.html > (I wish there was one discussing just SourceResolvers.) > > a.. Use http://foo/bar to merge in xml content via http protocol, received > from machine foo. > a.. Use context://servlet-context-path/foo/bar to merge in xml content from > the servlet context. > a.. Use cocoon:/current-sitmap-pipeline/foo/bar to merge in xml content from > the current sitemap. The appropriate pipeline is selected matching > current-sitemap-pipeline. > a.. Use cocoon://root-sitmap-pipeline/foo/bar to merge in xml content from > the root sitemap. The appropriate pipeline is selected matching > root-sitemap-pipeline. > a.. Use resource://class-path-context/foo/bar to merge in xml content from > the classpath. > a.. Use jar:http://www.foo.com/bar/jar.jar!/foo/bar to merge in xml content > coming from a jar via http connection. > a.. Use file:///foo/bar to merge in xml content from the filesystem. > a.. Use xmldb:<your driver here>://your.xmldb.host/db/foo/bar to merge in > xml content from a XML:DB compliant database. > a.. Depending on your setup you may use nfs:, jndi: protocols, too. > > > > > -=Ivelin=- > > ----- Original Message ----- > From: "Josema Alonso" <[EMAIL PROTECTED]> > To: "Cocoon-Users" <[EMAIL PROTECTED]> > Sent: Friday, February 14, 2003 7:07 AM > Subject: extending XMLForms for different kinds of models...opinions? > > > > Dear all, > > > > I need your suggestions and opinions in extending the current XMLForm > model > > approach. If you use XMLForm or are thinking about using it soon, I'd > > suggest youy to read this message and send some feedback to the list. > > > > Some days ago, and with some ideas I exchanged with Ivelin, I made a > how-to > > that should help users on using XMLForm with Xindice for storing XML > models. > > It is at Wiki (http://wiki.cocoondev.org/Wiki.jsp?page=XMLFormXindice) and > > made its way into the CVS a few days ago. > > > > In this how-to I explored new ways of storing the form model. This new way > > the XML model is stored in a file in the system with an empty structure. > > Then it is loaded into a JXPath Container and manipulated from there. The > > getFormModel() is overriden so you don't need a Bean, but just the file. > > > > Ivelin thought this could be a great addition to the framework, so we were > > discussing how to make this available for the end user. > > > > We exchanged some ideas and they led us to incorporating some mechanism to > > the sitemap. We were thinking about a prefix. This way, passing the model > > parameter to the form would be like this: > > <map:parameter name="xmlform-model" value="java:MyBean"/> > > > > The 'java:' prefix would be used for java models. If you would like to use > > the pure XML model approach you could do something like: > > <map:parameter name="xmlform-model" value="xml:MyDocument"/> > > > > Of course, one of the approaches could be made the default one so this > could > > make life easier for most used models declaring them implicit: > > <map:parameter name="xmlform-model" value="MyModel"/> > > > > I hope I explained it clearly. Now I need your feedback. I'd like to know > if > > this make sense to you and if so, we should decide which of the two > > approaches should be the implicit one, so the AbstractXMLFormAction would > be > > modified accordingly. > > Maybe some of you would prefer to see it implemented but having the java > > models as the implicit ones, so you won't need to change your working > > xmlforms in order to use it in the future 2.1. If you feel that way, > please > > say so. > > > > Best, > > Josema. > > > > > > --------------------------------------------------------------------- > > 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]> > > > --------------------------------------------------------------------- > 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]> > > --------------------------------------------------------------------- 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]>
