Stefano Mazzocchi wrote: <big snip/>
>> Here the generator reads an Excel document from the input stream that >> is submitted by the context, and translate it to some xml format. The >> serializer write its xml input in the file system. I reused the names >> generator and serializer partly because I didn't found any good names >> (deserializer is the inverse to serializer, but what is the inverse of >> a generator?) > > There is none, because the opposite of generation would be destruction > and you are definately *not* distructing something, but still *generate* > it. Where the data the generator uses comes from is *not* an > architectural concern and should not modify the component's name. One could argue that the opposite of a generator is a "motor", or more generally, a "utilizer"... <big snip/> >> In Flowscripts >> -------------- >> >> IIRC the discussion and examples of input for flowscripts this far has >> mainly dealed with request parameter based input. If we want to use >> flowscripts for describing e.g. web service flow, more advanced input >> handling is needed. IMO it would be an excelent SOC to use output >> pipelines for the presentation of the data used in the system, input >> pipelines for going from input to system data, java objects (or some >> other programming language) for describing business logic working on >> the data within the system, and flowscripts for connecting all this in >> an appropriate temporal order. > > A while ago, I proposed the addition of a new flowscript method that > would be something like this > > invoquePipeline(uri, parameters, outputStream) > > that means that the flow will be calling the pipeline associated with > the given URI, but the serializer will write on the given outputStream. > > Since there were already too many irons in the fire, I wanted to see the > flowscript settle down before starting to push for this again, but your > RT brings back pressure on this concept and I think this is all we need > to remove the asymmetry from cocoon pipelines. This seems to me to mostly close the circle: the "utilizer" being the "outputstream"... <big snip/> --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
