Hi all.
The attached patch adds the ability to specify a "target" in a
<map:redirect-to resource=""> tag. The "target" is available as "{1}"
in the resource specification.
Example
<map:resources>
<map:resource name="simple-page">
<map:generate type="serverpages" src="test/{1}.xsp"/>
<map:transform src="stylesheets/presentation.xsl"/>
<map:transform src="stylesheets/dynamic-page2html.xsl"/>
<map:serialize/>
</map:resource>
</map:resources>
<map:pipelines>
<map:pipeline>
<map:match pattern="test">
<map:act type="form-validator">
<map:parameter name="descriptor" value="context:///descriptor.xml"/>
<map:parameter name="validate-set" value="user-input"/>
<map:redirect-to resource="simple-page" target="OK"/>
</map:act>
<map:redirect-to resource="simple-page" target="ERROR"/>
</map:match>
</map:pipeline>
</map:pipelines>
This way it is only necessary to specify required transformation steps
only in one place. A redirection to a URL wouldn't work here as that
would create a new request object which discards some values. In
addition resources are not accessible from outside.
Implementation
Since maps (listOfMaps) is handed to resources, a new map is added to
the listOfMaps with just one entry ("1","@target").
Rationale
A thing called "flowmap" has been discussed on this list for a long
time. Recently I felt the need for such a thing as well. Anyway, it
was not clear enough for me in which aspects a flowmap will differ from
the sitemap. All in all I believe all the functionality for a flowmap
is already present in the sitemap concept.
As far as I am concerned, a sitemap would care about the URI mapping
and transformation steps. A flowmap would be a XML representation of a
state chart with states, sub states, transitions, triggers, guards and
actions.
States can be represented by matchers, sub states by nested
matchers. Triggers are requests (request parameters) which could be
represented by selectors. Transitions are allowed paths to other URIs
or resources, guards can be realized by cocoon-actions with nested
content and actions, well be be realized by cocoon-actions.
This way every resource would need a separate definition.
The patch allows to redirect to a common definition for
transformation. So those two different concerns are separated, even if
they live in the same file. Since resources from ancestor sitemaps can
be accessed, this could be split up to that resources are only defined
in the top level sitemap.
Comments?
Chris.
PS: I hope to offer a matcher based on session state shortly. This way
not the requested page is matched but the state that the application
believes the user should be in. Stay tuned.
--
C h r i s t i a n H a u l
[EMAIL PROTECTED]
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
? build
Index: src/org/apache/cocoon/components/language/markup/sitemap/java/sitemap.xsl
===================================================================
RCS file:
/home/cvspublic/xml-cocoon2/src/org/apache/cocoon/components/language/markup/sitemap/java/sitemap.xsl,v
retrieving revision 1.17
diff -u -r1.17 sitemap.xsl
--- src/org/apache/cocoon/components/language/markup/sitemap/java/sitemap.xsl
2001/06/19 11:56:56 1.17
+++ src/org/apache/cocoon/components/language/markup/sitemap/java/sitemap.xsl
+2001/06/20 12:31:48
@@ -1169,6 +1169,11 @@
<!-- redirect to a internal resource definition -->
<xsl:when test="@resource">
+ <xsl:if test="@target">
+ map = new HashMap(1);
+ map.put("1","<xsl:value-of select="@target"/>");
+ listOfMaps.add(map);
+ </xsl:if>
Class[] argTypes = new Class[] {StreamPipeline.class, EventPipeline.class,
List.class, Environment.class, String.class, Boolean.TYPE};
Object[] argValues = new Object[] {pipeline, eventPipeline, listOfMaps,
environment, cocoon_view, new Boolean(internalRequest)};
String methodName = "resource_" + substitute(listOfMaps, "<xsl:value-of
select="translate(@resource, '- ', '__')"/>");
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
