Guys, > The link stuff is a cross-cutting concern. This thread has IMHO shown > how aspects can be easily added to the sitemap, and effectively used. > Let's see...
> >>>- We're abusing the name 'transformer', since nothing is > >>>transformed. > >>> If we're really going to go this way, let's define a new sitemap > >>> element, <map:link-gatherer/>. > >> > >>There are transformers that do not transform, it's not unusual, > > > > I can't think of any others? > > some OTOMH, maybe not 100% correct: > > LogTransformer > XMLFormTransformer > WriteDOMSessionTransformer > SourceWritingTransformer Yup. Now, I've got an (untested) LinkGatheringTransformer ready and compiling. It shouldn't be much work to test it and get it going. > > <snip links to stuff I mostly missed - thanks> > > > >>" > >>So basically we are adding a contract to the sitemap, by saying that > >>each sitemap implementation has to provide a list of links if > >>requested to (as seen above). " > >> > >>As you state, a Transformer does not feel right. In fact, a sitemap > >>has now a new contract that it has to give links. The question is: > >>how can it be made more versatile? Who can we tell the pipeline > >>where we want the link gathering to occur? > >> > >>What about a named pipeline that is inserted by the link gatherer > >>where it gets the links? What about using a spacial label to > >>indicate where to gather links? What is a named pipeline? How would the link gatherer (or rather the bean) 'insert a named pipeline'? > > Hmm.. interesting. Perhaps we just need to augment Resources a bit: > > > > <map:resource name="gather-links" from-position="content"> > > <!-- Any required link munging --> > > <map:transformer type="gather-links"/> > > </map:resource> > > Cool, you have put my words in code, adding that last bit that makes > them worthwile :-) This really looks like some sort of final solution, > intriguing. So how does this work? I don't get it. You're specifying a resource, but presumably you're going to still have to insert it somehow? > Hmmm, it also has to do with the "named pipelines" thread, or the > pipeline==reusable_component one that Stefano had started. > > Seems like simply adding this capability to resources is nice. We > could similarly make a link-view that uses the same transformer and a > serializer. In this way it could also be compatible with the 3pass > method. Hmmm... > > > Ie, a Resource inserted in each pipeline after the 'content' label. > > Rather AOP'ish. > > Yup. As link gathering is a cross-cutting concern, it also makes sense > conceptually. So you're saying, with a resource that has a 'from-position' attribute, that specifies after which label it should be inserted? That makes sense. So you only have to have the resource once per sitemap, rather than having to insert it into every pipeline. But - what if the pipeline itself needs modifying to expose links from within PDFs for example. The LinkGatheringTransformer I have coded has two modes, one where it just hunts for href, src and xlink attributes, and the other that searches for attributes in the http://apache.org/cocoon/link-gatherer/1.0 namespace (probably to be used with a 'link' prefix). This latter kind is required for gathering links that don't conform to the href, src or xlink conventions. Just auto-inserting a link gatherer wouldn't work in this case. > The thing here is how it's called by the sitemap engine. There is no > explicit call in the pipelines, but instead a "from-position" > attribute. It could easily have also a serializer, and in this way it > would terminate all pipelines... but it's like fa view in this case... > > But a view then would become an AOPish resource with a serializer > called only on certain conditions. Let's call them aspects instead of > resources. > > So: > - <pipelines> are called per request one after the other till the > sitemap exits - <resources> are sitemap snippets called by the > pipelines - <views> are exit points that get called at a particular > label > (effectively a hard-wired AOP feature) by the sitemap > > Pipelines and resources are effectively the same thing not that there > is the cocoon protocol. > > What remains is the <views> part, that has introduce pipeline-stage > metadata, as a label. It's an aspect that gets called when that > particular condition is met (I won't use AOP terminology that I > personally don't yet like) > > So we can generalize it, and add configurability to the view mechanism > to specify other conditions. > > <map:view name="content" from-label="content"> > <map:serialize type="xml"/> > </map:view> > > becomes: > > <map:view name="content" type="from-label" > test="content"> > <map:serialize type="xml"/> > </map:view> > > This makes it possible to make a different position where to start > from... > > What can also be made configurable is *when*, in which condition, it's > triggered, but the logic has to be inverted. > > Now we say: "when the view is triggered, start at a label" > After it could be: "when the view is triggered, start at position" > Instead we need: "when the position is met, check if it has to be > triggered". > > Here is an example that uses this "inverted" AOPish system for views. > > The following adds two aspects: > - an aspect gets called from every content position and gathers > links. - the other one gets called from every content position. If > the > request has a cocoon-view=links, then the links are serialized. > > <map:aspects> > <map:aspect type="from-label" test="content"> > <!-- Any required link munging --> > <map:transformer type="gather-links"/> > </map:aspect> > <map:aspect type="from-label" test="content"> > <map:action type="request-param"> > <map:param name="cocoon-view" value="link"> > <map:serializer type="links"/> > </map:action> > </map:aspect> > </map:aspects> > > This would make it very easy to add security-based checks, logging, or > any other stuff. > > <map:aspects> > <map:aspect type="pipeline" test="start"> > <map:action type="check-security"/> > </map:aspect> > <map:aspect type="pipeline" test="all"> > <map:transformer type="logger"/> > </map:aspect> > <map:aspect type="error" test="all"> > <map:action type="notify-admin"/> > </map:aspect> > </map:aspects> > > What do others think? > > Is it already possible to do this today with other components and > skillful pipeline writing? For doing it at the beginning or at the end > of a request it's possible to have an entry-point pieline that has pre > and post processing, but to add stuff *inside* other pipelines? I > think it cannot be done today. I'm afraid you left me completely behind there. I've not really yet understood what AOP is, and your ideas go far further than my Cocoon implementation skills currently allow. I'd quite like to find something that can be implemented reasonably short term, and then explore these more far-reaching ideas as time passes (and as the size and capacity of my brain increases). Are you guys interested for the time being in a LinkGatheringTransformer as described above? Or is there something not too far away that we can do now to gather links? Regards, Upayavira
