cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Lutz <mat...@gmx.at>
Subject Re: CForms: need some design help
Date Tue, 09 Aug 2005 15:50:38 GMT
:-) That sounds familiar to me.

This is the third version of my sitemap... and in between I rather had a 
hard time :-).

Sometimes I am thinking of a diagram drawer for the sitemap... something 
like a parser grepping all matchers and parsing the flow functions to 
put together how a request is handled in a nice little dot file.

Basically that's not too difficult I think, but things will get 
complicated in flow functions, determining the variables with influence 
on the sendPage. On the other hand that could be handled with some 
"parser hints" in comments... maybe I'll give it a try someday :-).

:-),
tom

footh wrote:

>Thomas,
>
>Thanks for the reply.  The funny thing is, I stepped
>away from it yesterday, then, last night I tried
>everything from scratch and it suddenly all worked!
>
>I can't figure out what went wrong before but at this
>point I don't really care.
>
>Anyway, thanks for the tips.  Based on your sitemap, I
>think I can improve mine by consolidating some of my
>pipelines.
>
>Regards,
>
>JF
>
>--- Thomas Lutz <mattom@gmx.at> wrote:
>
>  
>
>>yep, thats quite the same approach. there's only one
>>difference, my html 
>>renderer takes care of both form and no form
>>content. Here are some 
>>fragments from my sitemap...
>>
>>        <map:match pattern="*.form.do">
>>          <map:call function="genericForm" />
>>        </map:match>
>>
>>This intercepts all requests that result in a edit
>>form. I have similar 
>>matchers for views, details, deletes,... classical
>>new edit delete stuff.
>>
>>Then the genericForm function goes crazy (do
>>binding, attach 
>>formhandler, get data from by j2ee layer...) and
>>quits with:
>>
>>form.show(tFormName + ".formobj.html");
>>
>>This is handled by my generic renderer:
>>
>>        <map:match pattern="*.*.html">
>>          <map:aggregate element="root">
>>            <map:part src="cocoon:/menu/{0}"/>
>>            <map:part src="cocoon:/c_{2}/{1}.xml"
>>element="content" 
>>label="content"/>
>>          </map:aggregate>
>>          <map:transform src="simple2page.xsl">
>>            <map:parameter name="contextPath" 
>>value="{request:contextPath}"/>
>>            <map:parameter name="page" value="{0}"/>
>>            <map:parameter name="locale"
>>value="{../locale}"/>
>>          </map:transform>
>>          <map:transform 
>>
>>    
>>
>src="context://resources/xsl/html/aim-page2html.xsl">
>  
>
>>            <map:parameter name="contextPath" 
>>value="{request:contextPath}"/>
>>            <map:parameter name="page" value="{0}"/>
>>            <map:parameter name="locale"
>>value="{../locale}"/>
>>          </map:transform>
>>          <map:transform type="i18n">
>>            <map:parameter name="locale"
>>value="{../locale}"/>
>>          </map:transform>                     
>>          <map:serialize type="xhtml"/>
>>        </map:match>
>>
>>The aggregator generates a document with menu and
>>content information, 
>>the simple2page.xsl creates a content layout with
>>some metatags, which 
>>are rendered to html (or someday to pdf...) with the
>>second stylesheet.
>>My header and footer is rather static, so I add it
>>in the 
>>aim-page2html.xsl... but there's not much difference
>>to your aggregation.
>>
>>The important line is:
>>
>><map:part src="cocoon:/c_{2}/{1}.xml"
>>element="content" label="content"/>
>>
>>This calls some internal pipelines for content
>>generation, and one of 
>>them generates the form:
>>
>>        <map:match pattern="c_formobj/*.xml">
>>          <map:generate
>>src="cocoon:/{1}.obj.form.template.xml"/>
>>          <map:transform type="forms"
>>label="content1" />
>>          <map:transform 
>>
>>    
>>
>src="context://resources/xsl/forms/forms-samples-styling.xsl"/>
>  
>
>>          <map:serialize type="xml"/>         
>>        </map:match>
>>
>>Don't ask me why I have the label="content1" stuff
>>here, can't remember 
>>now .-).
>>
>>The line
>><map:generate
>>src="cocoon:/{1}.obj.form.template.xml"/>
>>just calls a pipeline, that tests for a file with a
>>form definition, and 
>>if there's no file generates a form definition from
>>metadata, nothing 
>>special here...
>>
>>Could you post the exception, too ? Maybe it looks
>>familiar to me, I had 
>>rather strange problems setting up my environment,
>>too... (and right now 
>>I am stuck in some weird binding exceptions :-) ).
>>
>>:-),
>>tom
>>
>>footh wrote:
>>
>>    
>>
>>>I think I tried something very similar but I was
>>>getting a null pointer exception.  Perhaps if I
>>>      
>>>
>>showed
>>    
>>
>>>you some of my sitemap you could steer me in the
>>>      
>>>
>>right
>>    
>>
>>>direction.
>>>
>>>All pages go through this pipeline:
>>>
>>><map:match pattern="*.html">
>>> <map:call function="allPages">
>>>   <map:parameter name="source" value="{1}"/>
>>>   <map:parameter name="type" value="html"/>
>>> </map:call>    
>>></map:match>
>>>
>>>Now, the allPages function will set up the variable
>>>map that I need for all my pages. Typically after
>>>that, I would just use sendPage to send the process
>>>      
>>>
>>to
>>    
>>
>>>my "aggregation" pipeline that looks like this:
>>>
>>><map:match pattern="*.html.temp">
>>> <map:aggregate element="page">
>>>   <map:part src="cocoon:/header"/>
>>>   <map:part src="cocoon:/sidebar-left"/>
>>>   <map:part src="cocoon:/{1}-content"/>
>>>   <map:part src="cocoon:/sidebar-right"/>
>>>   <map:part src="cocoon:/footer"/>
>>> </map:aggregate>
>>> <map:transform src="stylesheets/main.xsl"/>
>>> <map:serialize type="html"/>
>>></map:match>
>>>
>>>Each "part" is a separate pipeline that generates
>>>      
>>>
>>the
>>    
>>
>>>XML I need for each piece.  They are all just JX
>>>generators.
>>>
>>>Anyway, in the allPages function from the flow, I
>>>added logic to determine whether the main content
>>>      
>>>
>>was
>>    
>>
>>>a form.  So instead of using sendPage to send it to
>>>the above pipeline, I used form.show to send it to
>>>this:
>>>
>>><map:match pattern="*.html.form">
>>> <map:aggregate element="page">
>>>   <map:part src="cocoon:/header"/>
>>>   <map:part src="cocoon:/sidebar-left"/>
>>>   <map:part src="cocoon:/{1}-display-form"/>
>>>   <map:part src="cocoon:/sidebar-right"/>
>>>   <map:part src="cocoon:/footer"/>
>>> </map:aggregate>
>>> <map:transform src="stylesheets/main.xsl"/>
>>> <map:serialize type="html"/>
>>></map:match>
>>>
>>>Which is the same as the previous pipeline, except
>>>      
>>>
>>the
>>    
>>
>>>main content is generated with a different
>>>      
>>>
>>pipeline. 
>>    
>>
>>>That pipeline looks like this:
>>>
>>><map:match pattern="*-display-form">
>>> <map:generate src="forms/ftemplate-{1}.xml"/>
>>> <map:transform type="forms"/>
>>> <map:transform
>>>src="forms/stylesheets/forms-main-styling.xsl"/>
>>> <map:serialize type="xml"/>
>>></map:match>
>>>
>>>But, this gives me a null pointer exception which
>>>      
>>>
>>is
>>    
>>
>>>very difficult to track.  I assumed it was because
>>>      
>>>
>>the
>>    
>>
>>>form definition file that was used when the new
>>>FormInstance variable was constructed gets lost
>>>because I'm going several pipelines deep rather
>>>      
>>>
>>than
>>    
>>
>>>just directly using the form transformer.  Is this
>>>similar to what you are doing?  Can you give me
>>>      
>>>
>>some
>>    
>>
>>>pointer as to how I might be able to fix this?
>>>
>>>
>>>
>>>
>>>--- Thomas Lutz <mattom@gmx.at> wrote:
>>>
>>> 
>>>
>>>      
>>>
>>>>I had quite similar problems as you have, here's
>>>>        
>>>>
>=== message truncated ===
>
>
>__________________________________________________
>Do You Yahoo!?
>Tired of spam?  Yahoo! Mail has the best spam protection around 
>http://mail.yahoo.com 
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
>For additional commands, e-mail: users-help@cocoon.apache.org
>
>
>  
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Mime
View raw message