Well I can explain what I've done which matches your requirements but the 
implementation I suspect is quite different.

First some issues I had.
1.) I like the XFORMS concept but... didn't like the fact that I couldn't represent 
non-forms widgets, e.g. page banners, table of contents, footers, buttons that didn't 
submit data, e.g. were simply URL's etc.  so I created a schema (for my own purposes) 
much like XFORMS but then added a few things like url's, etc.  I removed the concept 
of the model and the bindings and what I'm left with is a schema that describes a UI 
so I called it XUI.  I have separate XUI files for the portlets within my page, e.g. 
banner, toc, footer, 1-n body portlets.  
2.) Cocoon's portal concept.  In my world every page is a portal page (not just the 
home page) in that I break it up into banner, toc, footer, body sections.  since the 
banner, toc, footer rarely change (perhaps due to the user's locale or due to security 
permissions for various features) I can cache this and improve overall page 
performance as only the body portlet(s) is really be generated.  Back to cocoon's 
portal concept.  There's four config/layout files and you need to do it per portal and 
then there's alot of sitemap configuration per portal and this isn't my idea of fun.

So I created yet another schema called XPORTAL (again for my own uses) which declares 
validation file to be used, the portlets, the pagebuilder which should assemble all of 
the portlets into one nice page, etc.

So to wrap this up.  What I've done is create a portalAction that takes an actionID 
request parameter (not a url).  The actionID corresponds to an XPORTAL file.  The 
portalAction reads the XPORTAL file and then populates the sitemap parameters and/or 
the httpRequest object with the necessary parameters to drive the sitemap.

Therefore my sitemap is more like a programming language rather than a set of url 
filters.  XML Metadata files read by actions feed the sitemap with parameters.  So 
there's no hardcoding of a specific URL do this...

The XPORTAL file goes so far as to say should we use SSL for a set of pages, should 
the page(s) be authenticated and if so what handler, what UI look and feel skins to 
use, should we validate the form data (form-validator-action) and if so what 
descriptor file, what set, what actions to redirect to for successful validation 
versus unsuccessful validation, etc.

Each portlet then is described using the WSUI schema from www.wsui.org.  This allows 
me to call out SOAP services or wherever.  I've extended the wsui schema to handle 
cocoon "services" (XSP).  WSUI files (for me) show what XSP page to use for the 
model/db IO, and what XUI file (implemented in XSL) to use to transform generated 
model XML into a UI form of XML.  The XUI files implemented as XSL (therefore I get 
XPATH and language constructs like for-loops, choose, etc for free) acts like cocoon's 
XMLFORMS action.

I then do a second XSL transform to do the look and feel (skin).  (skin's are know 
within the portal file as the skin should be applied across the entire page.)

Basically I'm creating a web application framework out of cocoon rather than what (I 
believe) most people are using cocoon for e.g. web publishing.

So I'm more than happy to share the XML schemas with the list as well as sample XML 
files to illustrate their usage.  Beyond that... I've followed an iterative approach 
in developing this and the visual aspects were done first, e.g. pagebuilders 
assemblign HTML fragments hardcoded into a sitemap, then pagebuilders assemblign HTML 
fragments retrieved from an XPORTAL file driving the sitemap, then to XSP pages 
instead of the HTML fragments....

So if you'd like code too... I'd probably just give you the first iterations (as I've 
saved them off) or so otherwise it would be too confusing if I gave you what I have 
now.  Let's just say it's very different although in the end it takes many familar 
concepts to the cocoon community.

To accomplish what I've done I've really only ever created actions and XSP pages.  I 
heavily use XSL and the sitemap.  I also use the authentication framework and the 
form-validation concepts of XSP.  Beyond that I use all the normal sitemap constructs 
like matchers, selectors, resources, transformers, etc.

If interested I'll send the stuff tonight as the computer I'm on doesn't have access 
to all that stuff.

MD

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

Reply via email to