David Crossley wrote:
Ross Gardler wrote:
Thorsten Scherler wrote:
Ross Gardler escribi??:
The Drawbacks
=============
What are the drawbacks of getting rid of Cocoon?
Probably the biggest drawback would be that we have to code it. There's
not a huge amount of work to be done, but there are some neat things in
Cocoon that we would have to reimplement or find elsewhere. We may be
able to extract some of the code from Cocoon, but I'm not convinced this
is a good approach.
Because of this need to write the code it will mean that Forrest would
initially take a step backwards in terms of its functionality.
The other thing is that the existing community is right now pretty much
cocoon orientate. Dropping cocoon in 2.x can have the side effect that
the current community *may* loose interest in forrest (cocoon have been
a big selling point in the past).
The critical question is, how many people (as devs) can we attract to
join the rewrite dropping cocoon, taking a step back in functionality,
focusing on java for new components?
How many committer and devs will work on branch, how many on trunk, how
many on both?
I hope to see a healthy discussion, which will give some leads regarding
above questions.
This is very important, thanks for highlighting it.
I'd like to ask how many developers here do anything other than write
XML and XSLT in Forrest?
(We need to hear responses from all Forrest developers
on these questions.)
Me. I use the sitemap extensively. I don't call that
simply "writing XML". I don't need to create new
Cocoon Generators or Transformers because the default set
from Cocoon provides more than i need.
Which means that you only use forrest to do XML/XSLT processing. The
sitemap is only one way of configuring this processing.
I appreciate that you like the sitemap for its ease of configuration in
many use cases. I love it too, in a limited domain. My point though, is
that having all the baggage that the sitemap brings with it is
proibitive to a great many users who only do XML/XSLT transformations.
Sure aggregation is important, but that is part of the rendering process
not the generation process. This is especially true if one adopts the
Dispatcher, or Velocity or some other templating engine.
But I don't want to enforce any particular design pattern on you or any
other user/dev, just as I don't want to be forced into any particular
web framework by my publishing technology.
It is this last paragraph that makes me think your suggestion of Cocoon
as a generic Input/Ouyput plugin is the best idea so far. We can both
work as we wish.
How many actually use Forrest in an environemnt where it is doing
anything more than building a website?
It depends what do you mean by "website"? I use web
technologies on my internal network and i have some
complex public websites.
For example, i have a Forrest server running on my
desktop which scrapes remote web pages to extract recent
stock market announcements and show me only the stocks
that i am interested in.
[DISCLAIMER - my next para is not meant to criticise your implementation
of this, I am sure you have decided to implement this way for good
reasons. However, I will use this example in order to identify the
problems that Forrest presents in this approach]
Scraping a screen is a bad way to implement a data collection syste. If
the page layout changes the app. changes. Instead we need a reliable
format feed (CSV, RSS, XML or whatever) and a custom plugin to read and
process that format.
If the format is XML and is available over a netowrk connection then we
can do this by getting the document and processing it with XSLT. So all
we need is a XSLT processor.
If its not an XML feed then we need a custom plugin. Forrest today
requires the developer to dig into Forrest. It requires them to use Java
(or some very nifty sitemap programming) thus it requires a
non-superficial knowledge of Cocoon.
Now, you and I may be comfortable with this requirement but most users
are not. Result... most of our users can't do it and don't want to learn
how to do it. What we need is a Forrest implementation that does not
force the user to use a given techology to build their plugins
(including Cocoon as has been made clear in this RT).
I'd suggest that the thing to do is ensure that we support the building
of simple websites quickly in order to quickly support what I suspect is
the vast majority of our users.
Why would such people be using Forrest? If they only
want simple websites, then there are plenty of other
tools out there.
The fact is that they do use Forrest for this. We encourage it with our
home page too.
We have heard from a couple of users who started with Forrest this way,
attracted by the promise that it is simple to extend then they
discovered it was not and lost interest.
Ross
