2

Reading the documentation i'm a bit confused as to where exactly are aspect chains.

in the documentation: https://wiki.duraspace.org/display/DSDOC18/XMLUI+Configuration+and+Customization#XMLUIConfigurationandCustomization-AdditionalXMLUILearningResources

IT is not clear how the order of the aspect is determined, hence how they are actually chained.

I red in a doc of 2005 that Manakin Developer Guide, that the order was determined from a file aspect.xml.

Please could someone, explain briefly how one match uri to a chain of aspect? but it seems like it is not in dspace 1.8.2 anymore. Could it be that one can work without it ? or is there another way to associate an uri to a chain ?

Beside I do never understand yet what means {1} or {2} and etc. in the DRI path. A hint here would help me understand better.

MaatDeamon
  • 9,532
  • 9
  • 60
  • 127

1 Answers1

4

The documentation is a bit obscure. There is one aspect chain. Every dynamically generated page passes through it.

To understand how it all works, you need to keep in mind that XMLUI is a Cocoon application, and in particular you need to understand the Cocoon "sitemap" which is built up from a number of .xmap files. Incoming requests are guided through the sitemap by map components called Matchers. XMLUI embodies the Aspect chain in a portion of the sitemap.

Where the aspect chain is defined: config/xmlui.xconf, as the content of the <aspects> element. The order given there is the order in which the defined Aspects will be applied to the developing DRI document. (This is stated a bit higher up in XMLUI Configuration and Customization, at https://wiki.duraspace.org/display/DSDOC18/XMLUI+Configuration+and+Customization#XMLUIConfigurationandCustomization-UnderstandingtheFlowofanXMLUIRequest in step 3b.)

I can't find any instance of an 'aspect.xml'. webapps/xmlui/aspects/aspects.xmap is a Cocoon sitemap file that causes the aspect chain to be applied. The AspectMatcher component is where the ordering of Aspects is enforced.

As stated above, every request for a dynamic page causes the resulting document to be sent down the single Aspect chain.

The tokens like {1} represent URI text which is matched by wildcards ('*' or '**') in the nearest enclosing element's 'match' attribute. This is similar to the subexpression match variables provided by some regular expression packages. (This feature is provided by Cocoon; it is not a part of DSpace, but is used by XMLUI.)

I recommend reading up a bit on Cocoon, if you can find a good resource. I usually refer to Cocoon Developer's Handbook by Moczar and Aston. It is now outdated, but it's much more complete than the current online Cocoon documentation.

Mark Wood
  • 356
  • 1
  • 9