2012/3/19 Svante Schubert <[email protected]>: > On 19.03.2012 17:30, Michał Jaskurzyński wrote: >> Hi Rob, >> >>> One observation: you >>> have a -s parameter that contains a mini script of commands. Could >>> this be a in a separate file as well, which could make it easier to do >>> more complex scenarios? >> Yes, I mentioned that in first example. -S will read script from file >> >> >> >We could even have a special "small language" >>> for text processing of WYSIWYG documents. The interesting thing about >>> that approach is that the same syntax could be implemented on multiple >>> languages, e.g., ODF Toolkit for a GSoC project, but then someone else >>> could implement on top of Apache POI to support MS Office documents. >>> So it will be good to have a clean abstraction and separation between >>> the command layers and the ODF-manipulation layers. >>> >>> I think the Simple API that we have today is a good level of >>> abstraction for many text operations, but it requires a skilled Java >>> programmer to work with it. They don't need to understand ODF in >>> detail, but they do need to understand Java. >> I think that most of commands can by translated directly to java api >> >> so script like this: >> >> newImage(filename); >> addParagraph(content); >> addList("element1", "element2"); >> addTable(3, 3); >> >> This approach can be easily implemented in our tool and it will let to >> create odf documents from shell script. The another advantage is that >> programmer will not have to learn new api. >> > I assume that the above code is meant similar to a stack, where every > command is appending an entity to an ODF document, right? > What if you want to add something to arbitrary places within a document, > for instance reusing ODF entity once created? > Like if you are not referencing by parameters of an operation to a > certain place in the document, it might indicate that the component > should be appended to the end of the document. > > Some similar approach as you plan is under development in OASIS, where > the changes of a document are saved in a queue of operations in a new > ODF XML file called undo.xml. To be precisely the operation to undo the > changes are being saved, as new ODF change-tracking. > Basically the idea is the same and these operations are intended to be > overtaking as high-level API to this project. > I have uploaded last Friday some examples [1] and there is presentation > [2] providing an overview to this approach. > Perhaps this work might be inspiring. > > Svante > > [1] > http://www.oasis-open.org/committees/document.php?document_id=45463&wg_abbrev=office-collab > <http://www.oasis-open.org/committees/document.php?document_id=45463&wg_abbrev=office-collab> > > [2] > http://www.oasis-open.org/committees/document.php?document_id=45161&wg_abbrev=office-collab > <http://www.oasis-open.org/committees/document.php?document_id=45161&wg_abbrev=office-collab>
I think the best way is to store in memory last element for each type. For example: getParagraphById(2); will store this paragraph as a actual to work on, so next commands will change it: paragraphSetHorizontalAlignment(CENTER); paragraphSetFont(Arial, BOLD, 16); Next command in script: addParagraph(test paragraph); will overwrite this paragraph variable I choose these script syntax because implementing full script language would be very hard task.
