All, Just a brief update to this earlier thread about how a request flows through the XMLUI.
I finally got around to documenting this in a more formal fashion. I just added a section called "Overview of XMLUI / Manakin" to the online 1.8 documentation: https://wiki.duraspace.org/display/DSDOC18/XMLUI+Configuration+and+Customization#XMLUIConfigurationandCustomization-OverviewofXMLUI%2FManakin Under this "Overview" section, there is now a section called "Understanding the Flow of an XMLUI Request" : https://wiki.duraspace.org/display/DSDOC18/XMLUI+Configuration+and+Customization#XMLUIConfigurationandCustomization-UnderstandingtheFlowofanXMLUIRequest Hopefully others will find this useful! If anyone notices any mistakes in my documentation (or wish to enhance it), feel free to make your own updates! Thanks, - Tim On 11/14/2011 10:21 AM, Tim Donohue wrote: > Hi Jose, > > Here's the general "flow" of things in XMLUI. Remember, as Cocoon is > pipeline based, there can actually be *multiple* matches per possible URI. > > General XMLUI Request Flow: > =============================== > > Everything starts at the root 'sitemap.xmap' (main 'entry' point for all > requests) > 1. It loads 'themes/themes.xmap' (which controls the Themes) > 1a. This then loads all "matching" themes configured in xmlui.xconf > 1b. If more than one theme matches the URI, then first match wins > 1c. The theme's 'sitemap.xmap' is loaded & processed > > When the theme's 'sitemap.xmap' is loaded, it makes a call to generate > the DRI content by calling: > <map:generate type="file" src="cocoon://DRI/{1}"/> > > This generates a brand new internal Cocoon request, which is processed > back in the *root* sitemap.xmap. > 2. Again, back in the root sitemap.xmap, the "DRI/**" call is matched > and loads the 'aspects/aspects.xmap' (which controls the Aspects) > 2a. This loads all enabled Aspects configured in xmlui.xconf > 2b. Each aspect is loaded in the order it appears. But, *multiple* > aspects may be loaded for the same URI. (Remember aspects can build upon > each other as they generate the final DRI content) > 2c. When an aspect is loaded its 'sitemap.xmap' is loaded & processed. > > 3. Finally, after all Aspects have been processed, the flow returns back > to the Theme's sitemap (remember it is what triggered the loading of the > Aspects in the first place). That theme's sitemap continues processing, > at this point it will perform a transform using various XSLTs to > generate the final XHTML content which is the user interface. > > That's a simplified version of what is going on underneath. So, > hopefully that will give you some clues on how best to proceed. > > (I'm now realizing this general flow probably should be documented > somewhere -- not sure that it is documented anywhere yet. It took me a > while to figure it out on my own.) > > - Tim > > On 11/14/2011 9:48 AM, Blanco, Jose wrote: >> Sorry for my hard headedness, but I still don't understand. >> >> Perhaps if you could explain this, I would see it. In looking at the >> aspect sitemaps, I was expecting to find only one pipeline match per >> possible uri, but that is I not the case. For example, >> "/community-list" exist in two places: >> >>> grep -r "<map:match pattern=" */*.xmap | grep community-list >> ArtifactBrowser/sitemap.xmap:<map:match pattern="community-list"> >> BrowseArtifacts/sitemap.xmap:<map:match pattern="community-list"> >> >> How does the code know to use the match in the ArtifactBrowser dir, as >> oppose to what is in the BrowseArtifacts dir? >> >> -Jose >> >> -----Original Message----- >> From: Mark H. Wood [mailto:[email protected]] >> Sent: Friday, November 11, 2011 4:49 PM >> To: [email protected] >> Subject: Re: [Dspace-tech] adding new uri >> >> On Fri, Nov 11, 2011 at 05:03:59PM +0000, Blanco, Jose wrote: >>> I guess my problem is that I'm having a real hard time understanding >>> the flow of a request in the manakin world. >>> >>> I know that in the jspui world the web.xml file is the starting point >>> for a request and gets you going on the path, but how does it work in >>> cocoon. When a uri, say, "/abc" comes in. what is the path it takes >>> before the page is rendered? I think this would be great to know, and >>> could really help me better understand the xmlui interface. >> >> At the bottom it all rests on servlets. That's what web.xml is doing: >> it tells the servlet container (e.g. Tomcat) how to map the local-part >> of a request to some servlet. >> >> IIRC the JSP engine is just a fancy way of creating servlets on the >> fly from something that looks more like the page you want to deliver. >> Similarly Cocoon has to provide at least one servlet to the servlet >> container and you need to have the necessary servlet mapping(s) for it. >> >> Cocoon then looks at the rest of the local-part and applies the >> sitemap(s) to it to figure out what to do with it. >> ------------------------------------------------------------------------------ Cloud Services Checklist: Pricing and Packaging Optimization This white paper is intended to serve as a reference, checklist and point of discussion for anyone considering optimizing the pricing and packaging model of a cloud services business. Read Now! http://www.accelacomm.com/jaw/sfnl/114/51491232/ _______________________________________________ DSpace-tech mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspace-tech
