You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by Ferdinand Soethe <sa...@soethe.net> on 2005/05/22 11:48:47 UTC
New Plugin: Filtering output
Working on our presentation for ApacheCon, Ross and I have the problem
that the presentation contains a lot of internal info and also some
that should only be part of someversions (speaker version, slide
version, printed notes).
They are marked up with class attributes, so filtering is possible,
the question is where.
And since filtering might vary on a per document basis, I was
wondering whether we could have a filtering plugin that can be applied
before any other output plugin and apply the filtering needed.
Ideally the criteria would be defined in the site element.
So instead of my current version (that opens the presentation as a
normal Forrest document as well as an s5-slideshow)
<apachecon label="ApacheCon">
<slides label="slides" href="s5slides/ssp_with_forrest.html"/>
<slides label="document" href="ssp_with_forrest.html"/>
</apachecon>
I could then have
<apachecon label="ApacheCon">
<slides label="Slides" href="s5slides/ssp_with_forrest.html"
filter="cleanSlides.xsl"/>
<slides label="Slides" href="s5slides/ssp_with_forrest.html"
filter="speakerSlides.xsl"/>
<slides label="document" href="ssp_with_forrest.html"
filter="printedVersion.xsl"/>
</apachecon>
where the xsl-files contain the desired filter.
Am I thinking along the right track here or are there better ways to
do this.
I first wanted to create this as output plugin, but since all there is
is custom xsl which can be different for each file, I didn't think
this would made a lot of sense.
--
Ferdinand Soethe
Re: New Plugin: Filtering output
Posted by Ferdinand Soethe <sa...@soethe.net>.
Johannes Schaefer wrote:
> Ideally the reader can adjust the filtering, like: give
> me all information about version A; give me my information
> about versions A, B, D. The information about this is
> in the specialized markup, so, theoretically it can be
> done.
Yes, I'd like that as an option. Though sometimes you want that, other
times you don't.
> Our "writers" don't care about filtering, they provide
> the full information anyway (each one his/her bit).
> It's the "admin" or "publisher" who creates the published
> version(s).
If you call it publisher or editor I agree. But these are
also content workers and not techies in most businesses I know.
--
Ferdinand Soethe
Re: New Plugin: Filtering output
Posted by Johannes Schaefer <jo...@uidesign.de>.
Just another use case and some more RTs.
We are writing styleguides with forrest.
Application developers need less information than
component developers, so we are offering different
versions for both. Now we do this with two separate
project sitemaps to create the (static) output.
We would happily adopt some "live" filtering.
In our case it's more like we do know what info is not
needed for a specific user group and so we drop it in a
first transformation step (i.e. from a specialized DTD to
DocBook). Thus the filtering applies only to specialized
parts of the document (e.g. matches **-ABC.html) and the
rest is handled normally. There is no special markup
(like class="dirCut"/"actorCut").
Ideally the reader can adjust the filtering, like: give
me all information about version A; give me my information
about versions A, B, D. The information about this is
in the specialized markup, so, theoretically it can be
done.
Our "writers" don't care about filtering, they provide
the full information anyway (each one his/her bit).
It's the "admin" or "publisher" who creates the published
version(s).
We would like to do 'forrest run' and access the
versions using the same instance, e.g. like
http://localhost:8888/app-dev/ and
http://localhost:8888/core-dev/
(see also: http://issues.cocoondev.org/browse/FOR-490)
I'd agree with Ross, that this is not a output/skinning
step, but an internal one. For us it would be sooner than
xdoc->skin because it'll be hard to preserve all the
semantics up to the xdoc-format.
Cheers
Johannes
Ferdinand Soethe schrieb:
> Two quick responses since I'm still working on the apachecon
> presentation:
>
> - I'm happy for this to be a part of views and I hope after apachecon
> I'll know how to use them for this purpose.
>
> - I agree that the filter could and perhaps should be configured as
> part of the configuration.
>
>
>>...and content writer != admin (site.xml)
>
>
> - I do not agree that editing site.xml is admin work as Thorsten
> seems to suggest since it is the only way a user can make Forrest
> show his page.
>
> - And since I (with the content writer hat) usually make the decisions about
> which file to show in which menu and what filter should be applied
> to it (e.g. show the directors version of Shakespeare in my 'Directors
> resources' menu while the full version is in the 'Popular
> Dramas') I (user) need a way simply apply a filter to a given
> resource.
>
> To determine which filters to apply to which resources (by the list of
> patterns in the plugin config that Ross suggested) does not seem an
> ideal solution to me as it requires an understanding of patterns
> that users don't usually have and also makes it much harder to see
> what will actually the outcome of a certain site.xml (because you
> have to also look at the filter patterns in the plugin (and apply
> that knowledge to site) to know what will actually show.
>
> Very difficult and not easy to maintain.
>
> I understand the objective not to extend site-grammar for every new
> plugin (and share it), but I'd raise the question if it wouldn't be a
> good idea to consider it at least for some basic operations like
> filtering, pdf-aggregation and ...
>
> And if that is not agreeable, to find some other way of keeping the
> selection of a given filter closely with the site-element.
>
> --
> Ferdinand Soethe
>
>
--
User Interface Design GmbH * Teinacher Str. 38 * D-71634
Ludwigsburg
Fon +49 (0)7141 377 000 * Fax +49 (0)7141 377 00-99
Geschäftsstelle: User Interface Design GmbH *
Lehrer-Götz-Weg 11 * D-81825 München
www.uidesign.de
Buch "User Interface Tuning" von Joachim Machate & Michael
Burmester
www.user-interface-tuning.de
Re: New Plugin: Filtering output
Posted by Ferdinand Soethe <sa...@soethe.net>.
Two quick responses since I'm still working on the apachecon
presentation:
- I'm happy for this to be a part of views and I hope after apachecon
I'll know how to use them for this purpose.
- I agree that the filter could and perhaps should be configured as
part of the configuration.
> ...and content writer != admin (site.xml)
- I do not agree that editing site.xml is admin work as Thorsten
seems to suggest since it is the only way a user can make Forrest
show his page.
- And since I (with the content writer hat) usually make the decisions about
which file to show in which menu and what filter should be applied
to it (e.g. show the directors version of Shakespeare in my 'Directors
resources' menu while the full version is in the 'Popular
Dramas') I (user) need a way simply apply a filter to a given
resource.
To determine which filters to apply to which resources (by the list of
patterns in the plugin config that Ross suggested) does not seem an
ideal solution to me as it requires an understanding of patterns
that users don't usually have and also makes it much harder to see
what will actually the outcome of a certain site.xml (because you
have to also look at the filter patterns in the plugin (and apply
that knowledge to site) to know what will actually show.
Very difficult and not easy to maintain.
I understand the objective not to extend site-grammar for every new
plugin (and share it), but I'd raise the question if it wouldn't be a
good idea to consider it at least for some basic operations like
filtering, pdf-aggregation and ...
And if that is not agreeable, to find some other way of keeping the
selection of a given filter closely with the site-element.
--
Ferdinand Soethe
Re: New Plugin: Filtering output
Posted by Thorsten Scherler <th...@apache.org>.
On Sun, 2005-05-22 at 12:59 +0100, Ross Gardler wrote:
> Ferdinand Soethe wrote:
> > Working on our presentation for ApacheCon, Ross and I have the problem
> > that the presentation contains a lot of internal info and also some
> > that should only be part of someversions (speaker version, slide
> > version, printed notes).
> >
> > They are marked up with class attributes, so filtering is possible,
> > the question is where.
> >
> > And since filtering might vary on a per document basis, I was
> > wondering whether we could have a filtering plugin that can be applied
> > before any other output plugin and apply the filtering needed.
>
> Interesting.
>
> This allows us to define a different versions of the content of a page.
> That is some content will not be displayed. I actually have another use
> case for this. I have the full works of Shakespeare ,marked up as XML, I
> want to be able to provide directors output (stage directions, and
> director notes), actor versions (dialogue and actor cues) etc.
>
Jumping in right here, with other words that means that in your
Shakespeare you have some kind of markup to state which paragraph or
sentence should go into the directors output and which in the actor
versions, right?
Maybe something like
<p class="dirCut">...</p>
<p class="actorCut">...</p>
> However, since this is only an extension to the skin I suspect there
> will be considerable overlap with Thorstens work on views. Thorsten, any
> comments on how this would overlap with your vision for Forrest:views?
>
That leads use to the logic:tag that I mentioned the other day (ross was
talking about role specific views and I mentioned this logic tags -
maybe somebody can provide a link I could not found it). In my recent RT
you can find: xmlns:logic="http://apache.org/forrest/logic/1.0"
I used this in the inx plugin to make a decision what contract to
include based on parameters (or bean properties). The actual use-case
was that a catalog can either have 4 or 8 page and the processing had
some marginal differences.
Here is a snippet demonstrating this:
<forrest:hook name="page" count="4">
<logic:lastPage value="4">
<forrest:contract type="img" name="top-image-bit-last"
objectId="411"/>
<forrest:contract type="txt" name="footer-l-text" objectId="441"/>
</logic:lastPage>
<logic:lastPage value="8">
<forrest:contract type="img" name="top-image-bit" objectId="411"/>
<forrest:contract type="txt" name="footer-r-text" objectId="441"/>
</logic:lastPage>
<forrest:fbits name="infobits" count="4"/>
</forrest:hook>
This could be used for marginal differences in the page.
If the processing or the containing contracts are very different
something like the following I reckon would be more appropriate:
<forrest:views xmlns:forrest="http://apache.org/forrest/templates/1.0"
xmlns:logic="http://apache.org/forrest/logic/1.0">
<logic:filter value="dirCut" parameter="p">
<forrest:view format="inx" />
</logic:filter>
<logic:filter value="actorCut" parameter="p">
<forrest:view format="inx" />
</logic:filter>
I just altered the logic tag. Like I stated as well in RT the inx plugin
still has some specific business logic. The logic:lastPage is an
example. Better would be something more generic like <logic:filter
value="" parameter=""/>.
> > Ideally the criteria would be defined in the site element.
> >
> > So instead of my current version (that opens the presentation as a
> > normal Forrest document as well as an s5-slideshow)
> >
> > <apachecon label="ApacheCon">
> > <slides label="slides" href="s5slides/ssp_with_forrest.html"/>
> > <slides label="document" href="ssp_with_forrest.html"/>
> > </apachecon>
> >
> > I could then have
> >
> > <apachecon label="ApacheCon">
> > <slides label="Slides" href="s5slides/ssp_with_forrest.html"
> > filter="cleanSlides.xsl"/>
> > <slides label="Slides" href="s5slides/ssp_with_forrest.html"
> > filter="speakerSlides.xsl"/>
> > <slides label="document" href="ssp_with_forrest.html"
> > filter="printedVersion.xsl"/>
> > </apachecon>
> >
> > where the xsl-files contain the desired filter.
>
> I wouldn't define it in site.xml,
>
+1
>
> I would define it in a plugin
> configuration.
>
If you consider the view as config. +1
>
> For example:
>
> <filters>
> <document href="ssp_with_forrest.s5.html" filter="cleanSlides.xsl"/>
> <document href="ssp_with_forrest.s5.html" filter="speakerSlides.xsl"/>
> ...
> </filters>
>
> (NOTE my change to using the s5.html extension is planned for the s5
> plugin and becomes necessary to achieve the following)
>
> The reasons for having it in a config file are numersous:
>
> 1) a plugin cannot mess with an internal format DTD (we don't currently
> have one for site.xml so at present that's not a problem, but if we did
> go that way it would be)
>
> 2) it would allow us to provide more granular control over the filters
>
> 3) It would allow filter chains.
>
> For example:
>
> <filters>
> <document href="**.s5.html" filter="stripDetail.xsl"/>
> <document href="speaker.s5.html" filter="speakerSlides.xsl"/>
> ...
> </filters>
>
I would do like above mentioned with Shakespeare.
Thing about the content writer (s)he will know where the content belongs.
...and content writer != admin (site.xml)
>
> > I first wanted to create this as output plugin, but since all there is
> > is custom xsl which can be different for each file, I didn't think
> > this would made a lot of sense.
>
> This would not be an output plugin. The reason being that this
> processing *has* to occur at a specific point in the pipeline, i.e.
> after conversion to XDoc and before skinning, output plugins come after
> the skinning stage.
>
>
> Consequently, this proposal would have to override
> some of the core pipelines in Forrest, hence it is an Internal plugin
> (that's the clearest definiiton yet of what an Internal plugin is, I think).
>
> Ross
>
Yes, Ross is right:
http://svn.apache.org/viewcvs.cgi/*checkout*/forrest/trunk/site-author/content/xdocs/docs/TR/2004/WD-forrest10.html
Step 3: Filtering (content)
Actually the filtering should IMO happen and controlled in the view dispatcher (configured by the *.fv).
It is part of the dispatcherView concept. Actually filtering IMO is part of my recent RT.
The filtering should further be done by simple logic matches that define conditions that have to be
matched to display the content (or better said contract). The filter of
<document href="ssp_with_forrest.s5.html" filter="cleanSlides.xsl"/> is per definition (my personal) a contract
because it is processing special parts of the content. To capsule the filter="cleanSlides.xsl" within a contact
makes is easier to reuse and define new ones in different views.
The view is (can be) document specific that means IMO the filtering *has to* be part of the view package.
Here you define which business and view helper are needed.
The filtering stage is within the business helper part of the dispatcher view pattern.
WDYT?
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: New Plugin: Filtering output
Posted by Ross Gardler <rg...@apache.org>.
Ferdinand Soethe wrote:
> Working on our presentation for ApacheCon, Ross and I have the problem
> that the presentation contains a lot of internal info and also some
> that should only be part of someversions (speaker version, slide
> version, printed notes).
>
> They are marked up with class attributes, so filtering is possible,
> the question is where.
>
> And since filtering might vary on a per document basis, I was
> wondering whether we could have a filtering plugin that can be applied
> before any other output plugin and apply the filtering needed.
Interesting.
This allows us to define a different versions of the content of a page.
That is some content will not be displayed. I actually have another use
case for this. I have the full works of Shakespeare ,marked up as XML, I
want to be able to provide directors output (stage directions, and
director notes), actor versions (dialogue and actor cues) etc.
However, since this is only an extension to the skin I suspect there
will be considerable overlap with Thorstens work on views. Thorsten, any
comments on how this would overlap with your vision for Forrest:views?
> Ideally the criteria would be defined in the site element.
>
> So instead of my current version (that opens the presentation as a
> normal Forrest document as well as an s5-slideshow)
>
> <apachecon label="ApacheCon">
> <slides label="slides" href="s5slides/ssp_with_forrest.html"/>
> <slides label="document" href="ssp_with_forrest.html"/>
> </apachecon>
>
> I could then have
>
> <apachecon label="ApacheCon">
> <slides label="Slides" href="s5slides/ssp_with_forrest.html"
> filter="cleanSlides.xsl"/>
> <slides label="Slides" href="s5slides/ssp_with_forrest.html"
> filter="speakerSlides.xsl"/>
> <slides label="document" href="ssp_with_forrest.html"
> filter="printedVersion.xsl"/>
> </apachecon>
>
> where the xsl-files contain the desired filter.
I wouldn't define it in site.xml, I would define it in a plugin
configuration. For example:
<filters>
<document href="ssp_with_forrest.s5.html" filter="cleanSlides.xsl"/>
<document href="ssp_with_forrest.s5.html" filter="speakerSlides.xsl"/>
...
</filters>
(NOTE my change to using the s5.html extension is planned for the s5
plugin and becomes necessary to achieve the following)
The reasons for having it in a config file are numersous:
1) a plugin cannot mess with an internal format DTD (we don't currently
have one for site.xml so at present that's not a problem, but if we did
go that way it would be)
2) it would allow us to provide more granular control over the filters
3) It would allow filter chains.
For example:
<filters>
<document href="**.s5.html" filter="stripDetail.xsl"/>
<document href="speaker.s5.html" filter="speakerSlides.xsl"/>
...
</filters>
> I first wanted to create this as output plugin, but since all there is
> is custom xsl which can be different for each file, I didn't think
> this would made a lot of sense.
This would not be an output plugin. The reason being that this
processing *has* to occur at a specific point in the pipeline, i.e.
after conversion to XDoc and before skinning, output plugins come after
the skinning stage. Consequently, this proposal would have to override
some of the core pipelines in Forrest, hence it is an Internal plugin
(that's the clearest definiiton yet of what an Internal plugin is, I think).
Ross
Re: Locationmaps and Lenya integration
Posted by Thorsten Scherler <th...@apache.org>.
On Wed, 2005-05-25 at 19:51 -0400, Gregor J. Rothfuss wrote:
> Ross Gardler wrote:
>
> > I'm going to come back to this after we have submitted the Apachecon
> > presentation. I'd like to see how Thorstens work integrates with
> > locationmap as that is the next thing I need in Forrest. It makes using
> > things like Daisy or Lenya far easier and may be the ideal place for
> > view configurations like this one. I'll catch up with Thorstens recent
> > RT's and try and bring the locationmap idea into them.
>
> hmm, can you explain this a bit more? i haven't followed the list very
> closely and would appreciate a quick summary as to how this could
> improve said integration?
>
> forgive me my ignorance, but when i see things like
>
> <forrest:views xmlns:forrest="http://apache.org/forrest/templates/1.0"
> xmlns:logic="http://apache.org/forrest/logic/1.0">
> <logic:filter value="dirCut" parameter="p">
> <forrest:view format="inx" />
> </logic:filter>
> <logic:filter value="actorCut" parameter="p">
> <forrest:view format="inx" />
> </logic:filter>
>
> i am wondering if forrest is moving into a direction of 'programming in
> xml'.
Do you see CForms as well as 'programming in xml'?
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: [Proposal] remove views from forrest (Re: Views as a Domain
Specific Language)
Posted by Thorsten Scherler <th...@apache.org>.
Sorry!
On Mon, 2005-05-30 at 11:16 +1000, David Crossley wrote:
> Thorsten, stop! We already said a while ago that we love your work
> with views. We also said that we cannot afford for our attention
> to be distracted at this stage. We agreed to work towards getting
> the 0.7 release finished before we can concentrate on views.
> The problem is that only a few committers are helping to get the
> release finished. Those delays are now causing pressure.
>
> --David
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: [Proposal] remove views from forrest (Re: Views as a Domain Specific Language)
Posted by David Crossley <cr...@apache.org>.
Thorsten, stop! We already said a while ago that we love your work
with views. We also said that we cannot afford for our attention
to be distracted at this stage. We agreed to work towards getting
the 0.7 release finished before we can concentrate on views.
The problem is that only a few committers are helping to get the
release finished. Those delays are now causing pressure.
--David
Re: [Proposal] remove views from forrest (Re: Views as a Domain
Specific Language)
Posted by Ross Gardler <rg...@apache.org>.
Nicola Ken Barozzi wrote:
> Thorsten Scherler wrote:
> ...
>
>> On Fri, 2005-05-27 at 11:39 +0100, Ross Gardler wrote:
>
> ...
>
>>> So in conclusion, I agree with Gregors concerns, but I also agree
>>> with the direction Thorsten is trying to go in.
>>
>>
>> Actually that is the reason why I am proposing that forrest is *not*
>> officially developing views anymore.
Woaahhhh!!!!
It's very late for me now, I've had many beers and a bottle of wine so I
am not about to try and sort this mess out now. However....
Thorsten, please listen to Nicola Ken's very wise words below
(inparticular the first part - "please reconsider".
I'll explain my original comments in detail tomorrow - for now I hope it
is enough to say you have misinterpreted the intent of my mail.
Ross
>
> Please reconsider. You are getting unnecessarily carried away by your
> emotion. Don't mistakenly read mails as if they were personal complaints
> when they are not.
>
> ...
>
>> I do not see that it get accepted better said it is causing confusion
>> and concerns by user.
>
>
> Let me be brutally honest with you, as you are being so too with this mail.
>
> Forrest needs a view system that is better than the current skins, and
> what you are doing is generally in line with what I have in mind. You
> like it, you have passion, and this is good.
>
> On the other hand, your descriptions of the system are sometimes totally
> incomprehensible. If I hadn't seen the code and did not have a similar
> concept in mind, I think I would have not understood.
>
> I think it's about time that I check out your work and give you
> feedback. Where do I start?
>
Re: [Proposal] remove views from forrest (Re: Views as a Domain
Specific Language)
Posted by Ross Gardler <rg...@apache.org>.
Thorsten Scherler wrote:
> On Sun, 2005-05-29 at 16:02 +0200, Nicola Ken Barozzi wrote:
>
>>Thorsten Scherler wrote:
>>...
>>
>>>On Fri, 2005-05-27 at 11:39 +0100, Ross Gardler wrote:
>>
>>...
>>
>>>>So in conclusion, I agree with Gregors concerns, but I also agree with
>>>>the direction Thorsten is trying to go in.
>>>
>>>Actually that is the reason why I am proposing that forrest is *not*
>>>officially developing views anymore.
>>
>>Please reconsider. You are getting unnecessarily carried away by your
>>emotion. Don't mistakenly read mails as if they were personal complaints
>>when they are not.
>>
>
>
> Ok, I did not meant to do that but it seems I did. Sorry!
>
> I was *not* *recommending* it but was *offering* to do so because I
> thought that is maybe the best for forrest.
Thank goodness it is "an offer", that implies we have a choice, my
choice is to not accept your offer. We need views, but we (the other
devs) need to spend more time understanding it.
(as promised I will explain my original comments when I have a clearer
head).
Ross
Re: [Proposal] remove views from forrest (Re: Views as a Domain
Specific Language)
Posted by Thorsten Scherler <th...@apache.org>.
On Sun, 2005-05-29 at 16:02 +0200, Nicola Ken Barozzi wrote:
> Thorsten Scherler wrote:
> ...
> > On Fri, 2005-05-27 at 11:39 +0100, Ross Gardler wrote:
> ...
> >>So in conclusion, I agree with Gregors concerns, but I also agree with
> >>the direction Thorsten is trying to go in.
> >
> > Actually that is the reason why I am proposing that forrest is *not*
> > officially developing views anymore.
>
> Please reconsider. You are getting unnecessarily carried away by your
> emotion. Don't mistakenly read mails as if they were personal complaints
> when they are not.
>
Ok, I did not meant to do that but it seems I did. Sorry!
I was *not* *recommending* it but was *offering* to do so because I
thought that is maybe the best for forrest.
> ...
> > I do not see that it get accepted better said it is causing confusion
> > and concerns by user.
>
> Let me be brutally honest with you, as you are being so too with this mail.
>
:) That is the best. ;-)
> Forrest needs a view system that is better than the current skins, and
> what you are doing is generally in line with what I have in mind. You
> like it, you have passion, and this is good.
>
> On the other hand, your descriptions of the system are sometimes totally
> incomprehensible. If I hadn't seen the code and did not have a similar
> concept in mind, I think I would have not understood.
>
Maybe you can help to describe what views is trying to do.
I know that you are working on a similar concept maybe you can write it down
and I can use it to implement it. Like you notice it seems that I badly
failed to describe it in an easy way.
My biggest problem (I guess) is that I am not trying to solve a subset of
problems but tackle more and more problems with the implementation.
It would be awesome if you can help me again as you did with my first skin and
set some simple basics goals (do's - don't's) to focus the work of views.
>
> I think it's about time that I check out your work and give you
> feedback. Where do I start?
>
Actually you just did. ;-) It would help that you can firstly write down
your thoughts of the view concept and maybe have a look in the
processing of the xhtml. I do not like the way I produce the final
xsl-stylesheets because I am using dynamic cocoon:// includes to produce
an alias xsl. I reckon that is the most complex thing on the view that
exist right now.
I am sorry if my mail sounded as if I got carried away by my emotions
and thanks for the headsup (at least you know me a wee bit and know that
I sometime react quite emotional, I reckon that is my biggest weakness)
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: [Proposal] remove views from forrest (Re: Views as a Domain
Specific Language)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Thorsten Scherler wrote:
...
> On Fri, 2005-05-27 at 11:39 +0100, Ross Gardler wrote:
...
>>So in conclusion, I agree with Gregors concerns, but I also agree with
>>the direction Thorsten is trying to go in.
>
> Actually that is the reason why I am proposing that forrest is *not*
> officially developing views anymore.
Please reconsider. You are getting unnecessarily carried away by your
emotion. Don't mistakenly read mails as if they were personal complaints
when they are not.
...
> I do not see that it get accepted better said it is causing confusion
> and concerns by user.
Let me be brutally honest with you, as you are being so too with this mail.
Forrest needs a view system that is better than the current skins, and
what you are doing is generally in line with what I have in mind. You
like it, you have passion, and this is good.
On the other hand, your descriptions of the system are sometimes totally
incomprehensible. If I hadn't seen the code and did not have a similar
concept in mind, I think I would have not understood.
I think it's about time that I check out your work and give you
feedback. Where do I start?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: [Proposal] remove views from forrest (Re: Views as a Domain Specific Language)
Posted by Ferdinand Soethe <sa...@soethe.net>.
David Crossley wrote:
> If we give people too much rope, then they can hang
> themselves.
... and we'll get caught in their noose trying to maintain the
code base ...
--
Ferdinand Soethe
Re: [Proposal] remove views from forrest (Re: Views as a Domain Specific Language)
Posted by David Crossley <cr...@apache.org>.
Gregor J. Rothfuss wrote:
> Ross Gardler wrote:
>
> >I'm sorry that you took my original mail as being criticism of your
> >excellent work. It was not intended as personal comment, only
> >reassurance to Gregor that his concerns were, in my opinion, unfounded.
>
> it seems the community is now tackling the concerns that i had, which is
> very good.
Thanks Gregor, i reckon that your concerns were appropriate.
Cocoon was very careful to ensure that the sitemap did not
enable too much "programming". We need to be always on the
lookout. If we give people too much rope, then they can hang
themselves.
--David
Re: [Proposal] remove views from forrest (Re: Views as a Domain Specific
Language)
Posted by "Gregor J. Rothfuss" <gr...@apache.org>.
Ross Gardler wrote:
> Again, this is not meant as a criticism, it is an observation. I made
> the observation because Gregor had clearly found himself in the middle
> of one of these *seemingly* complex examples and it was ringing alarm
> bells for him. He was quite rightly asking should he turn them off or
> was there a real issue.
>
> The example in question is:
>
> <forrest:views xmlns:forrest="http://apache.org/forrest/templates/1.0"
> xmlns:logic="http://apache.org/forrest/logic/1.0">
> <logic:filter value="dirCut" parameter="p">
> <forrest:view format="inx" />
> </logic:filter>
> <logic:filter value="actorCut" parameter="p">
> <forrest:view format="inx" />
> </logic:filter>
>
> This has a "logic" namespace, I believe it is that namespace that
> started alarm bells ringing. The term logic implies there is programming
> in this config file. Now I do know enough about views to know you are
> not doing programming in their config files, but Gregor (I assume) does
> not know this yet. I was trying to reassure him, but in the process I
> seem to have upset you. Sorry.
indeed, the logic in there was a large part of my alarm bells. i brought
this up because there has been a lot of talk about plugins / lenya
resource types and how they could interact / share, and views seem to be
a crucial part for this (very desirable) feature.
i wanted to make sure views solve more problems than they create ;)
> I'm sorry that you took my original mail as being criticism of your
> excellent work. It was not intended as personal comment, only
> reassurance to Gregor that his concerns were, in my opinion, unfounded.
it seems the community is now tackling the concerns that i had, which is
very good.
-gregor
Re: [OT] Come on Preston!!! (Re: [Proposal] remove views from
forrest (Re: Views as a Domain Specific Language))
Posted by Thorsten Scherler <th...@apache.org>.
On Mon, 2005-05-30 at 10:04 +0100, Ross Gardler wrote:
> Thorsten Scherler wrote:
> > On Sun, 2005-05-29 at 21:33 -0500, Antonio Gallardo wrote:
> >
> >>On Dom, 29 de Mayo de 2005, 21:15, David Crossley dijo:
> >>
> >>>Well said Ross, you express yourself well even when drunk.
> >>
> >>+1
> >>
> >>Perhaps we need to send him more beers? ;-)
> >>
> >>Seriously, it was a very nice answer! I liked it much.
> >>
> >
> >
> > +1
> >
> > Sorry for being such a pain in the a*++.
> >
> > I will answer the thread after work by taking your observations to
> > another topic.
> >
> >
>
> Well you guys just took away my hangover, now I can go watch my local
> Football team in the Play-Off finals for a place in the Premiership.
>
> Come on Preston!!!
>
> ( http://news.bbc.co.uk/sport1/hi/football/eng_div_1/4591287.stm )
>
> Ross
+1 Go preston. ;-)
...best against hangover is another beer. ;-) It is on me. ;-)
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
[OT] Come on Preston!!! (Re: [Proposal] remove views from forrest
(Re: Views as a Domain Specific Language))
Posted by Ross Gardler <rg...@apache.org>.
Thorsten Scherler wrote:
> On Sun, 2005-05-29 at 21:33 -0500, Antonio Gallardo wrote:
>
>>On Dom, 29 de Mayo de 2005, 21:15, David Crossley dijo:
>>
>>>Well said Ross, you express yourself well even when drunk.
>>
>>+1
>>
>>Perhaps we need to send him more beers? ;-)
>>
>>Seriously, it was a very nice answer! I liked it much.
>>
>
>
> +1
>
> Sorry for being such a pain in the a*++.
>
> I will answer the thread after work by taking your observations to
> another topic.
>
>
Well you guys just took away my hangover, now I can go watch my local
Football team in the Play-Off finals for a place in the Premiership.
Come on Preston!!!
( http://news.bbc.co.uk/sport1/hi/football/eng_div_1/4591287.stm )
Ross
Re: [Proposal] remove views from forrest (Re: Views as a
Domain Specific Language)
Posted by Thorsten Scherler <th...@apache.org>.
On Sun, 2005-05-29 at 21:33 -0500, Antonio Gallardo wrote:
> On Dom, 29 de Mayo de 2005, 21:15, David Crossley dijo:
> > Well said Ross, you express yourself well even when drunk.
>
> +1
>
> Perhaps we need to send him more beers? ;-)
>
> Seriously, it was a very nice answer! I liked it much.
>
+1
Sorry for being such a pain in the a*++.
I will answer the thread after work by taking your observations to
another topic.
> Best Regards,
>
> Antonio Gallardo
>
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: [Proposal] remove views from forrest (Re: Views as a
Domain Specific Language)
Posted by Antonio Gallardo <ag...@agssa.net>.
On Dom, 29 de Mayo de 2005, 21:15, David Crossley dijo:
> Well said Ross, you express yourself well even when drunk.
+1
Perhaps we need to send him more beers? ;-)
Seriously, it was a very nice answer! I liked it much.
Best Regards,
Antonio Gallardo
Re: [Proposal] remove views from forrest (Re: Views as a Domain Specific Language)
Posted by David Crossley <cr...@apache.org>.
Well said Ross, you express yourself well even when drunk.
Would the next poster please start a new thread for any
design issues that spring from this.
--David
Re: [Proposal] remove views from forrest (Re: Views as a Domain Specific
Language)
Posted by Ross Gardler <rg...@apache.org>.
Thorsten Scherler wrote:
> I really thought whether or not to answer this thread.
Well I said I was going to answer this tomorrow, but there is no way I
will sleep thinking that I have left this unaddressed so here goes (I
hope the alcohol doesn't make things worse ;-)...
> On Fri, 2005-05-27 at 11:39 +0100, Ross Gardler wrote:
>
>>Thorsten Scherler wrote:
>>
>>>On Thu, 2005-05-26 at 18:20 -0400, Gregor J. Rothfuss wrote:
>>
>>...
>>
>>
>>>>are you suggesting that it is easier to learn and use a DSL than to use
>>>>java? i don't buy that, sorry. the DSL is just a layer of indirection,
>>>>the real implementation (at least in lenya, dunno about forrest) will be
>>>>java classes anyway, so why not try to have a sensible API rather than
>>>>hide it behind a bunch of xml?
>>>>
>>>
>>>
>>>That user that do not have to learn java to extend and use
>>>lenya/forrest. They want to configure and not program.
>>
>>I think it is important to understand that at present only Thorstens
>>eyes have touched most of the views plugin (that is why it is in the
>>whiteboard). Last time another dev was able to find the time to
>>understand what Thorsten was doing we ended up simplifying a rather
>>complex XML structure to a really simple one that did the same job, far
>>more efficiently.
>>
>
>
> ¿? Are you talking about Diwaker Gupta? If so then what you wrote is not
> true! I added CSS support to then decide to get rid of it again.
No I wasn't talking of Diwaker Gupta, however you are right to mention
him as he has been active in examining and discussing some aspects of
views. My apologies for overlooking his contribution, even if it has not
been implemented, it has been valid discussion.
What I *was* referring to was our discussions on how to include feeder
output in a view:
http://marc.theaimsgroup.com/?l=forrest-dev&m=111217134219139&w=2
In which we went from:
<forrest:contract name="feeder">
<forrest:properties contract="feeder">
<forrest:property name="feeder" nugget="get.nugget.feeder">
<feedDescriptor>
<feed id="shows">
<url>http://m11.btefnet.net/torrents/backend.xml</url>
</feed>
<feed id="sf">
<url>http://sourceforge.net/export/rss2_projnews.php?group_id=96589</url>
</feed>
</feedDescriptor>
</forrest:property>
<forrest:property name="feedConfig">
<feed id="planetJava" maxItem="10" descr="false"/>
</forrest:property>
</forrest:properties>
</forrest:contract>
To a nice clean and more understandable:
<forrest:contract name="feeder">
<forrest:properties contract="feeder">
<forrest:property name="feeder" nugget="get.nugget.feeder">
<url>/feeds/somefeed.xml</url>
</forrest:property>
</forrest:properties>
</forrest:contract>
Admittedly some of the information in the original is in the feeder
plugin config rather than the views config, but both configs are much
more understandable and we successfully separated the concerns of the
view designer and the content designer.
My intention in raising this point was not to say that your designs are
not good, but to say that we have found that they *are* good and when we
(all the Forrest devs) put our heads together we can really polish what
you have done.
>
> ...and about which complex structure are you takling about?
>
>
>>What I am saying is that when you examine an example from Thorsten in
>>the mailing list it tends to be hugely complex.
>
>
> ¿?
I simply meant that sometimes your examples are too complex for others,
who are lacking your background in the development of views. This is not
a failing of yours, it is a failing of *ours* (mine?) because we (I?)
are not currently able to find the time to discuss the examples with you
as we did in the above thread.
>
> ...again do you consider the fv markup as complex? It contains in the
> core 2 basic tags: forrest:hooks (will be transformed in div) and
> forrest:contracts (which is a capsuled piece of code from the former
> site2xhtml.xsl).
When you explain it like that it sounds wonderful, but a complex
language need not have many elements. It can have a few elements used in
many contexts. However, that is not the problem I have perceive, at
least I don't think so. The problem I have can be seen in the example above.
Look at your first stab at the config file. It contains information
relevant to two different types of Forrest user, the content designer
(the feeder config stuff) and the views designer (the contracts, hooks
and properties). This makes it *appear* complex to the uninitiated reader.
Again, this is not meant as a criticism, it is an observation. I made
the observation because Gregor had clearly found himself in the middle
of one of these *seemingly* complex examples and it was ringing alarm
bells for him. He was quite rightly asking should he turn them off or
was there a real issue.
The example in question is:
<forrest:views xmlns:forrest="http://apache.org/forrest/templates/1.0"
xmlns:logic="http://apache.org/forrest/logic/1.0">
<logic:filter value="dirCut" parameter="p">
<forrest:view format="inx" />
</logic:filter>
<logic:filter value="actorCut" parameter="p">
<forrest:view format="inx" />
</logic:filter>
This has a "logic" namespace, I believe it is that namespace that
started alarm bells ringing. The term logic implies there is programming
in this config file. Now I do know enough about views to know you are
not doing programming in their config files, but Gregor (I assume) does
not know this yet. I was trying to reassure him, but in the process I
seem to have upset you. Sorry.
> I *really* do not understand what is complex. On the other hand to
> create a new skin I consider complex and inflexible. You have to get
> into 2-3 xsl stylesheets and do all changes there regardless whether you
> "only" want to move e.g. the logo.
Agreed, which is why we are all making supportive noises, although not
actually helping at this stage.
> In fv that is dead simple!!!
Not for me, at least not yet.
This is the only point, If they are as simple as you say then they need
to be made more understandable.
What is simple to one person is very complex to another. For example, I
used to work as live Sound Engineer, you know the guy in the middle of a
music venue twiddling all those thousands of knobs on a huge mixing desk
(if you have no idea what I mean see
http://www.soundcraft.com/product_sheet.asp?product_id=18 ). To most
people it looks *really* complex, probably to you too, but to me it is
*extremely* simple.
In my response I was *not* intending to make a *negative* comment about
your work on views. Quite the reverse as you will hopefully see...
>>Thorsten has been
>>working away at this for some time and is in it far deeper than anyone else.
>>
>
>
> Yeah, because I am using the concept of dispatcher view in some customer
> projects with success.
Again, this was not intended as a criticism of your work. It was an
observation that so far you have not had the benefit of "many eyes". It
is solely a product of your own hard work.
I think we all know that in Open Source subsequent versions after peer
review far outstrip the initial version. This has nothing to do with the
skills and abilities of the original author, it has everything to do
with the key benefits of the Open Source methodology.
>>I have a feeling that once we get the chance to review his work the
>>config schema and configuration technique will be massively improved. As
>>you know, that is the way of Open Source.
>>
>
>
> Hmm, the only thing I consider to be improved is the processing behind
> the scenes for xhtml. The scheme is *simple* (see above) and the
> technique, yeah it needs a clearer separation.
On this one you have not misunderstood my intent. You may be right,
maybe we can't improve the implementation, but maybe we can.
Look at the plugins system, it was originally based on Nicola's code
enhancement that allows project sitemaps to pass through to the Forrest
sitemap. I don't know if Nicola intended todays plugins to be the end
result, but if he'd said "you can't improve on project specific
sitemaps" we may never have worked out how to do plugins.
I do know I never envisioned plugins becoming the enabling tool for views.
My point is that things can *always* be improved.
>>All Thorsten is doing is providing a configuration file. However, I do
>>agree that at present that config file is far too complex,
>
>
>
> Please show me where the config file is complex!!!
Let me rephrase the original statement - I believe the configuration
files can be further simplified.
For an example of where they can be further simplified go back to the
top of this email. The thread I link to shows a time when a dev found
the time to understood enough of what you were doing to be able to
discuss a solution with you. The outcome seems to be agreement on a much
simplified solution when compared to the first suggested.
>> if the
>>Forrest devs (well, me at least) can't understand it then it is not
>>suitable for use.
>
>
>
> ¿?
Again, let me rephrase to make my intent clearer (written only from a
personal perspective):
Since I, as a Forrest dev, am having trouble understanding this work, it
is difficult to evaluate its suitability for use.
This is not meant to imply views are *not* suitable. Just that either we
need clearer examples, docs and descriptions, and, possibly, we need to
do more development.
>>So in conclusion, I agree with Gregors concerns, but I also agree with
>>the direction Thorsten is trying to go in.
>>
>
>
> Actually that is the reason why I am proposing that forrest is *not*
> officially developing views anymore. I do not see that it get accepted
> better said it is causing confusion and concerns by user. I happily
> remove all code regarding views from forrest if the forrest pmc will
> positively vote for it.
As a member of the Forrest PMC I will *not* vote for this. In fact I
would vote *against* this. We need views and we need Thorstens vision
for them.
I'm sorry that you took my original mail as being criticism of your
excellent work. It was not intended as personal comment, only
reassurance to Gregor that his concerns were, in my opinion, unfounded.
I wish I learnt your language when I was at school, then I could express
myself better. Sometimes my lack of language skills can cause problems
on mail lists like this.
Ross
Re: [Proposal] remove views from forrest (Re: Views as a Domain Specific Language)
Posted by Diwaker Gupta <di...@gmail.com>.
> ¿? Are you talking about Diwaker Gupta? If so then what you wrote is not
> true! I added CSS support to then decide to get rid of it again.
Perfectly correct! I *was* working on another skin using views, but
I've stopped work on that since I find that problem with the id
generation for anchor tags is a much bigger problem.
I'd just like to add that views IS the right direction for forrest
IMHO and work SHOULD continue on it. I think views/viewsHelper is
pretty easy to use, in reasonably good shape, and with some more
polishing user documentation, it'll be ready to fly!
So hang in there Thorsten!
--
Diwaker Gupta
http://resolute.ucsd.edu/diwaker
Re: [Proposal] remove views from forrest (Re: Views as a Domain
Specific Language)
Posted by Thorsten Scherler <th...@apache.org>.
On Sun, 2005-05-29 at 10:25 -0500, Antonio Gallardo wrote:
> On Dom, 29 de Mayo de 2005, 8:22, Thorsten Scherler dijo:
>
> <snip/>
>
> >> So in conclusion, I agree with Gregors concerns, but I also agree with
> >> the direction Thorsten is trying to go in.
> >>
> >
> > Actually that is the reason why I am proposing that forrest is *not*
> > officially developing views anymore. I do not see that it get accepted
> > better said it is causing confusion and concerns by user. I happily
> > remove all code regarding views from forrest if the forrest pmc will
> > positively vote for it.
> >
> > If this happens I will open an OS-project and develop it elsewhere. I
> > will provide in such a project support for lenya and forrest but this
> > would be independently from both projects.
> >
> > Forrest can keep on using skins with all the downside that they have
> > (see the recent threads on user/dev). They are accepted. ;-)
>
> What are you talking about? Thorsten, please don't take it too personal!
>
>
Sorry, it really seems I did. But no, I thought that this would maybe
the best.
> People can comment about the work you are doing.
Yeah, you are right.
> Unfortunately, I don't
> had time to check you current work.
>
> 3 lessons I learned:
>
> 1-Don't get angry when people do bad comments about your work. AFAIK, only
> people that do nothing, never makes mistakes!. ;-)
>
> I know how frustating is when you spended a lot of hours in a job and then
> somebody told you this is not good. Please, next time, better breath a bit
> and wait until you are OK, before answering. ;-) --> Pollo Alemán!
>
Muchas gracias, killo y tienes razón. I reckon it was really the
frustration about not being able to describe what I am trying to do,
more then the comment itself.
> 2-I will suggest you to finish the job and then show us how easy or
> dificult it is.
Actually it is working like Diwaker stated in some of his mails but it
needs some polishing to really be finished, there you are right.
>
> 3-Keep the user interface in mind all the time.
>
:)
You are right and actually that is what I personally consider the
easiest part of the views.
> I remember you told me about this since last year. I still believe the
> idea is good.
Cheers, yeah the weeks living with you have been really valuable for the
design and implementation of the views. Thanks again.
>
> So please don't call unnecesary votes before it is needed. ok? ;-)
>
Yeah, I understood. Thanks for the feedback.
> Best Regards,
>
> Antonio Gallardo.
>
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: [Proposal] remove views from forrest (Re: Views as a Domain
Specific Language)
Posted by Antonio Gallardo <ag...@agssa.net>.
On Dom, 29 de Mayo de 2005, 8:22, Thorsten Scherler dijo:
<snip/>
>> So in conclusion, I agree with Gregors concerns, but I also agree with
>> the direction Thorsten is trying to go in.
>>
>
> Actually that is the reason why I am proposing that forrest is *not*
> officially developing views anymore. I do not see that it get accepted
> better said it is causing confusion and concerns by user. I happily
> remove all code regarding views from forrest if the forrest pmc will
> positively vote for it.
>
> If this happens I will open an OS-project and develop it elsewhere. I
> will provide in such a project support for lenya and forrest but this
> would be independently from both projects.
>
> Forrest can keep on using skins with all the downside that they have
> (see the recent threads on user/dev). They are accepted. ;-)
What are you talking about? Thorsten, please don't take it too personal!
People can comment about the work you are doing. Unfortunately, I don't
had time to check you current work.
3 lessons I learned:
1-Don't get angry when people do bad comments about your work. AFAIK, only
people that do nothing, never makes mistakes!. ;-)
I know how frustating is when you spended a lot of hours in a job and then
somebody told you this is not good. Please, next time, better breath a bit
and wait until you are OK, before answering. ;-) --> Pollo Alemán!
2-I will suggest you to finish the job and then show us how easy or
dificult it is.
3-Keep the user interface in mind all the time.
I remember you told me about this since last year. I still believe the
idea is good.
So please don't call unnecesary votes before it is needed. ok? ;-)
Best Regards,
Antonio Gallardo.
[Proposal] remove views from forrest (Re: Views as a Domain
Specific Language)
Posted by Thorsten Scherler <th...@apache.org>.
I really thought whether or not to answer this thread.
On Fri, 2005-05-27 at 11:39 +0100, Ross Gardler wrote:
> Thorsten Scherler wrote:
> > On Thu, 2005-05-26 at 18:20 -0400, Gregor J. Rothfuss wrote:
>
> ...
>
> >>are you suggesting that it is easier to learn and use a DSL than to use
> >>java? i don't buy that, sorry. the DSL is just a layer of indirection,
> >>the real implementation (at least in lenya, dunno about forrest) will be
> >>java classes anyway, so why not try to have a sensible API rather than
> >>hide it behind a bunch of xml?
> >>
> >
> >
> > That user that do not have to learn java to extend and use
> > lenya/forrest. They want to configure and not program.
>
> I think it is important to understand that at present only Thorstens
> eyes have touched most of the views plugin (that is why it is in the
> whiteboard). Last time another dev was able to find the time to
> understand what Thorsten was doing we ended up simplifying a rather
> complex XML structure to a really simple one that did the same job, far
> more efficiently.
>
¿? Are you talking about Diwaker Gupta? If so then what you wrote is not
true! I added CSS support to then decide to get rid of it again.
...and about which complex structure are you takling about?
> What I am saying is that when you examine an example from Thorsten in
> the mailing list it tends to be hugely complex.
¿?
...again do you consider the fv markup as complex? It contains in the
core 2 basic tags: forrest:hooks (will be transformed in div) and
forrest:contracts (which is a capsuled piece of code from the former
site2xhtml.xsl).
I *really* do not understand what is complex. On the other hand to
create a new skin I consider complex and inflexible. You have to get
into 2-3 xsl stylesheets and do all changes there regardless whether you
"only" want to move e.g. the logo.
In fv that is dead simple!!!
> Thorsten has been
> working away at this for some time and is in it far deeper than anyone else.
>
Yeah, because I am using the concept of dispatcher view in some customer
projects with success.
> I have a feeling that once we get the chance to review his work the
> config schema and configuration technique will be massively improved. As
> you know, that is the way of Open Source.
>
Hmm, the only thing I consider to be improved is the processing behind
the scenes for xhtml. The scheme is *simple* (see above) and the
technique, yeah it needs a clearer separation.
> All Thorsten is doing is providing a configuration file. However, I do
> agree that at present that config file is far too complex,
Please show me where the config file is complex!!!
> if the
> Forrest devs (well, me at least) can't understand it then it is not
> suitable for use.
¿?
>
> So in conclusion, I agree with Gregors concerns, but I also agree with
> the direction Thorsten is trying to go in.
>
Actually that is the reason why I am proposing that forrest is *not*
officially developing views anymore. I do not see that it get accepted
better said it is causing confusion and concerns by user. I happily
remove all code regarding views from forrest if the forrest pmc will
positively vote for it.
If this happens I will open an OS-project and develop it elsewhere. I
will provide in such a project support for lenya and forrest but this
would be independently from both projects.
Forrest can keep on using skins with all the downside that they have
(see the recent threads on user/dev). They are accepted. ;-)
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Views as a Domain Specific Language (was Re: Locationmaps and Lenya
integration)
Posted by Ross Gardler <rg...@apache.org>.
Thorsten Scherler wrote:
> On Thu, 2005-05-26 at 18:20 -0400, Gregor J. Rothfuss wrote:
...
>>are you suggesting that it is easier to learn and use a DSL than to use
>>java? i don't buy that, sorry. the DSL is just a layer of indirection,
>>the real implementation (at least in lenya, dunno about forrest) will be
>>java classes anyway, so why not try to have a sensible API rather than
>>hide it behind a bunch of xml?
>>
>
>
> That user that do not have to learn java to extend and use
> lenya/forrest. They want to configure and not program.
I think it is important to understand that at present only Thorstens
eyes have touched most of the views plugin (that is why it is in the
whiteboard). Last time another dev was able to find the time to
understand what Thorsten was doing we ended up simplifying a rather
complex XML structure to a really simple one that did the same job, far
more efficiently.
What I am saying is that when you examine an example from Thorsten in
the mailing list it tends to be hugely complex. Thorsten has been
working away at this for some time and is in it far deeper than anyone else.
I have a feeling that once we get the chance to review his work the
config schema and configuration technique will be massively improved. As
you know, that is the way of Open Source.
All Thorsten is doing is providing a configuration file. However, I do
agree that at present that config file is far too complex, if the
Forrest devs (well, me at least) can't understand it then it is not
suitable for use.
So in conclusion, I agree with Gregors concerns, but I also agree with
the direction Thorsten is trying to go in.
Views needs work, when 0.7 is out the door it will get more attention
from other devs (at least from me).
Ross
Re: Locationmaps and Lenya integration
Posted by Thorsten Scherler <th...@apache.org>.
On Thu, 2005-05-26 at 18:20 -0400, Gregor J. Rothfuss wrote:
> Thorsten Scherler wrote:
>
> > I do not like this expression 'programming in xml' it is more (like I
> > stated in other threads) 'configuring components with xml'.
>
> the crucial question will be where to draw the boundaries.
>
I agree.
> > This code should help *user* easily change the output of forrest. In the
> > end this code should be produced by tools.
> >
> > ...and btw I would like to see such clear intuitive configuration and
> > separation in lenya and not a parameter overkilled framework that allows
> > user to extend the framework if they *exactly* follow the *not easy* to
> > understand boundaries and rules of the framework where you can do
> > everything you want as long it is the lenya way.
>
> what you are proposing as an alternative is a domain-specific language
> (DSL). i don't think that is any easier than java, especially
> considering that you lose all the nice autocomplete, javadocs,
> refactoring, testing etc features that have sprung up around java. it's
> not the fault of the language if you use vi to write java when there are
> better alternatives available.
>
I never said that this DSL will do anything other then configuring. Java
is for devs and not users, but user can use a simple configuration
language to configure the java classes. That is a simple interface for
SOC.
> > *User* want to have a configuration file (or better (in the future) a
> > tool where they can create such a file) to alter the behavior of their
> > application. They do not want to learn cocoon/java to alter the default
> > behavior. You have worked on PostNuke, you should know that for
> > yourself, as a user you do not want to learn php. ;-)
>
> if you have a tool, you don't need a DSL :) the effort spent on coming
> up with a DSL could alternatively be spent on creating wizards for
> common functionality, like 'create new publication' in the lenya case.
>
:) To do so you need a common interface for components (or tools) to
plugin into the framework. This is best expressed in a DSL because you
can capsule the parameter passed to the tools/components.
[OT] Create new publication - that should work IMO like "forrest seed".
Anywhere on your hd executable and not limited to be within lenya site
structure. If we can provide this we as well would be copyless like
forrest which is one of the biggest advantage of forrest over lenya for
developing webappz.
> speaking of postnuke, that was a total disaster, totally unmaintainable
> code. take a look at xaraya (and it's history), it's a rewrite that
> avoids the problems postnuke has.
>
Agree.
> > The goal is that a normal user do not have to understand much of
> > programming (nor cocoon or java) but rather can configure forrest in an
> > easy intuitive way to customize it the way they want. The view e.g.
> > should be created by a webdesigner that have *no* knowledge of
> > programming at all.
>
> why not use CSS?
>
Because you can not do everything with css. The css only can be applied
to certain xhtml-skeletons. The designer wants to have control over the
produced skeleton with the views we will give him this possibility. Then
he really can use the css he wants the way he want it.
> > Devs on the other hand want an easy to understand and clear defined
> > interface where they can plugin new components.
>
> are you suggesting that it is easier to learn and use a DSL than to use
> java? i don't buy that, sorry. the DSL is just a layer of indirection,
> the real implementation (at least in lenya, dunno about forrest) will be
> java classes anyway, so why not try to have a sensible API rather than
> hide it behind a bunch of xml?
>
That user that do not have to learn java to extend and use
lenya/forrest. They want to configure and not program.
...and you are right it is "a layer of indirection" but I do not see
anything bad on that. ...and I *really truly* believe it is easier to
use and learn a DSL that contains right now 4 different tags and
configure your classes with that.
The benefit is that other components can use the same DSL to be
configured. That will make component development much easier because you
have a clear DSL for configuration.
In short views are the "missing link" between user and devs. I started
the work on it because I saw that our forrest skins are sharing *a lot*
of common components but as soon as we change some components than I
have to apply the changes in all skins. By capsuling this components
into contracts the maintainment and use of this components is much
easier.
> i like xml as much as anyone, but there are limits (see below for a case
> where the limit has been violated in a drastic way)
>
:) LOL
Yeah you are right.
> > Search the ml for view;view helper;leather;...
>
> cool, will do.
>
some links
http://marc.theaimsgroup.com/?l=forrest-dev&m=110107619329543&w=2
<mailings href="http://marc.theaimsgroup.com/?">
<dev href="l=forrest-dev&">
<pInfra href="m=110019697426791&w=2"/>
<ftLeather href="m=109959086204887&w=2"/>
</dev>
</mailings>
>
> > ...or do you *really* consider
> > <logic:filter value="dirCut" parameter="p">
> > <forrest:view format="inx" />
> > </logic:filter>
> > <logic:filter value="actorCut" parameter="p">
> > <forrest:view format="inx" />
> > </logic:filter>
> > as programming???
>
> if the expressive power of that XML is not severely restricted, then yes.
>
> see http://ant.apache.org/ant2/features.html, heading "Simple
> Flow-Control" for a similar argument.
>
I totally agree with that, and views should never become a scripting language.
The logic tags are simple conditions which content to request. Nothing more and nothing less.
>
> cocoon moved away from having logic in the sitemap, and lenya 1.4 has
> removed all the logic in XSP and other XML places, because XSP turned
> out to be brittle: you don't get compile errors if a XSP has calls to an
> API that has been removed.
>
Agree as well. I do not want to invent a new XSP and do not want to add logic to the sitemap (besides some simple "resource exist" test).
>
> i just refactored a cocoon app that has a 4000 line sitemap. below is a
> sample of how things looked before the refactoring. this experience is
> the reason why i am asking these questions.
>
:) Yeah but with views this would not happen. It is invented to overcome such situation.
>
> i will try to find your RT to better understand what you have in mind.
>
Thanks, I am always happy to talk about this idea. ;-)
salu2
>
> best,
>
> -gregor
>
> <map:resource name="submitApproved">
> <map:select type="parameter">
> <map:parameter name="parameter-selector-test"
> value="{cct-package:/deliveryMethod}"/>
>
> <map:when test="email">
> <map:act type="resource-load" src="cocoon:/letter.submission">
> <map:parameter name="write-to" value="session"/>
> <map:parameter name="attribute-name" value="packageQueue.package"/>
> <map:select type="parameter">
> <map:parameter name="parameter-selector-test"
> value="{cct-package:/lsttestmode}"/>
> <map:when test="">
> <map:act type="jmsSender">
> <map:parameter name="packageID" value="{cct-package:/id}"/>
> <map:parameter name="srcPattern"
> value="cocoon:/letter.*.*.archive"/>
> <map:parameter name="appendSrcPattern"
> value="cocoon:/letter.*.*.email"/>
> <map:parameter name="ccRecipients"
> value="{cct-package:count(/recipient/advisor)}"/>
> <map:parameter name="requiredRecipients"
> value="{cct-package:count(/requiredRecipients/requiredRecipient)}"/>
> <map:act type="sendmail">
> <map:parameter name="from" value="@EMAIL_REPLYTO@"/>
> <map:parameter name="to"
> value="{cct-package:/recipient/email}"/>
> <map:parameter name="cc"
> value="{cct-package-concat:/recipient/advisor/email |
> /copies-to/copy-to/email}"/>
> <map:parameter name="requiredRecipients"
> value="{cct-package:count(/requiredRecipients/requiredRecipient)}"/>
> <map:parameter name="subject" value="@EMAIL_SUBJECT@"/>
> <map:parameter name="src"
> value="cocoon:/letter.*.*.email"/>
> <map:parameter name="srcMimeType" value="text/html"/>
> <map:parameter name="inlineparts"
> value="cocoon:/letter.*.*.email.txt cocoon:/letter.*.*.email"/>
> <map:parameter name="inlinepartsMimeType"
> value="text/plain text/html"/>
> <map:parameter name="subtype" value="alternative"/>
> <map:act type="dbms-emailPackage">
> <map:parameter name="table-set"
> value="EmailPackage{../../../../fromInstance}"/>
> <map:call resource="processUnlockPackage">
> <map:parameter name="unlock" value="{../../../../../unlock}"/>
> <map:parameter name="actionType"
> value="{../../../../actionType}"/>
> <map:parameter name="redirect" value="showConfPage"/>
> </map:call>
> </map:act>
> <map:call resource="processUnlockPackage">
> <map:parameter name="unlock" value="{../../../../unlock}"/>
> <map:parameter name="redirect"
> value="cocoon:/emailPackage.error"/>
> </map:call>
> </map:act>
> <map:call resource="processUnlockPackage">
> <map:parameter name="unlock" value="{../../../unlock}"/>
> <map:parameter name="redirect" value="cocoon:/emailLetter.error"/>
> </map:call>
> </map:act>
> </map:when>
> <map:otherwise>
> <map:act type="jmsSenderTest">
> <map:parameter name="packageID" value="{cct-package:/id}"/>
> <map:parameter name="srcPattern"
> value="cocoon:/letter.*.*.archive"/>
> <map:parameter name="appendSrcPattern"
> value="cocoon:/letter.*.*.email"/>
> <map:parameter name="ccRecipients"
> value="{cct-package:count(/recipient/advisor)}"/>
> <map:parameter name="requiredRecipients"
> value="{cct-package:count(/requiredRecipients/requiredRecipient)}"/>
> <map:act type="sendmail">
> <map:parameter name="from" value="@EMAIL_REPLYTO@"/>
> <map:parameter name="to"
> value="{cct-package:/recipient/email}"/>
> <map:parameter name="cc"
> value="{cct-package-concat:/recipient/advisor/email |
> /copies-to/copy-to/email}"/>
> <map:parameter name="requiredRecipients"
> value="{cct-package:count(/requiredRecipients/requiredRecipient)}"/>
> <map:parameter name="subject" value="@EMAIL_SUBJECT@"/>
> <map:parameter name="src"
> value="cocoon:/letter.*.*.email"/>
> <map:parameter name="srcMimeType" value="text/html"/>
> <map:parameter name="inlineparts"
> value="cocoon:/letter.*.*.email.txt cocoon:/letter.*.*.email"/>
> <map:parameter name="inlinepartsMimeType"
> value="text/plain text/html"/>
> <map:parameter name="subtype" value="alternative"/>
> <map:act type="dbms-emailPackage">
> <map:parameter name="table-set"
> value="EmailPackage{../../../../fromInstance}"/>
> <map:call resource="processUnlockPackage">
> <map:parameter name="unlock" value="{../../../../../unlock}"/>
> <map:parameter name="actionType"
> value="{../../../../actionType}"/>
> <map:parameter name="redirect" value="showConfPage"/>
> </map:call>
> </map:act>
> <map:call resource="processUnlockPackage">
> <map:parameter name="unlock" value="{../../../../unlock}"/>
> <map:parameter name="redirect"
> value="cocoon:/emailPackage.error"/>
> </map:call>
> </map:act>
> <map:call resource="processUnlockPackage">
> <map:parameter name="unlock" value="{../../../unlock}"/>
> <map:parameter name="redirect" value="cocoon:/emailLetter.error"/>
> </map:call>
> </map:act>
> </map:otherwise>
> </map:select>
>
> <map:call resource="processUnlockPackage">
> <map:parameter name="unlock" value="{../../unlock}"/>
> <map:parameter name="redirect"
> value="cocoon:/onDemandArchive.error"/>
> </map:call>
> </map:act>
> <map:call resource="processUnlockPackage">
> <map:parameter name="unlock" value="{../unlock}"/>
> <map:parameter name="redirect"
> value="cocoon:/generateSubmission.error"/>
> </map:call>
> </map:when>
>
> <map:when test="local">
> <map:act type="resource-load" src="cocoon:/letter.submission">
> <map:parameter name="write-to" value="session"/>
> <map:parameter name="attribute-name" value="packageQueue.package"/>
> <map:select type="parameter">
> <map:parameter name="parameter-selector-test"
> value="{cct-package:/lsttestmode}"/>
> <map:when test="">
> <map:act type="jmsSender">
> <map:parameter name="packageID" value="{cct-package:/id}"/>
> <map:parameter name="srcPattern"
> value="cocoon:/letter.*.*.archive"/>
> <map:parameter name="appendSrcPattern"
> value="cocoon:/letter.*.*.view.ondemand"/>
> <map:parameter name="ccRecipients"
> value="{cct-package:count(/recipient/advisor)}"/>
> <map:parameter name="requiredRecipients"
> value="{cct-package:count(/requiredRecipients/requiredRecipient)}"/>
> <map:act type="dbms-printLocalPackage">
> <map:parameter name="table-set"
> value="PrintLocalPackage{../../../fromInstance}"/>
> <map:redirect-to uri="cctUserIndex.html"/>
> </map:act>
> <map:redirect-to uri="cocoon:/printLocalPackage.error"/>
> </map:act>
> </map:when>
> <map:otherwise>
> <map:act type="jmsSenderTest">
> <map:parameter name="packageID" value="{cct-package:/id}"/>
> <map:parameter name="srcPattern"
> value="cocoon:/letter.*.*.archive"/>
> <map:parameter name="appendSrcPattern"
> value="cocoon:/letter.*.*.view.ondemand"/>
> <map:parameter name="ccRecipients"
> value="{cct-package:count(/recipient/advisor)}"/>
> <map:parameter name="requiredRecipients"
> value="{cct-package:count(/requiredRecipients/requiredRecipient)}"/>
> <map:act type="dbms-printLocalPackage">
> <map:parameter name="table-set"
> value="PrintLocalPackage{../../../fromInstance}"/>
> <map:redirect-to uri="cctUserIndex.html"/>
> </map:act>
> <map:redirect-to uri="cocoon:/printLocalPackage.error"/>
> </map:act>
> </map:otherwise>
> </map:select>
> <map:redirect-to uri="cocoon:/onDemandArchive.error"/>
> </map:act>
> <map:redirect-to uri="cocoon:/generateSubmission.error"/>
> </map:when>
>
> <map:when test="central">
> <map:act type="resource-load" src="cocoon:/letter.submission">
> <map:parameter name="write-to" value="session"/>
> <map:parameter name="attribute-name" value="packageQueue.package"/>
>
> <!-- Determine if we should queue this package or render/send it
> immediately -->
> <map:select type="parameter">
> <map:parameter name="parameter-selector-test"
> value="{cct-package:/sendAfter}{cct-package:/sendBefore}"/>
> <map:when test="">
> <map:act type="set">
> <map:parameter name="write-to" value="request"/>
> <map:parameter name="attribute-name" value="QueuePackage"/>
> <map:parameter name="attribute-value" value="false"/>
> </map:act>
> </map:when>
> <map:otherwise>
> <map:select type="parameter">
> <map:parameter name="parameter-selector-test"
> value="{request-param:/RenderImmediately}"/>
> <map:when test="true">
> <map:act type="set">
> <map:parameter name="write-to" value="request"/>
> <map:parameter name="attribute-name" value="QueuePackage"/>
> <map:parameter name="attribute-value" value="false"/>
> </map:act>
> </map:when>
> <map:otherwise>
> <map:act type="set">
> <map:parameter name="write-to" value="request"/>
> <map:parameter name="attribute-name" value="QueuePackage"/>
> <map:parameter name="attribute-value" value="true"/>
> </map:act>
> </map:otherwise>
> </map:select>
> </map:otherwise>
> </map:select>
>
> <map:select type="parameter">
> <map:parameter name="parameter-selector-test"
> value="{request-attr:QueuePackage}"/> <!-- Should we queue instead of
> render/send immediately? -->
> <map:when test="false">
> <!-- Render/Send Immediately -->
> <map:select type="parameter">
> <map:parameter name="parameter-selector-test"
> value="{cct-package:/lsttestmode}"/>
> <map:when test="">
> <map:act type="jmsSender">
> <map:parameter name="packageID" value="{cct-package:/id}"/>
> <map:parameter name="srcPattern"
> value="cocoon:/letter.*.*.archive"/>
> <map:parameter name="appendSrcPattern"
> value="cocoon:/letter.*.*.view.ondemand"/>
> <map:parameter name="ccRecipients"
> value="{cct-package:count(/recipient/advisor)}"/>
> <map:parameter name="requiredRecipients"
> value="{cct-package:count(/requiredRecipients/requiredRecipient)}"/>
> <map:act type="centralPrintCopy">
> <map:parameter name="packageID" value="{cct-package:/id}"/>
> <map:parameter name="srcPattern"
> value="cocoon:/letter.*.*.print"/>
> <map:parameter name="ccRecipients"
> value="{cct-package:count(/recipient/advisor)}"/>
> <map:parameter name="requiredRecipients"
> value="{cct-package:count(/requiredRecipients/requiredRecipient)}"/>
> <map:parameter name="lst_test_mode"
> value="{request-param:lst_test_mode}"/>
> <map:act type="dbms-printCentralPackage">
> <map:parameter name="table-set"
> value="PrintCentralPackage{../../../../fromInstance}"/>
> <map:call resource="processUnlockPackage">
> <map:parameter name="unlock" value="{../../../../../unlock}"/>
> <map:parameter name="actionType"
> value="{../../../../../actionType}"/>
> <map:parameter name="redirect" value="showConfPage"/>
> </map:call>
> </map:act>
> <map:call resource="processUnlockPackage">
> <map:parameter name="unlock" value="{../../../../unlock}"/>
> <map:parameter name="redirect"
> value="cocoon:/printCentralPackage.error"/>
> </map:call>
> </map:act>
> <map:call resource="processUnlockPackage">
> <map:parameter name="unlock" value="{../../../unlock}"/>
> <map:parameter name="redirect"
> value="cocoon:/printCentralLetter.error"/>
> </map:call>
> </map:act>
> </map:when>
> <map:otherwise>
> <map:act type="jmsSenderTest">
> <map:parameter name="packageID" value="{cct-package:/id}"/>
> <map:parameter name="srcPattern"
> value="cocoon:/letter.*.*.archive"/>
> <map:parameter name="appendSrcPattern"
> value="cocoon:/letter.*.*.view.ondemand"/>
> <map:parameter name="ccRecipients"
> value="{cct-package:count(/recipient/advisor)}"/>
> <map:parameter name="requiredRecipients"
> value="{cct-package:count(/requiredRecipients/requiredRecipient)}"/>
> <map:act type="centralPrintCopy">
> <map:parameter name="packageID" value="{cct-package:/id}"/>
> <map:parameter name="srcPattern"
> value="cocoon:/letter.*.*.print"/>
> <map:parameter name="ccRecipients"
> value="{cct-package:count(/recipient/advisor)}"/>
> <map:parameter name="requiredRecipients"
> value="{cct-package:count(/requiredRecipients/requiredRecipient)}"/>
> <map:parameter name="lst_test_mode"
> value="{request-param:lst_test_mode}"/>
> <map:act type="dbms-printCentralPackage">
> <map:parameter name="table-set"
> value="PrintCentralPackage{../../../../fromInstance}"/>
> <map:call resource="processUnlockPackage">
> <map:parameter name="unlock" value="{../../../../../unlock}"/>
> <map:parameter name="actionType"
> value="{../../../../../actionType}"/>
> <map:parameter name="redirect" value="showConfPage"/>
> </map:call>
> </map:act>
> <map:call resource="processUnlockPackage">
> <map:parameter name="unlock" value="{../../../../unlock}"/>
> <map:parameter name="redirect"
> value="cocoon:/printCentralPackage.error"/>
> </map:call>
> </map:act>
> <map:call resource="processUnlockPackage">
> <map:parameter name="unlock" value="{../../../unlock}"/>
> <map:parameter name="redirect"
> value="cocoon:/printCentralLetter.error"/>
> </map:call>
> </map:act>
> </map:otherwise>
> </map:select>
> <map:call resource="processUnlockPackage">
> <map:parameter name="unlock" value="{../../unlock}"/>
> <map:parameter name="redirect"
> value="cocoon:/onDemandArchive.error"/>
> </map:call>
> </map:when>
>
> <map:otherwise>
> <!-- Queue the Central Print Package instead -->
>
> <map:act type="dbms-queueCentralPackage">
> <map:parameter name="table-set"
> value="QueueCentralPackage{../../fromInstance}"/>
> <map:call resource="processUnlockPackage">
> <map:parameter name="unlock" value="{../../../unlock}"/>
> <map:parameter name="actionType"
> value="{../../../actionType}"/>
> <map:parameter name="redirect" value="showConfPage"/>
> </map:call>
> </map:act>
> <map:call resource="processUnlockPackage">
> <map:parameter name="unlock" value="{../../unlock}"/>
> <map:parameter name="redirect"
> value="cocoon:/queueCentralPackage.error"/>
> </map:call>
> </map:otherwise>
> </map:select>
>
> </map:act>
> <map:call resource="processUnlockPackage">
> <map:parameter name="unlock" value="{../unlock}"/>
> <map:parameter name="redirect"
> value="cocoon:/generateSubmission.error"/>
> </map:call>
> </map:when>
>
> <map:otherwise>
> <map:redirect-to
> uri="cocoon:/invalidDeliveryMethodForSubmission.error"/>
> </map:otherwise>
> </map:select>
> </map:resource>
>
>
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: Locationmaps and Lenya integration
Posted by "Gregor J. Rothfuss" <gr...@apache.org>.
Thorsten Scherler wrote:
> I do not like this expression 'programming in xml' it is more (like I
> stated in other threads) 'configuring components with xml'.
the crucial question will be where to draw the boundaries.
> This code should help *user* easily change the output of forrest. In the
> end this code should be produced by tools.
>
> ...and btw I would like to see such clear intuitive configuration and
> separation in lenya and not a parameter overkilled framework that allows
> user to extend the framework if they *exactly* follow the *not easy* to
> understand boundaries and rules of the framework where you can do
> everything you want as long it is the lenya way.
what you are proposing as an alternative is a domain-specific language
(DSL). i don't think that is any easier than java, especially
considering that you lose all the nice autocomplete, javadocs,
refactoring, testing etc features that have sprung up around java. it's
not the fault of the language if you use vi to write java when there are
better alternatives available.
> *User* want to have a configuration file (or better (in the future) a
> tool where they can create such a file) to alter the behavior of their
> application. They do not want to learn cocoon/java to alter the default
> behavior. You have worked on PostNuke, you should know that for
> yourself, as a user you do not want to learn php. ;-)
if you have a tool, you don't need a DSL :) the effort spent on coming
up with a DSL could alternatively be spent on creating wizards for
common functionality, like 'create new publication' in the lenya case.
speaking of postnuke, that was a total disaster, totally unmaintainable
code. take a look at xaraya (and it's history), it's a rewrite that
avoids the problems postnuke has.
> The goal is that a normal user do not have to understand much of
> programming (nor cocoon or java) but rather can configure forrest in an
> easy intuitive way to customize it the way they want. The view e.g.
> should be created by a webdesigner that have *no* knowledge of
> programming at all.
why not use CSS?
> Devs on the other hand want an easy to understand and clear defined
> interface where they can plugin new components.
are you suggesting that it is easier to learn and use a DSL than to use
java? i don't buy that, sorry. the DSL is just a layer of indirection,
the real implementation (at least in lenya, dunno about forrest) will be
java classes anyway, so why not try to have a sensible API rather than
hide it behind a bunch of xml?
i like xml as much as anyone, but there are limits (see below for a case
where the limit has been violated in a drastic way)
> Search the ml for view;view helper;leather;...
cool, will do.
> ...or do you *really* consider
> <logic:filter value="dirCut" parameter="p">
> <forrest:view format="inx" />
> </logic:filter>
> <logic:filter value="actorCut" parameter="p">
> <forrest:view format="inx" />
> </logic:filter>
> as programming???
if the expressive power of that XML is not severely restricted, then yes.
see http://ant.apache.org/ant2/features.html, heading "Simple
Flow-Control" for a similar argument.
cocoon moved away from having logic in the sitemap, and lenya 1.4 has
removed all the logic in XSP and other XML places, because XSP turned
out to be brittle: you don't get compile errors if a XSP has calls to an
API that has been removed.
i just refactored a cocoon app that has a 4000 line sitemap. below is a
sample of how things looked before the refactoring. this experience is
the reason why i am asking these questions.
i will try to find your RT to better understand what you have in mind.
best,
-gregor
<map:resource name="submitApproved">
<map:select type="parameter">
<map:parameter name="parameter-selector-test"
value="{cct-package:/deliveryMethod}"/>
<map:when test="email">
<map:act type="resource-load" src="cocoon:/letter.submission">
<map:parameter name="write-to" value="session"/>
<map:parameter name="attribute-name" value="packageQueue.package"/>
<map:select type="parameter">
<map:parameter name="parameter-selector-test"
value="{cct-package:/lsttestmode}"/>
<map:when test="">
<map:act type="jmsSender">
<map:parameter name="packageID" value="{cct-package:/id}"/>
<map:parameter name="srcPattern"
value="cocoon:/letter.*.*.archive"/>
<map:parameter name="appendSrcPattern"
value="cocoon:/letter.*.*.email"/>
<map:parameter name="ccRecipients"
value="{cct-package:count(/recipient/advisor)}"/>
<map:parameter name="requiredRecipients"
value="{cct-package:count(/requiredRecipients/requiredRecipient)}"/>
<map:act type="sendmail">
<map:parameter name="from" value="@EMAIL_REPLYTO@"/>
<map:parameter name="to"
value="{cct-package:/recipient/email}"/>
<map:parameter name="cc"
value="{cct-package-concat:/recipient/advisor/email |
/copies-to/copy-to/email}"/>
<map:parameter name="requiredRecipients"
value="{cct-package:count(/requiredRecipients/requiredRecipient)}"/>
<map:parameter name="subject" value="@EMAIL_SUBJECT@"/>
<map:parameter name="src"
value="cocoon:/letter.*.*.email"/>
<map:parameter name="srcMimeType" value="text/html"/>
<map:parameter name="inlineparts"
value="cocoon:/letter.*.*.email.txt cocoon:/letter.*.*.email"/>
<map:parameter name="inlinepartsMimeType"
value="text/plain text/html"/>
<map:parameter name="subtype" value="alternative"/>
<map:act type="dbms-emailPackage">
<map:parameter name="table-set"
value="EmailPackage{../../../../fromInstance}"/>
<map:call resource="processUnlockPackage">
<map:parameter name="unlock" value="{../../../../../unlock}"/>
<map:parameter name="actionType"
value="{../../../../actionType}"/>
<map:parameter name="redirect" value="showConfPage"/>
</map:call>
</map:act>
<map:call resource="processUnlockPackage">
<map:parameter name="unlock" value="{../../../../unlock}"/>
<map:parameter name="redirect"
value="cocoon:/emailPackage.error"/>
</map:call>
</map:act>
<map:call resource="processUnlockPackage">
<map:parameter name="unlock" value="{../../../unlock}"/>
<map:parameter name="redirect" value="cocoon:/emailLetter.error"/>
</map:call>
</map:act>
</map:when>
<map:otherwise>
<map:act type="jmsSenderTest">
<map:parameter name="packageID" value="{cct-package:/id}"/>
<map:parameter name="srcPattern"
value="cocoon:/letter.*.*.archive"/>
<map:parameter name="appendSrcPattern"
value="cocoon:/letter.*.*.email"/>
<map:parameter name="ccRecipients"
value="{cct-package:count(/recipient/advisor)}"/>
<map:parameter name="requiredRecipients"
value="{cct-package:count(/requiredRecipients/requiredRecipient)}"/>
<map:act type="sendmail">
<map:parameter name="from" value="@EMAIL_REPLYTO@"/>
<map:parameter name="to"
value="{cct-package:/recipient/email}"/>
<map:parameter name="cc"
value="{cct-package-concat:/recipient/advisor/email |
/copies-to/copy-to/email}"/>
<map:parameter name="requiredRecipients"
value="{cct-package:count(/requiredRecipients/requiredRecipient)}"/>
<map:parameter name="subject" value="@EMAIL_SUBJECT@"/>
<map:parameter name="src"
value="cocoon:/letter.*.*.email"/>
<map:parameter name="srcMimeType" value="text/html"/>
<map:parameter name="inlineparts"
value="cocoon:/letter.*.*.email.txt cocoon:/letter.*.*.email"/>
<map:parameter name="inlinepartsMimeType"
value="text/plain text/html"/>
<map:parameter name="subtype" value="alternative"/>
<map:act type="dbms-emailPackage">
<map:parameter name="table-set"
value="EmailPackage{../../../../fromInstance}"/>
<map:call resource="processUnlockPackage">
<map:parameter name="unlock" value="{../../../../../unlock}"/>
<map:parameter name="actionType"
value="{../../../../actionType}"/>
<map:parameter name="redirect" value="showConfPage"/>
</map:call>
</map:act>
<map:call resource="processUnlockPackage">
<map:parameter name="unlock" value="{../../../../unlock}"/>
<map:parameter name="redirect"
value="cocoon:/emailPackage.error"/>
</map:call>
</map:act>
<map:call resource="processUnlockPackage">
<map:parameter name="unlock" value="{../../../unlock}"/>
<map:parameter name="redirect" value="cocoon:/emailLetter.error"/>
</map:call>
</map:act>
</map:otherwise>
</map:select>
<map:call resource="processUnlockPackage">
<map:parameter name="unlock" value="{../../unlock}"/>
<map:parameter name="redirect"
value="cocoon:/onDemandArchive.error"/>
</map:call>
</map:act>
<map:call resource="processUnlockPackage">
<map:parameter name="unlock" value="{../unlock}"/>
<map:parameter name="redirect"
value="cocoon:/generateSubmission.error"/>
</map:call>
</map:when>
<map:when test="local">
<map:act type="resource-load" src="cocoon:/letter.submission">
<map:parameter name="write-to" value="session"/>
<map:parameter name="attribute-name" value="packageQueue.package"/>
<map:select type="parameter">
<map:parameter name="parameter-selector-test"
value="{cct-package:/lsttestmode}"/>
<map:when test="">
<map:act type="jmsSender">
<map:parameter name="packageID" value="{cct-package:/id}"/>
<map:parameter name="srcPattern"
value="cocoon:/letter.*.*.archive"/>
<map:parameter name="appendSrcPattern"
value="cocoon:/letter.*.*.view.ondemand"/>
<map:parameter name="ccRecipients"
value="{cct-package:count(/recipient/advisor)}"/>
<map:parameter name="requiredRecipients"
value="{cct-package:count(/requiredRecipients/requiredRecipient)}"/>
<map:act type="dbms-printLocalPackage">
<map:parameter name="table-set"
value="PrintLocalPackage{../../../fromInstance}"/>
<map:redirect-to uri="cctUserIndex.html"/>
</map:act>
<map:redirect-to uri="cocoon:/printLocalPackage.error"/>
</map:act>
</map:when>
<map:otherwise>
<map:act type="jmsSenderTest">
<map:parameter name="packageID" value="{cct-package:/id}"/>
<map:parameter name="srcPattern"
value="cocoon:/letter.*.*.archive"/>
<map:parameter name="appendSrcPattern"
value="cocoon:/letter.*.*.view.ondemand"/>
<map:parameter name="ccRecipients"
value="{cct-package:count(/recipient/advisor)}"/>
<map:parameter name="requiredRecipients"
value="{cct-package:count(/requiredRecipients/requiredRecipient)}"/>
<map:act type="dbms-printLocalPackage">
<map:parameter name="table-set"
value="PrintLocalPackage{../../../fromInstance}"/>
<map:redirect-to uri="cctUserIndex.html"/>
</map:act>
<map:redirect-to uri="cocoon:/printLocalPackage.error"/>
</map:act>
</map:otherwise>
</map:select>
<map:redirect-to uri="cocoon:/onDemandArchive.error"/>
</map:act>
<map:redirect-to uri="cocoon:/generateSubmission.error"/>
</map:when>
<map:when test="central">
<map:act type="resource-load" src="cocoon:/letter.submission">
<map:parameter name="write-to" value="session"/>
<map:parameter name="attribute-name" value="packageQueue.package"/>
<!-- Determine if we should queue this package or render/send it
immediately -->
<map:select type="parameter">
<map:parameter name="parameter-selector-test"
value="{cct-package:/sendAfter}{cct-package:/sendBefore}"/>
<map:when test="">
<map:act type="set">
<map:parameter name="write-to" value="request"/>
<map:parameter name="attribute-name" value="QueuePackage"/>
<map:parameter name="attribute-value" value="false"/>
</map:act>
</map:when>
<map:otherwise>
<map:select type="parameter">
<map:parameter name="parameter-selector-test"
value="{request-param:/RenderImmediately}"/>
<map:when test="true">
<map:act type="set">
<map:parameter name="write-to" value="request"/>
<map:parameter name="attribute-name" value="QueuePackage"/>
<map:parameter name="attribute-value" value="false"/>
</map:act>
</map:when>
<map:otherwise>
<map:act type="set">
<map:parameter name="write-to" value="request"/>
<map:parameter name="attribute-name" value="QueuePackage"/>
<map:parameter name="attribute-value" value="true"/>
</map:act>
</map:otherwise>
</map:select>
</map:otherwise>
</map:select>
<map:select type="parameter">
<map:parameter name="parameter-selector-test"
value="{request-attr:QueuePackage}"/> <!-- Should we queue instead of
render/send immediately? -->
<map:when test="false">
<!-- Render/Send Immediately -->
<map:select type="parameter">
<map:parameter name="parameter-selector-test"
value="{cct-package:/lsttestmode}"/>
<map:when test="">
<map:act type="jmsSender">
<map:parameter name="packageID" value="{cct-package:/id}"/>
<map:parameter name="srcPattern"
value="cocoon:/letter.*.*.archive"/>
<map:parameter name="appendSrcPattern"
value="cocoon:/letter.*.*.view.ondemand"/>
<map:parameter name="ccRecipients"
value="{cct-package:count(/recipient/advisor)}"/>
<map:parameter name="requiredRecipients"
value="{cct-package:count(/requiredRecipients/requiredRecipient)}"/>
<map:act type="centralPrintCopy">
<map:parameter name="packageID" value="{cct-package:/id}"/>
<map:parameter name="srcPattern"
value="cocoon:/letter.*.*.print"/>
<map:parameter name="ccRecipients"
value="{cct-package:count(/recipient/advisor)}"/>
<map:parameter name="requiredRecipients"
value="{cct-package:count(/requiredRecipients/requiredRecipient)}"/>
<map:parameter name="lst_test_mode"
value="{request-param:lst_test_mode}"/>
<map:act type="dbms-printCentralPackage">
<map:parameter name="table-set"
value="PrintCentralPackage{../../../../fromInstance}"/>
<map:call resource="processUnlockPackage">
<map:parameter name="unlock" value="{../../../../../unlock}"/>
<map:parameter name="actionType"
value="{../../../../../actionType}"/>
<map:parameter name="redirect" value="showConfPage"/>
</map:call>
</map:act>
<map:call resource="processUnlockPackage">
<map:parameter name="unlock" value="{../../../../unlock}"/>
<map:parameter name="redirect"
value="cocoon:/printCentralPackage.error"/>
</map:call>
</map:act>
<map:call resource="processUnlockPackage">
<map:parameter name="unlock" value="{../../../unlock}"/>
<map:parameter name="redirect"
value="cocoon:/printCentralLetter.error"/>
</map:call>
</map:act>
</map:when>
<map:otherwise>
<map:act type="jmsSenderTest">
<map:parameter name="packageID" value="{cct-package:/id}"/>
<map:parameter name="srcPattern"
value="cocoon:/letter.*.*.archive"/>
<map:parameter name="appendSrcPattern"
value="cocoon:/letter.*.*.view.ondemand"/>
<map:parameter name="ccRecipients"
value="{cct-package:count(/recipient/advisor)}"/>
<map:parameter name="requiredRecipients"
value="{cct-package:count(/requiredRecipients/requiredRecipient)}"/>
<map:act type="centralPrintCopy">
<map:parameter name="packageID" value="{cct-package:/id}"/>
<map:parameter name="srcPattern"
value="cocoon:/letter.*.*.print"/>
<map:parameter name="ccRecipients"
value="{cct-package:count(/recipient/advisor)}"/>
<map:parameter name="requiredRecipients"
value="{cct-package:count(/requiredRecipients/requiredRecipient)}"/>
<map:parameter name="lst_test_mode"
value="{request-param:lst_test_mode}"/>
<map:act type="dbms-printCentralPackage">
<map:parameter name="table-set"
value="PrintCentralPackage{../../../../fromInstance}"/>
<map:call resource="processUnlockPackage">
<map:parameter name="unlock" value="{../../../../../unlock}"/>
<map:parameter name="actionType"
value="{../../../../../actionType}"/>
<map:parameter name="redirect" value="showConfPage"/>
</map:call>
</map:act>
<map:call resource="processUnlockPackage">
<map:parameter name="unlock" value="{../../../../unlock}"/>
<map:parameter name="redirect"
value="cocoon:/printCentralPackage.error"/>
</map:call>
</map:act>
<map:call resource="processUnlockPackage">
<map:parameter name="unlock" value="{../../../unlock}"/>
<map:parameter name="redirect"
value="cocoon:/printCentralLetter.error"/>
</map:call>
</map:act>
</map:otherwise>
</map:select>
<map:call resource="processUnlockPackage">
<map:parameter name="unlock" value="{../../unlock}"/>
<map:parameter name="redirect"
value="cocoon:/onDemandArchive.error"/>
</map:call>
</map:when>
<map:otherwise>
<!-- Queue the Central Print Package instead -->
<map:act type="dbms-queueCentralPackage">
<map:parameter name="table-set"
value="QueueCentralPackage{../../fromInstance}"/>
<map:call resource="processUnlockPackage">
<map:parameter name="unlock" value="{../../../unlock}"/>
<map:parameter name="actionType"
value="{../../../actionType}"/>
<map:parameter name="redirect" value="showConfPage"/>
</map:call>
</map:act>
<map:call resource="processUnlockPackage">
<map:parameter name="unlock" value="{../../unlock}"/>
<map:parameter name="redirect"
value="cocoon:/queueCentralPackage.error"/>
</map:call>
</map:otherwise>
</map:select>
</map:act>
<map:call resource="processUnlockPackage">
<map:parameter name="unlock" value="{../unlock}"/>
<map:parameter name="redirect"
value="cocoon:/generateSubmission.error"/>
</map:call>
</map:when>
<map:otherwise>
<map:redirect-to
uri="cocoon:/invalidDeliveryMethodForSubmission.error"/>
</map:otherwise>
</map:select>
</map:resource>
Re: Locationmaps and Lenya integration
Posted by Thorsten Scherler <th...@apache.org>.
On Wed, 2005-05-25 at 19:51 -0400, Gregor J. Rothfuss wrote:
> Ross Gardler wrote:
>
> > I'm going to come back to this after we have submitted the Apachecon
> > presentation. I'd like to see how Thorstens work integrates with
> > locationmap as that is the next thing I need in Forrest. It makes using
> > things like Daisy or Lenya far easier and may be the ideal place for
> > view configurations like this one. I'll catch up with Thorstens recent
> > RT's and try and bring the locationmap idea into them.
>
> hmm, can you explain this a bit more? i haven't followed the list very
> closely and would appreciate a quick summary as to how this could
> improve said integration?
>
I leave this part to ross because I still have to have a closer look on
locationmaps. ;-)
> forgive me my ignorance, but when i see things like
>
> <forrest:views xmlns:forrest="http://apache.org/forrest/templates/1.0"
> xmlns:logic="http://apache.org/forrest/logic/1.0">
> <logic:filter value="dirCut" parameter="p">
> <forrest:view format="inx" />
> </logic:filter>
> <logic:filter value="actorCut" parameter="p">
> <forrest:view format="inx" />
> </logic:filter>
>
> i am wondering if forrest is moving into a direction of 'programming in
> xml'. is this the case?
I do not like this expression 'programming in xml' it is more (like I
stated in other threads) 'configuring components with xml'.
This code should help *user* easily change the output of forrest. In the
end this code should be produced by tools.
...and btw I would like to see such clear intuitive configuration and
separation in lenya and not a parameter overkilled framework that allows
user to extend the framework if they *exactly* follow the *not easy* to
understand boundaries and rules of the framework where you can do
everything you want as long it is the lenya way.
*User* want to have a configuration file (or better (in the future) a
tool where they can create such a file) to alter the behavior of their
application. They do not want to learn cocoon/java to alter the default
behavior. You have worked on PostNuke, you should know that for
yourself, as a user you do not want to learn php. ;-)
> is there a document / discussion / wiki page
> somewhere that explains the goals behind this?
>
The goal is that a normal user do not have to understand much of
programming (nor cocoon or java) but rather can configure forrest in an
easy intuitive way to customize it the way they want. The view e.g.
should be created by a webdesigner that have *no* knowledge of
programming at all.
Devs on the other hand want an easy to understand and clear defined
interface where they can plugin new components.
Search the ml for view;view helper;leather;...
...or do you *really* consider
<logic:filter value="dirCut" parameter="p">
<forrest:view format="inx" />
</logic:filter>
<logic:filter value="actorCut" parameter="p">
<forrest:view format="inx" />
</logic:filter>
as programming???
salu2
> thanks,
>
> -gregor
>
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: Locationmaps and Lenya integration
Posted by David Crossley <cr...@apache.org>.
Hi Gregor, this is a peep from the sidelines, as i don't know much.
We are storing links to threads about locationmaps if it helps:
http://issues.cocoondev.org/browse/FOR-200
--David
Re: Locationmaps and Lenya integration
Posted by Ross Gardler <rg...@apache.org>.
Gregor J. Rothfuss wrote:
> Ross Gardler wrote:
>
>> I'm going to come back to this after we have submitted the Apachecon
>> presentation. I'd like to see how Thorstens work integrates with
>> locationmap as that is the next thing I need in Forrest. It makes
>> using things like Daisy or Lenya far easier and may be the ideal place
>> for view configurations like this one. I'll catch up with Thorstens
>> recent RT's and try and bring the locationmap idea into them.
>
>
> hmm, can you explain this a bit more? i haven't followed the list very
> closely and would appreciate a quick summary as to how this could
> improve said integration?
Wow, that is good timing. I was working on that (locationmaps) for the
first time for months this morning.
Locationmaps are configuration files that separate the physical location
of files from the URL space in use. In other words they are a way of
mapping:
http://www.myserver.com/my/path/to/my/file.xml
to something like:
http://www.lenyaCMS.com/lenya/path/to/their/file.xml
or
http://www.daisyCMS.com/lenya/path/to/another/file.xml
or whatever repository we wish to use.
They are nothing more than a config file.
> forgive me my ignorance, but when i see things like
>
> <forrest:views xmlns:forrest="http://apache.org/forrest/templates/1.0"
> xmlns:logic="http://apache.org/forrest/logic/1.0">
> <logic:filter value="dirCut" parameter="p">
> <forrest:view format="inx" />
> </logic:filter>
> <logic:filter value="actorCut" parameter="p">
> <forrest:view format="inx" />
> </logic:filter>
>
> i am wondering if forrest is moving into a direction of 'programming in
> xml'. is this the case?
Thorsten will have to argue the case on this one as right now views are
are one man band and the rest of us have not yet got our heads around
them. Many of the Forrest devs will be at ApacheCon and we will be
having a major session on trying to understand what Thorsten is trying
to do, why and what its implications are.
> is there a document / discussion / wiki page
> somewhere that explains the goals behind this?
Search the archives for RT's by Thorsten, there are quite a few.
Ross
Locationmaps and Lenya integration
Posted by "Gregor J. Rothfuss" <gr...@apache.org>.
Ross Gardler wrote:
> I'm going to come back to this after we have submitted the Apachecon
> presentation. I'd like to see how Thorstens work integrates with
> locationmap as that is the next thing I need in Forrest. It makes using
> things like Daisy or Lenya far easier and may be the ideal place for
> view configurations like this one. I'll catch up with Thorstens recent
> RT's and try and bring the locationmap idea into them.
hmm, can you explain this a bit more? i haven't followed the list very
closely and would appreciate a quick summary as to how this could
improve said integration?
forgive me my ignorance, but when i see things like
<forrest:views xmlns:forrest="http://apache.org/forrest/templates/1.0"
xmlns:logic="http://apache.org/forrest/logic/1.0">
<logic:filter value="dirCut" parameter="p">
<forrest:view format="inx" />
</logic:filter>
<logic:filter value="actorCut" parameter="p">
<forrest:view format="inx" />
</logic:filter>
i am wondering if forrest is moving into a direction of 'programming in
xml'. is this the case? is there a document / discussion / wiki page
somewhere that explains the goals behind this?
thanks,
-gregor
Re: New Plugin: Filtering output
Posted by Ross Gardler <rg...@apache.org>.
Ferdinand Soethe wrote:
>
>
>
> David Crossley wrote:
>
>
>>><apachecon label="ApacheCon">
>>> <slides label="Slides" href="s5slides/ssp_with_forrest.html"
>>> filter="cleanSlides.xsl"/>
>>> <slides label="Slides" href="s5slides/ssp_with_forrest.html"
>>> filter="speakerSlides.xsl"/>
>>> <slides label="document" href="ssp_with_forrest.html"
>>> filter="printedVersion.xsl"/>
>>></apachecon>
>
>
>>I asked this question before, but there was a flurry of activity
>>at the time and i don't think that there was a reply.
>
>
>>I don't understand how those site entries would get used
>>for linking. They are all the same.
>><a href="site:apachecon/slides">clean</a>
>><a href="site:apachecon/slides">speaker</a>
>><a href="site:apachecon/slides">print</a>
>
>
> Sorry, must have missed that. Of course you are right. The site excerpt
> should have been to enable linking.
Doh! I missed that in my alternative approach too, thank goodness for
"many eyes" when such a simple issue can get overlooked.
However, Thorstens,method seems to address that issue.
I'm going to come back to this after we have submitted the Apachecon
presentation. I'd like to see how Thorstens work integrates with
locationmap as that is the next thing I need in Forrest. It makes using
things like Daisy or Lenya far easier and may be the ideal place for
view configurations like this one. I'll catch up with Thorstens recent
RT's and try and bring the locationmap idea into them.
Ross
Re: New Plugin: Filtering output
Posted by Ferdinand Soethe <sa...@soethe.net>.
David Crossley wrote:
>> <apachecon label="ApacheCon">
>> <slides label="Slides" href="s5slides/ssp_with_forrest.html"
>> filter="cleanSlides.xsl"/>
>> <slides label="Slides" href="s5slides/ssp_with_forrest.html"
>> filter="speakerSlides.xsl"/>
>> <slides label="document" href="ssp_with_forrest.html"
>> filter="printedVersion.xsl"/>
>> </apachecon>
> I asked this question before, but there was a flurry of activity
> at the time and i don't think that there was a reply.
> I don't understand how those site entries would get used
> for linking. They are all the same.
> <a href="site:apachecon/slides">clean</a>
> <a href="site:apachecon/slides">speaker</a>
> <a href="site:apachecon/slides">print</a>
Sorry, must have missed that. Of course you are right. The site excerpt
should have been to enable linking.
>> <apachecon label="ApacheCon">
>> <slidesClean label="Slides" href="s5slides/ssp_with_forrest.html"
>> filter="cleanSlides.xsl"/>
>> <slidesSpeaker label="Slides" href="s5slides/ssp_with_forrest.html"
>> filter="speakerSlides.xsl"/>
>> <slidesPrint label="document" href="ssp_with_forrest.html"
>> filter="printedVersion.xsl"/>
>> </apachecon>
--
Ferdinand Soethe
Re: New Plugin: Filtering output
Posted by David Crossley <cr...@apache.org>.
Ferdinand Soethe wrote:
>
> Working on our presentation for ApacheCon, Ross and I have the problem
> that the presentation contains a lot of internal info and also some
> that should only be part of someversions (speaker version, slide
> version, printed notes).
>
> They are marked up with class attributes, so filtering is possible,
> the question is where.
>
> And since filtering might vary on a per document basis, I was
> wondering whether we could have a filtering plugin that can be applied
> before any other output plugin and apply the filtering needed.
>
> Ideally the criteria would be defined in the site element.
>
> So instead of my current version (that opens the presentation as a
> normal Forrest document as well as an s5-slideshow)
>
> <apachecon label="ApacheCon">
> <slides label="slides" href="s5slides/ssp_with_forrest.html"/>
> <slides label="document" href="ssp_with_forrest.html"/>
> </apachecon>
>
> I could then have
>
> <apachecon label="ApacheCon">
> <slides label="Slides" href="s5slides/ssp_with_forrest.html"
> filter="cleanSlides.xsl"/>
> <slides label="Slides" href="s5slides/ssp_with_forrest.html"
> filter="speakerSlides.xsl"/>
> <slides label="document" href="ssp_with_forrest.html"
> filter="printedVersion.xsl"/>
> </apachecon>
I asked this question before, but there was a flurry of activity
at the time and i don't think that there was a reply.
I don't understand how those site entries would get used
for linking. They are all the same.
<a href="site:apachecon/slides">clean</a>
<a href="site:apachecon/slides">speaker</a>
<a href="site:apachecon/slides">print</a>
--David
> where the xsl-files contain the desired filter.
>
> Am I thinking along the right track here or are there better ways to
> do this.
>
> I first wanted to create this as output plugin, but since all there is
> is custom xsl which can be different for each file, I didn't think
> this would made a lot of sense.
>
> --
> Ferdinand Soethe