cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giacomo Pati <pati_giac...@yahoo.com>
Subject [C2]Action proposal (long)
Date Wed, 08 Nov 2000 14:52:43 GMT
Hi all

I'd like to thank you all for patiently waiting for this proposal.
I know I was very ternse the last days. This is because I'm have 
to finish some projects apart from Cocoon.

Action proposal

Let me give a brief introduction to the sitemap concepts because,
as fullfilling a "last wish" from Stefano, I'll cross post this to
Jon Stevens (Turbine), Santiago Gala (Jetspeed) and Peter Donald
(Avalon) as well. It's up to them to further post it to their lists
if they think it's appropriate and share the discussions with us
which I would really appreciate because there is specific know how in
the web app domain we are touching here.

I further recommend reading the
xdocs/draft/sitemap-working.draft.xmap in the Cocoon2 cvs to have a
deeper explanation of what I'm reflecting here and the thread with
subjects "Action proposal" we had on the cocoon-dev list around
September 15 this year.

-------------------------------- O --------------------------------

The structure of the sitemap as for today is divided into the 
following sections:

	components
	views
	resources
	action-chains
	pipelines

Of special interest for this Action proposal are the components,
action-chains and pipelines sections which I'll explain now.

The components section is used to declare which components are used
in the sitemap context. Today we have the components

	generators
	transformers
	serializers

which all are responsible to produce a resource (a View in the MVC
context). These component are collected in the pipelines section and
connected together in a SAX pipeline

	generator-SAX->transformer-SAX-[transformer]*-SAX->serializer

There is also a reader component which is a combination of a
generator and a serializer to eliminate the need of a SAX pipeline
between these component. This component is used to produce "as is"
views which cannot be passed thru a SAX pipeline (i.e.
images, static html files, CSS files etc.)

The remaining components beside the Action components are

	matchers
	selectors

These components are used to "match" on request events using
"patterns" and "select" resource
generation/transformation/serialisation/reading components based on
"tests" to build up the SAX pipeline. These two components together
with the sitemap itself build the Controller part of a MVC
model.

Matchers have the ability to deliver information they matched up
back to the sitemap engine which the sitemap engine uses to replace
occurences of placeholders in specific attributes of sitemap tags.
Ok here is a brief example:

	<match type="uri" pattern="news/*/today/*">
	  <generate type="file" src="mydir/{1}/today/{2}.xml"/>
	</match>

Here the strings representing the "*" in the pattern are returned
by the uri-matcher to the sitemap engine and what ever was there
during request time is used to replace the "{1}" and the "{2}" in
the src attribute and then passed to the file-generator.

NOTE: This is a special behaviour of the uri-matcher. Other matchers 
      could return values not visible in the sitemap like the example
      above (pattern attribute). This leads to discussing an 
      implementational detail which affects the interface of a 
      Matcher to change its return type from List to Map.

It is also possible to nest Matchers. To reference returned values
of those Matcher we use a XPath like syntax:
	
	<match type="uri" pattern="news/*/today/*">
      <generate type="file" src="files/{1}/today/{2}.xml"/>
	  <match type="param" pattern="style">
	    <transform type="xslt" src="stylesheets/{../1}/{style}.xsl"/>
      </match>
	</match>
	
Here the Matcher of type "param" returns the value of the "style"
parameter named as "style" to the sitemap. The values returned from
the uri Matcher is references as {../1}.

NOTE: To be able to refer values like {style} in the example above 
      it is necessary to change the return type of the match method in 
      the Matcher interface from List to Map (see note above).

Selectors are used to choose components to build up the SAX
pipeline according to usually environmental circumstances. Here a
brief example:

	<select type="browser">
        <when test="lynx">
          <transform src="stylesheets/lynx.xsl"/>
        </when>
        <when test="netscape">
          <transform src="stylesheets/netscape.xsl"/>
        </when>
        <otherwise>
          <transform src="stylesheets/general.xsl"/>
        </otherwise>
      </select>

The only information a selector returns to the sitemap engine is a
boolean value representing the result of the test in the <when> tag.

But there is no component that deals with modifying the state of
your application model. Using an XSP page because you can integrate
logic in it is IMO wrong.

Mime
View raw message