Hi, Mark. Thanks for writing. After reading your message I can only say...wow! I think it is very interesting the way you made things work and I really would love to see it.
More than that, I'm with you when you say you're doing things from a very different approach when comparing to the average cocoon users do. So, I encourage you to document it well, take your time, and make it public on a website. IMHO, it is something that will help people like me to see Cocoon with a more open mind. Anyway, there are too many new concepts for me in your message, I can't try to understand them all at this stage in my project. So, I should look for another solution quickly. But I hope I could take a look at your work and take your approach into consideration for future projects. Thank you very much. ----- Original Message ----- From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, November 05, 2002 6:56 PM Subject: Re: how to manage several XMLForms in a sitemap? (it was: dynamically choosing an action at runtime) > 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]> > --------------------------------------------------------------------- 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]>
