Community
Participate
Working Groups
From Bug 396543. File I/O seems horrible, but the handling of multiple input and output models programmatically is currently awkward. I have had to recommend use of a spurious top level container of models. Provision of an 'initial' load of a model variable from an external file, relative to a invocation context, and a 'final' save of a model variable again to a file relative to an invocation context would be useful for debugging and general multi-input/output scenarios. If the saved model happens to be a String then you have MtoT file I/O. First suggestion, something like transformation MyTx(in inFiles : Folder, out outFiles : Folder); var myModel : MyModel := inFiles("my/Input.dat"); outFiles("my/Output.dat") := .... Folder is a new built in type perhaps with some helper functions such as files(), folders(). Some semantics. a load failure may throw an Exception. load and save occur just once. Repeated loads share the one load. Repeated saves throw an Exception. i.e no anarchic update/append. But a single load-recompute-save is permitted. all saves occur after all resolves have happened, i.e. pretty much as QVTo exits. No saves occur for a premature exit.
(In reply to Ed Willink from comment #0) > From Bug 396543. > > File I/O seems horrible, but the handling of multiple input and output > models programmatically is currently awkward. I have had to recommend use of > a spurious top level container of models. Provision of an 'initial' load of > a model variable from an external file, relative to a invocation context, > and a 'final' save of a model variable again to a file relative to an > invocation context would be useful for debugging and general > multi-input/output scenarios. If the saved model happens to be a String then > you have MtoT file I/O. > > First suggestion, something like > > transformation MyTx(in inFiles : Folder, out outFiles : Folder); > > > var myModel : MyModel := inFiles("my/Input.dat"); > > outFiles("my/Output.dat") := .... > > Folder is a new built in type perhaps with some helper functions such as > files(), folders(). > > Some semantics. > > a load failure may throw an Exception. > > load and save occur just once. Repeated loads share the one load. Repeated > saves throw an Exception. i.e no anarchic update/append. But a single > load-recompute-save is permitted. > > all saves occur after all resolves have happened, i.e. pretty much as QVTo > exits. No saves occur for a premature exit. Hi Ed, Proposal looks reasonable. Also it correlates with Bug 295193. As for implementation details I don't see necessity in providing any built-in types/functions. Blackbox library extension solves described scenario. 'Folder' type will be simplified to regular String.
I don't know enough about blackboxes to see how they can help. I think a built-in type is needed to signal in the Transformation signature that the parameter corresponds to a hierarchical node in some repository (typically a filesystem folder). A library type is sufficient to allow programmatic traversal inFiles.files()->forAll(file : String | ....)
(In reply to Ed Willink from comment #0) > If the saved model happens to be a String then you have MtoT file I/O. Yes, but a rather different issue to multi-file I/O. See Bug 534575 for a much simpler approach to supporting transformation in the XML and Text technology spaces.
