You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by "Gregor J. Rothfuss" <gr...@apache.org> on 2005/05/26 01:51:40 UTC
Locationmaps and Lenya integration
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: 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