Peter Royal wrote: > > 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.
Oh, absolutely, but on second though, looking at the sitemap semantics, an 'aggregation' is just another way of 'generating' content. But since this has a specific behavior in respect of cocoon views and such, and it's widely used, it got included and people love it. It could be the same with AC (besides, Apache does this). So, let's try to come up with some AC-augmentation for the sitemap and see where this leads us to... if it turns up to be 'feasible' in terms of verbosity and additional complexity of the semantics, we'll do that, otherwise, we'll consider AC part of the general webapp modularity. Carsten, don't you have anything to say here (you are about to donate some AC logic along with your portal additions, isn't it?) > 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? Hmmm, let's see... > <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}"/> well, this is not an attribute, but an element... should be something like <ac:check> <map:generate> ... </ac:check> but this would open the door for almost anything and this scares the crap out of me. > <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/> You are comping up with a procedural language... no, I think this is heading in the wrong direction. > </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). Exactly: xml attributes don't have numbering or order for a reason and you shouldn't be using something that *does* require order using attributes. > 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. No offense intended, but I find this very ugly. :/ > 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. Oh, no problem Pete, we need to place everything on the table during RT-based brainstorms and for sure they will trigger something that will end up in the right direction. > just stirring the pot. :) yeah, that's good visuals! -- Stefano Mazzocchi One must still have chaos in oneself to be able to give birth to a dancing star. <[EMAIL PROTECTED]> Friedrich Nietzsche -------------------------------------------------------------------- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
