Sorry about that. My mail client should have changed it for me. I'll
have to go tinker with that....
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 of it.
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.
- Addi
Ross Gardler wrote:
Maurice Gittens 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 encounter
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
the system.
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.
Ross
--
/Addi Berry/
240-274-0875
[EMAIL PROTECTED]
www.rocktreesky.com <http://www.rocktreesky.com>
--
/Addi Berry/
240-274-0875
[EMAIL PROTECTED]
www.rocktreesky.com <http://www.rocktreesky.com>
