Re: [RT] A new Forrest implementation?

[Addi]

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