incubator-odf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michał Jaskurzyński <jasko...@gmail.com>
Subject Re: GSoC: ODF Command Line Tools Application
Date Mon, 19 Mar 2012 20:35:04 GMT
2012/3/19 Svante Schubert <svante.schubert@gmail.com>:
> 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.

Mime
View raw message