On Wednesday 06 February 2002 07:06 pm, Stefano Mazzocchi wrote:
> my personal opinion is that I don't see anything that justifies the
> inclusion of AC at the sitemap level since AC is just another action.
i agree. it would make a great pluggable webapp though.
a "blocklet" if you will; some actions, transformers and maybe a custom
protocol handler could do it all. AC might be a great first candidate for
hammering out a component app API. (which could maybe be applied via
namedspaced attributes against the standard sitemap language?
<map:sitemap>
<map:components>
<map:blocklets>
<map:blocklet xmlns:ac="http://apache.org/cocoon/ac/1.0";
src="org.apache.cocoon.blocklet.ac.accesscontrol.sitemap.xmap"/>
</map:blocklets>
</map:components>
<map:pipelines>
<map:pipeline>
<map:match pattern="protected/**">
<map:generate src="context://secret/**" ac:check="{1}"/>
<map:transform>
...etc...
</map:match>
</map:pipeline>
</map:pipelines>
</map:sitemap>
then in org.apache.cocoon.blocklet.ac.accesscontrol.sitemap.xmap
<map:sitemap>
<map:components>
...standard stuff...
</map:components>
<map:pipelines>
<map:pipeline name="check">
<map:parameter name="resource"/> <!-- i don't know what to call this, but
similar to xsl:param, declaring a parameter name -->
<map:act type="check-logged-in">
<map:act type="can-read-resource">
<map:parameter name="username" value="{username}"/>
<map:parameter name="resource" value="{../resource"/>
<map:return/>
</map:type>
<map:call resource="access-denied"/>
</map:act>
<map:call resource="login">
<map:parameter name="requested-resource" value="resource"/>
</map:call>
</map:pipeline>
</map:pipelines>
</map:sitemap>
ok, only a couple new sitemap constructs here. we have map:blocklet at the
top, which defines the access controller, giving it a namespace to act in.
the src attribute points to another sitemap that defines the blocklet's
actions.
the blocklet is called when a namespaced attribute appears. the blocklet
would be called before the generate. (potential pitfall: multiple blockets on
a single element, what order are they called, no xml contract for attribute
ordering afaik). the name of the attribute corresponds to the name of a
pipeline in the blocklet sitemap. parameters could be passed either by the
attribute contents or via the implicit parameter maps of the sitemap. in the
first case, maybe declaring map:parameter elements under a pipeline could
signify the order the attributes are. (the implicit params might be best..)
then you would basically drop into a pipeline in the blocklet sitemap. the
only new element there is a map:return element which would return control to
the original sitemap.
rules on a blocklet pipeline could be relaxed, generators and serializers not
required, so a blocklet call could be placed in the middle of a pipeline
(think skin, the main contract would be an xml scheme contract, but you could
also pass parameters to the blocklet setup in the initial sitemap, maybe
there
passing in the skins you want to use to the skin engine).
rough ideas really. seems to jump out a bit more at me as far as seeming
simple on the top. some of your previous example sketches didn't immediately
'click' in my head, but i may just need to stare at them a bit more.
just stirring the pot.
-pete
--
peter royal -> [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
