forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Addi <>
Subject Re: [RT] A new Forrest implementation?
Date Wed, 16 Aug 2006 10:51:50 GMT
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 <>

/Addi Berry/
240-274-0875 <>

View raw message