Nicola Ken Barozzi wrote:
>From: "Sylvain Wallez" <[EMAIL PROTECTED]>
>
>>Hi team,
>>
>>I looked at Chris's modules in mod-db and thought about using them for
>>sitemap variable substitution.
>>
>>Up to now, sitemap variables can only be set by matchers and actions,
>>and we thus have a number of them whose primary purpose is to populate
>>sitemap parameters. This includes e.g. RequestParamAction,
>>RequestHeaderMatcher, SessionAttributeMatcher, etc.
>>
>>Now what about allowing the use of InputModules in sitemap variable
>>substitution ? For this, we need to extend the variable naming scheme :
>>if a variable name contains a colon (':'), the string before the colon
>>identifies an InputModule, and the string after the colon identifies an
>>attribute name for the InputModule (see InputModule.getAttribute())
>>
>>So the following snippet (copied from RequestParamAction javadoc) :
>> <map:act type="request">
>> <map:parameter name="parameters" value="true"/>
>> <map:generate src="users/menu-{id}.xml">
>> </map:act>
>>
>>could be written more simply :
>> <map:generate src="users/menu-{request-param:id}.xml"/>
>>
>
>It doesn't bring new functionality, creates duplicate ways of doing the
>*same* thing, and breaks compatibility with old sitemap.
>All this in favor of a more compact syntax.
>
Wow, this is harsh !
My opinion is that it brings more *usability* in the sitemap, since
there is currently no *simple* way to substitute anything else than
sitemap variables. This led to what I consider to be a degenerate use of
matchers and actions to populate these variables.
A developper here once asked me "My app has a parameter in web.xml which
is a directory containing application data. How can I get its value in
the 'src' attribute of a map:generate ?". My answer was to write a dummy
action that populates a sitemap variable. He (and I) found that
counter-intuitive and leading to hardly-readable sitemaps.
Concerning compatibility, the colon separator is just a proposal, and we
have to see if anybody already uses it. If some people do, there are
other possible syntaxes, such as "attaching" module substitution to the
root of the variable tree, i.e. "menu-{/request-param:id}.xml". Since
'/' is currently used to travel up the hierarchy, I'm pretty sure nobody
uses it as the first character of variable names.
>What I would like to see instead, is a ModularAction, that can pass
>attributes from inputmodules and output modules, and ModularMatcher and
>ModularSelector, that can, in this way, have a common codebase and
>functional opportunity.
>
This is good, but serves other purposes, as Matchers and Selectors
direct the pipeline construction by *testing* some values and giving
back some derived values (such as the matched wildcards) as sitemap
variables.
Substitution using InputModules serves to *access* some values when we
*must* have their value and no fallback exists.
In the above snippet, if "id" isn't present, you end up with a "Resource
not found : users/menu-.xml". Even worse if the action tests for the
existence of the parameter, you would obtain an "Attempting to process
an incomplete pipeline" since the generator wouldn't be added to the
pipeline. With InputModules substitution, you can obtain a more
meaningfull "Cannot get value for 'request-param:id' at sitemap.xmap,
line 342".
>Decoupling Sources from Generators seems like decoupling Modules from
>Matchers and Selectors.
>
Agree, as this decouples the usage of data from where it comes from :
- Generators produce SAX events out of a byte stream obtained by a
Source (the new SWFGenerator is the perfect example of this),
- Matchers and Selectors perform some tests on a value obtained from an
InputModule to direct pipeline construction.
Sylvain
--
Sylvain Wallez
Anyware Technologies Apache Cocoon
http://www.anyware-tech.com mailto:[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
