cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Irv Salisbury <irv.salisb...@gmail.com>
Subject Re: XMLBeans and request attributes
Date Sun, 13 Feb 2005 20:25:22 GMT
On Sun, 13 Feb 2005 16:43:01 +0100, Daniel Fagerstrom
<danielf@nada.kth.se> wrote:
> Irv Salisbury wrote:
> 
> >On Sat, 12 Feb 2005 14:52:57 +0100, Daniel Fagerstrom
> ><danielf@nada.kth.se> wrote:
> >
> >
> >>Irv Salisbury wrote:
> >>
> >>
> >>>This is really a follow up to some questions I asked earlier about XML
> >>>in request attributes.  I wanted to show how I went about solving what
> >>>I needed, and to get feedback if there is a better way.
> >>>
> >>>To recap, my basic problem was that I wanted to call internal
> >>>pipelines and pass them XML.  The cocoon: protocol does not support
> >>>POST, so the easiest way I was told to use request attributes.  I
> >>>decided to incorporate XMLBeans into the mix to make my life easier.
> >>>
> >>>So, all of my business objects in the system are XMLBeans that have
> >>>been generated from a set of XMLSchema files.  I have a series of
> >>>internal pipelines that can generate XML of these schemas.  To "pass"
> >>>the objects around, I use a combination of flowscript and a generator
> >>>I wrote that generates XML from a request attribute that happens to be
> >>>an XMLObject.  (Borrowing from the RequestAttributeGenerator)
> >>>
> >>>So, here is a simple flow snippet:
> >>>
> >>>        var sessionInfo = getSessionInfo();
> >>>      cocoon.request.setAttribute( "sessionInfo", sessionInfo );
> >>>      cocoon.sendPage( "internal/style/catalog" );
> >>>
> >>>So, the goal of the getSessionInfo call is to create a SessionInfo
> >>>object, which happens to be an XMLBeans object.  Here is the
> >>>getSessionInfo method:
> >>>
> >>>  function getSessionInfo() {
> >>>      var pipelineUtil = cocoon.createObject( PipelineUtil );
> >>>        var xmlSaxHandler =
> >>>              XmlBeans.getContextTypeLoader().newXmlSaxHandler(
> >>>
> >>>SessionInfoDocument.type, null );
> >>>       pipelineUtil.processToSAX(
> >>>                  "internal/sessionInfo/getSessionInfo",
> >>>                  null,
> >>>                  xmlSaxHandler.getContentHandler() );
> >>>         var sessionInfo = xmlSaxHandler.getObject();
> >>>      return sessionInfo;
> >>>  }
> >>>
> >>>Then, my generator for internal/style/catalog is such:
> >>>
> >>>         <map:generate type="xmlbeansAttribute">
> >>>           <map:parameter name="attributeName" value="sessionInfo"/>
> >>>         </map:generate>
> >>>
> >>>This really seems to work great.  Has anyone had experience with doing
> >>>this before?  Does this seem like a good idea?  Anything I am missing
> >>>here?
> >>>
> >>>
> >>Seem like a reasonable approach. You can simplify things a little bit by
> >>embeding the XMLBean in an object that implements
> >>org.apache.excalibur.xml.sax.XMLizable,
> >>http://svn.apache.org/viewcvs.cgi/excalibur/trunk/components/xmlutil/src/java/org/apache/excalibur/xml/sax/XMLizable.java?view=markup
> >>The toSAX method could be implemented in terms of the XMLObject.save method.
> >>
> >>Both JXTG and the XModuleSource
> >>http://wiki.apache.org/cocoon/XModuleSource are XMlizable aware, so you
> >>don't need any specialized generator.
> >>
> >>Also, if you are using trunk, it might be interesting to know that Rhino
> >>1.6, (that is used for flowscripts) has extensive XMLBean support:
> >>http://marc.theaimsgroup.com/?t=110009028500003&r=1&w=2.
> >>
> >>
> >>
> >>>The main reason for choosing XMLBeans was the ability to go back and
> >>>forth from Java - XML easily.  Boy, if this was merged with Hibernate,
> >>>that would be something!
> >>>
> >>>
> >>They are at least discussing it: http://wiki.apache.org/xmlbeans/V2Features.
> >>
> >>/Daniel
> >>
> >>
> >>
> >
> >This is why I ask this list!  Thanks for the info.  Great references.
> >You know, if only some of this could be put into book form...
> >
> >
> I would guess that the potential authors waiting for a stable 2.2 to
> come closer.
> 
> Concerning the XMLBean and flow stuff, it would IMO be a
> good idea to have an XMLBean block. That block would contain the XMLBean
> jar, some support stuff like the XMLizable embeding described above and
> maybe an XMLBean aware version of PipelineUtil. It would also contain
> some samples showing how one can use XMLBean and flow. Currently the
> XMLBean jar is part of core in the trunk, but that is unnecesary as
> nothing in core depends on XMLBean and it is a rather large jar.
> 
> I have not found any time to experiment with the new XML stuff in Rhino,
> if you or someone else does, describing your experiences of it or even
> patches are always welcome :)
> 
> /Daniel
> 
> 

I would love to have XMLBeans integrated closer into cocoon.  I looked
more into the XModule stuff as well as the XMLizable and the way that
would work.  It seems like it would actually get streamed in and out. 
The way I am currently doing things, so streams are used at all, just
SAX events.  It seems like this is more efficient.  I saw some
discussions on the wiki link you sent me that talk about having some
additional interfaces such that a stream would not be used if SAX
could be determined.  I understand the challenges to doing that.  Am I
correct in the way I was reading this?  The way I am currently doing
things, I know I have an XMLObject, so I can always use the SAX
directly.

All the links you sent were great.  Having a hibernate and XMLBeans
integration would be incredible for me.  I have usually shied away
from flowscript, trying to do all things in XML.  However, using
XMLBeans to go back and forth between Java and XML is great.

The XML stuff in Rhino, I don't think, helps me much.   It allows you
to do "XML like" things right in flowscript.  However, I deal with the
XMLBeans classes directly in flowscript, so don't need the things I
saw as XML as a first class type.  Now, if I removed XMLBeans and
built the XML up directly in flowscript, it would be really useful. 
Maybe I am missing something here?

I'd love to spend more time helping out.  The best I can do now is
submit small patches, answer questions, and contribute as I can.

As long as we are talking, the other thing I could have found a use
for (and as an alternative to the flowscript approach)  is  BPEL like
scripting language that would let you store results of pipelines and
pass that to other internal pipelines.  BPEL is a really nice language
for orchestrating XML "web services".  Seems like it would be a great
addition to cocoon.

Keep in mind my original problem was being able to take results of one
internal pipeline and pass it as input to another.  I really don't
NEED flowscript, but am using it to move my XML around.  A BPEL like
solution would allow me to stay pure XML if desired.

Thanks,

Irv
Irv

Mime
View raw message