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
