Marc Portier wrote: > also having the saveDocument and loadDocument you propose here > _outside_ the woody specific flowscript seems to make them more > widely re-useable in different areas! > > with those in place I think my previous idea to 'extend' the Form > object from woody2.js is a nice (almost trivial) example left to the > reader (meaning that if that gets into cvs it should probably be in > some 'samples' directory) > > wdyt?
While thinking about how useful a general-purpose-flow-layer-Javascript-library might be I figured it would make more sense to have such utility functions as Java components (like PipelineUtil). SourceUtil does indeed have a writeDOM method (in addition to a toDOM(source) method) whose signature however looks a little too verbose for flowscript use and I wonder how useful a FlowSourceUtil modeled after PipelineUtil would be. I would be a little bit reluctant however to duplicate every tiny utility class for the flow layer. Even more so that up to now there does not seem to be a common sense about what the right abstraction level of flowscript code is. There is definately a need for general purpose functions and utilities besides the FOM and I wonder wether there should be some sort of "offcially supported" user level API or just a bunch of utility functions. Although I believe we should try to keep the flow layer as much "user level" as possible, I'm not at all 100% certain that there is a rule as to when to cross the border between weakly typed Javascript and strongly typed Java. Therefore (and to gather experience how to modularize Javascript code :-), as of yet, I'm + 1 to find a place to put utility functions like this. Guido
