<lots of stuff snipped/>
*IMPORTANT* (and the reason why I started the RT):
So in he CLI, instead of asking for the link view and then generate, I simply ask Cocoon to insert a transformer that gathers links in the same positions where the links view would.
This would make it possible for the CLI to have the configurability of the view gatherer but the speed of the transfomer gatherer.
This is probably the point I'm missing.
Instead of discussion the solution, can't we start over again from the problem? maybe there are easier solutions that you didn't think about.
Well. The 'problem' is this:
By default, the CLI generates a page twice, once for the page and once for its links. This is inefficient. To work around this, I added the ability to automagically insert a LinkGatherer before the serializer. But with this you loose the configurability of the link view method. Some of this can be worked around by improving the CocoonBean, e.g. adding include/exclude capabilities, but some can't - particularly the ability to extract links from somewhere earlier in the pipeline when generating non-HTML content.
So the desire is for a way to gather links from a page that:
1) Is efficient (i.e. doesn't require complete regeneration of the page just for its links)
2) Can handle non-HTML content where links must be gathered earlier in the pipeline (and other flexibilities achievable using link view)
3) Minimal (or preferably no) change to the sitemap language
We have link view and link gathering at present. Both work, but neither of them are in themselves ideal. A link view that is efficient could replace both, as a link view can be by default configured to happen just before the serializer, which is what is currently happening with the Link Gatherer.
Vadim suggested using a tee pipe to simultaneously feed SAX events into both the remainder of the normal pipeline and into a view pipeline, and I'm continuing to reflect and explore how this could be done. It certainly wouldn't be easy, especially if you want to retain cachability. But that's getting into the area of solution, so I'll stop there.
Regards, Upayavira
