> I'll certainly guilty of being away for a while, but > gump.document.forrest is not a small thing, and to my eyes, not entirely > obvious.
It is really just a lot of repetative simple code, building simple xdoc pieces. It it's pretty, but it isn't that bad. We have gump.document.text, and we could create gump.document.html that use cheetah to write it. I looked at Cheetah and liked the ability to create templates as classes, and sub-class (perhaps aggregate) such, but when I thought about it I couldn't really find much real different from what was going on with gump.document.forrest. Basically Cheetah requires code within the template to map memory into locations, and I didn't find it hughly different than what is there. Also, if we want both xdoc and html output we'd need to set of tempaltes (with code in) which isn't nice. Still, I think forrest is a sticking point. I'd like a pure Python solution, and I suspect Cheetah is the best way to go. BTW: I'm eager to see some graphics. If SVG can be written (in XML, viua Python) can Forrest convert these to images (using Batik or somethough?) I'll happily continue with Forrest if that is a good way to get images rendered. > A design point for the original gump is that output was viewable as it > was produced. Is this the case for gumppy w/ forrest? No, everything is stored in files with memory context. With gump.document.forrest we write a bunch of xdocs in one pass (before we call forrest). regards, Adam --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
