Tim,
Thank you, Thank you, Thank you! This is great information to have in
understanding xmlui.
So, one more simple question, I think. I looked at my xmlui.xconf file and see
that I'm loading the following aspects:
<aspect name="Artifact Browser"
path="resource://aspects/ArtifactBrowser/" />
<aspect name="Administration" path="resource://aspects/Administrative/"
/>
<aspect name="E-Person" path="resource://aspects/EPerson/" />
<aspect name="Submission and Workflow"
path="resource://aspects/Submission/" />
So, knowing this I see that the "/community-list" request would be handled by:
ArtifactBrowser
And not
BrowseArtifacts
Which makes me think, what purpose does BrowseArtifacts serve? Why do we have
it?
One more question, Tim. I hope it's a simple one. I often have problem
getting the cache to clear in the xmlui world. I remember an email by Mark
Diggory about deleting a certain directory, but can't remember what directory
that is, do you know?
Thank you again!
Jose
-----Original Message-----
From: Tim Donohue [mailto:[email protected]]
Sent: Monday, November 14, 2011 11:22 AM
To: Blanco, Jose
Cc: [email protected]; Mark H. Wood
Subject: Re: [Dspace-tech] adding new uri
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
------------------------------------------------------------------------------
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
