Adam R. B. Jack wrote: > > We have gump.document.text, and we could create gump.document.html > that use cheetah to write it.
Stefano Mazzocchi wrote:
+1 in removal of forrest and go plain XHTML + CSS. But please, let's use a velocity-like approach, not a DOM like approach!
I may be reading too much into Stefano's words, but if so, the following is how I see things.
At the moment, gump.document.* take a complete set of knowledge and produce a set of artifacts. The best analogy to Cocoon for this would be a serializer which terminates a pipeline.
An alternate approach would be to completely flip this. Have the equivalent logic drive the acquisition of certain pieces of information, which can be processed as it is being received. The best analogy to Cocoon for this would be a generator which is at the beginning of a pipeline. Classic gump is closer to this model... after a brief generation phase, the execution of the resulting script triggers actions, the output of which is intermixed with some static and some generated output.
I'm not much into abstract architectural discussion. I tend to focus on tangible and measurable quanties that matter to real people. In this case, it is clear that Gump is expected to run for a long period of time, and I view not having ANY output until EVERYTHING is done as something less than ideal.
Producing output as the information becomes available can also dramatically reduce working set sizes.
- Sam Ruby
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
