forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <>
Subject Re: [Proposal] remove views from forrest (Re: Views as a Domain Specific Language)
Date Mon, 30 May 2005 01:17:47 GMT
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:

In which we went from:

<forrest:contract name="feeder">
       <forrest:properties contract="feeder">
         <forrest:property name="feeder" nugget="get.nugget.feeder">
             <feed id="shows">
	    <feed id="sf">
         <forrest:property name="feedConfig">
           <feed id="planetJava" maxItem="10" descr="false"/>

To a nice clean and more understandable:

<forrest:contract name="feeder">
    <forrest:properties contract="feeder">
      <forrest:property name="feeder" nugget="get.nugget.feeder">

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=""
   <logic:filter value="dirCut" parameter="p">
      <forrest:view format="inx" />
   <logic:filter value="actorCut" parameter="p">
      <forrest:view format="inx" />

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 ). 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.


View raw message