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.
>
------------------------------------------------------------------------------
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
_______________________________________________
DSpace-tech mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-tech
