cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <dani...@nada.kth.se>
Subject Re: XMLBeans and request attributes
Date Sun, 13 Feb 2005 15:43:01 GMT
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





Mime
View raw message