forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Crossley <>
Subject Re: [RT] A new Forrest implementation?
Date Wed, 23 Aug 2006 07:08:51 GMT
Ross Gardler wrote:
> David Crossley wrote:
> >Ross Gardler wrote:
> >>
> >>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.

I also use aggregation at the input stage. Perhaps you
call that rendering. See below.

> 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]

Good idea. Me I want to help to identify some of the
beauties of our current system and ensure that they
flow to anything new.

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

Oh sure, but these websites don't provide any such thing.
The html pages, thankfully consistent, are all that we have.

Sure if it breaks, then i need to tweak my stylesheets.
That is not difficult. If my app was based on an xml feed
and its structure changed, then my stylesheets would too.

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

It does not come as XML. So i use "nifty sitemap programming".
However, i see that as straightforward use of the sitemap.

It aggregates three input sources, each of which is separately
retrieved, generated, and transformed by other sitemap matches.
This aggregate is then transformed into the internal format.

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

I think you are over-generalising there. See below.

> 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 probably need to change our home page.

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

One point that i was trying to make, is that we might
need to re-assess who is our target. I, for one, am here
to build a project that handles semi-advanced to advanced
publishing needs. I don't want to appeal to users who
only want "simple websites", especially ones who cannot
be bothered to explore beyond the basics.


View raw message