forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <rgard...@apache.org>
Subject Re: [RT] A new Forrest implementation?
Date Tue, 22 Aug 2006 22:53:04 GMT
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

Mime
View raw message