Hi folks, I haven't been active on the list for quite a while now but
do still skim. I don't use Forrest anymore but still like the concept
Not to bore you but just for some context - My main interest in Forrest
was that it did format transformations using XML stuff I could (mostly)
understand. I am not a lifelong programmer - I'm new to the IT world
in general about 4 years ago. I knew how to use email before then -
that was about as technical as I got. Today I am mainly an XHTML, CSS
developer with enough PHP to hack other people's code and get what I
need. I mainly work with PHP-based CMS now but I would still love to
have the transformation work that Forrest does.
I can't comment on the framework suggestion from a technical point of
view - Cocoon is just beyond me to even pretend to evaluate. But
anything that smacks of a "simpler" Forrest catches my attention. I
really did try to dig in deeper when I first came to Forrest but with
my limited programming background it was just too much to hack
through. Will changing the framework make it any easier for me? I
don't know, but I know that trying to learn the external components
that currently go into Forrest didn't work for me.
I'll go back to the recesses of lurking again now.
Ross Gardler wrote:
Here's an opinion of a dev that has been
lurking on this list for some time.
Excellent, it's really important that we hear views from everyone with
an interest. If we do something radical we have to be sure it is the
right thing to do.
I much appreciate the conceptual design of
forrest where a single internal format is used as the target of input
transformations and as the source of output transformations.
Yes, I agree. This is something that must not change. In fact, if we
make such a radical change on the underlying code then I'm sure we will
also take the opportunity to move to XHTML2, something we've wanted to
do for a long time.
However I agree with Ross that there is much
unneeded complexity involved in using Forrest relative to the
functionality it provides. I currently choose not to debug problems I
in Forrest simply because this entails delving into too many seemingly
overengineered components with not much relevance to the problem
I am trying to solve.
This is precisely what I thought was happening, although we can't
assume you are typical, it would be great to hear from others.
However, it is true that I have also grown tired of fighting to debug
stuff in Forrest. One of the other advantages of moving to a more
simple Java implementation is that we will gain the ability to write
unit tests for each component and test it in isolation of the rest of
Luckily for me, the forrest devs usually
quickly fix the problems so that I don't even have to report them. The
fact remains however that I would have enjoyed giving something back.
This is all to say that I would be happy to contribute to a cleaner
implementation of Forrest.
It's good to hear that you think such a move might help you become more
involved in Forrest. If your case is typical then I'm certain that this
would be a good move, but we need to hear from more people like you to
help us decide what to do.