I haven't written to this blog for quite a long period of time...
Just to summarize: my official task for GSoC has been completed :)

now I will be working on another project for OpenOffice.org : implementing XForms model in UNO.
In any case, if I somehow return back to the AODL, I'll write here ;)

I will be on my vacation till July, 29.
Cheers!

I've just released a new version of AODL.
Several major and minor bugs have been fixed and new tests were introduced.

Major bugs:
- When performing TextDocument.Forms.Remove or TextDocument.Forms.Clear the appropriate ODFControlRefs were not removed from the content collections. As a result, "placeholders" pointing to non-existent controls remained in the document
- The same for ODFForm.Controls

I will continue looking for new bugs :)

We've been disputing about storing field references in a centralized container with my mentor Lars Behrmann :)
I've made some changes to the code to fit the exact needs:

1. I've added a base abstract class Field. It fully implements the
IContent interface and has a Value property (internal field value).
It also has an internal _collection property that defines the content
collection it is located in (paragraph etc.)

2. A typed FieldsCollection has been added and a Fields property to
the TextDocument class.
FieldsCollection has FindFieldByName method that helps to look up the desired
field in the collection; such methods as Add, Remove etc. are
overloaded in such a way that they support full synchronization with
the content collection the field snippet is _really_ stored in.
IContentCollection has also been modified to maintain this
synchronization.

for example think about this piece of code:

Paragraph p1 = new Paragraph(td);
p1.TextContent.Add(new SimpleText(td, "Insert text here: "));
Placeholder plch1 = new Placeholder(td, PlaceholderType.Text, "A text placeholder");
plch1.Value = "Text";
p1.Content.Add(plch1);
td.Content.Add(p1);

after executing this, td.Fields will contain the plch1 Placeholder
reference.
If we do this:

Field f = td.Fields.FindFieldByValue("Text");
td.Fields.Remove(f);

the field will also be removed from p1.Content.
And conversely, if we do
p1.Content.Remove(plch1),
the td.Fields collection will be empty :)

3. Of course, the TextDocument.Fields collection is properly filled
while doing import.

4. When exporting a document to HTML, any field is replaced with its
internal value.

Now I'm working on testing all these new features :)

I've spent some time coding the initial implementation of the Fields.
Currently mostly all the features required by the official GSOC task are completed.

Fields that are fully functional:
- TextInput
- VariableSet
- PageNumber
- DateField
- Placeholder

I've also created a series of tests and made some improvements to the Forms.
At present time both export and import of Fields are supported :)

Here is my preliminary vision of Fields:

1. All the fields-related classes are located in AODL.Document.Fields namespace
2. All the Fields classes that represent the appropriate 'content' snippets implement the IContent interface.
3. Placeholder and TextInput classes stand for text:placeholder and text:text-input fields respectively.
4. Placeholder class has such properties as PlaceholderType, Value, Description and some others. PlaceholderType is an enumeration.
5. TextInput class has such Value, Descriptions properties etc.
6. Implementation of text:variable-set will be separated in two classes: VariableDecl and VariableSet. VariableDeclCollection will be a class deriving from CollectionWithEvents to handle variable declaration lists.
7. VariableDecl will stand for variable declaration snippet. Main properties besides Name and Node: Name and VariableValueType
8. TextDocument is augmented with a variable declaration list property
9. TextDocument has methods to find any VariableDecl. For example, by its name.
10. VariableSet is a class that implements the text:variable-set. It has a series of properties bound to the possible attributes of text:variable-set tag.
11. Of course, there will be some kind of synchronization between the two last mentioned classes
12. Import/export handlers will support fields.

Hi everybody who reads this blog,
this week I gonna be a little more busy than before because of my summer exams at the University. So I will probably be posting to this blog more rarely :)
My AODL Forms implementation (first part of my GSOC objective) is nearly finished. After some discussions with my mentor Lars Behrmann we decided that the thing I will concentrate now on is fixing bugs, writing tests and creating a demo application.
The first two points are in progress now. The third one is almost completed, but I've changed the initial goal - it was writing a demo application that loads any ODF file and creates a panel with controls corresponding to them. However, there could be a lot of problems with their positioning (ponder about a 100-page document with ODF Forms on every page). Of course, a scrollable panel could be created, but I decided to make a little bit simplier app that just creates a panel with a fixed set of controls and then "exports" and "imports" its values from the similar ODF Form.
Nevertheless, if I have enough time I will add extra features to it :)

The next step is ODF Fields - my second part of the GSoC!
I will be creating a detailed overview of their implementation soon.

Cheers!

Upd. I've just found a nasty bug producing an error while performing New-Load-Save, New-New-Save or Load-Load-Save with the same TextDocument instance.
It's already fixed :)

At present time I am creating a series of tests for the AODL forms.
After I finish fixing bugs I'll play with the nested forms a little bit - frankly speaking, I didn't pay too much attention to this concept before...

After that I'll upload a beta version to the CVS :)
Cheers!

+ Added forms support for spreadsheets (experimental)

As I have already previously mentioned, one of the problems connected with an export to HTML is a controls positioning.

I've studied the way OpenOffice does this. It uses float:left style. Of course, the controls get mixed up and they are not arranged exactly in the same way they are in the original document...
But nevertheless I have decided to implement the forms HTML export in the same way as OpenOffice does.

From now on, new controls are supported by the AODL:

• ODFImage
• ODFImageFrame
• ODFValueRange

Basically speaking, at present time all the controls that can be found in OpenOffice are implemented :)

I've just finished the most tedious part of the job - adding description to all the members of all the ODF Forms classes!

I've added some HTML export stuff to the AODL (currently buttons, text areas, check boxes, radio buttons, frames and fixed texts are supported).
There is one thing I'm working on now: positioning.
Currently, css position:absolute is being used but this induces problems if the paragraph contains not only controls, but also text or some other content - it gets mixed on the screen. Hope to fight this problem ;)

The alpha-version is ready and I am going to commit it directly to the CVS repository. This commitment is a little bit delayed because of the fact I still don't have the commit privilege; hope the OpenOffice admins will fix it soon.
At present time I'm going yo add some more controls (more "exotic" and rarely used) and, of course, to document each function and add some comments.
After that I'll switch to HTML export, improving ODF import/export and , surely, fixing bugs :))

- added ODFListBox, ODFComboBox, ODFFile, ODFFrame, ODFHidden controls.
- added ODFItem and ODFOption auxiliary classes that work together with ODFComboBox and ODFListBox respectively.
- fixed some bugs with import/export

Some new changes since the last version:
- Added form:properties support to all controls
- Added import for form:properties (including controls)
- Added different search methods to look for any property by its name
- changed OO prefix to ODF in all the control classes

I've uploaded a very early preview of Forms support implementation for
AODL library with a small test application.
Currently supported
- Forms, including nested ones. For text documents.
- Auxiliary properties (form:properties)
- Controls for form:textarea and form:button (OOTextArea and
OOButton). Other controls are represented through OOGenericControl
- Synchronization of draw:control with the appropriate form element;
however, I need to work on it more
- Methods to look for a specific control by its name or ID.
- Basic import/export to *.odt

You can download it here:
http://rapidshare.com/files/30019373/AODL_Test_Forms.zip

I've created a simplified UML diagram for Forms implementation.
NB! Only the most important classes are shown on the diagram; any of their unimportant members are omitted. (private or protected members are also omitted unless they are very important)

I've created a core Forms implementation following the scheme I've spoken before.
Of course, it is just a sketch but it already has some functionality now.
Currently implemented:
- Complete support for OOForm class that stands for form:form tag. All its attributes are reflected in the appropriated properties.
TextDocument class has Forms property. No nested forms support yet. No support for import, only test support for export (it will be completely rebuilt). Search methods are also not implemented.
- Support for form:properties.
- Basic support for controls (with synchronization). Currently base class OOFormControl with aggregated OOControlRef are done. I have also created working classes OOText and OOButton (form:text and form:button respectively)

I would like to speak a little bit more about form:properties, 'cause I haven't discussed it earlier.
In a nutshell, there are six classes: FormProperty, SingleFormProperty, ListFormPropertyElem, ListFormPropertyElemCollection, ListFormProperty and FormPropertyCollection.
FormProperty is a base class for both kinds of properties: single value and multiple value. SingleFormProperty stands for a single value property(form:property) and has such properties as Name, Value and PropertyValueType.
ListFormProperty : Name, PropertyValueType and PropertyValues.
PropertyValues is a collection (ListFormPropertyElemCollection), each element of which is ListFormPropertyElem.
I think it's quite clear:)

I'm a lazy guy and I haven't drawn a class diagram for all this stuff yet ;)) But I'll do it, I promise :)

I have decided to resolve the synchronization between the draw:control in the contents nodes and the appropriate form:form element in the following way:

A new auxiliary class AODL.Document.Forms.Controls.OOControlRef will be added; this is an internal AODL class that stands for draw:control tag. It will have such properties as ID, X,Y,Width,Height,AnchorType, AnchorPageNumber,StyleName,TextStyleName and others that reflect draw:control attributes. And, of course, it will have a set of common properties such as Node.

OOFormControl will be a basic class for all form controls. All specific controls such as Button will derive from it.OOFormControl will have an internal variable _controlRef (OOControlRef) that represents its reference; all the public properties of _controlRef will be accessible through public OOFormControl properties.

OOFormControl will have a constructor taking parent form, content container and ID string as obligatory parameters. Of course, there will be other handy overloaded constructors with more parameters.

OOForm's controls collection will have Inserted and Removed events to implement the synchronization:

private void ControlsCollection_Inserted(int index, object value)
{
OOFormControl ctrl = value as OOFormControl;
this._FNode.AppendChild(ctrl.Node);
ctrl._contentCollection.Add(ctrl._controlRef);
}

private void ControlsCollection_Removed(int index, object value)
{
OOFormControl ctrl = value as OOFormControl;
this._FNode.RemoveChild(ctrl.Node);
ctrl._contentCollection.Remove(ctrl._controlRef);
}

I'll also add appropriate deletion of control in form:form tag when the reference is deleted.

I've come down with the flu. Sore throat + fever :(
Hope to recover soon.

Today I've been playing a little bit with the AODL library, investigating its inner structure.
I've also created a basic core of Forms support. Of course, there are very few features available now, but they seem to work correctly.
Gonna have more fun with it today :)

At present time I'm thinking of main architectural features of Forms implementation.
The following ideas are just "pre-alpha" ideas :)

Here is the way I see it:

• The main classes for Forms support are located in the AODL.Document.Forms namespace.
• Each form is represented by the OOForm class; this class should contain such properties as Href, TargetFrame, Method and others (which are the attributes of a form:form tag). It should implement the IHtml interface (however, we'll need to think more about exporting nested forms to HTML)
• Those properties that have several possible values should have an enum type.
• Properties listed in form:properties tag should be reflected in a FormProperties property of OOForm (these properties are application-specific). It should be some kind of a collection descending from the CollectionWithEvents class.
• Each form should have a collection of child controls (ControlList); ControlList will be a class derived from CollectionWithEvents.
• Everything connected with controls will be located in AODL.Document.Forms.Controls
• A separate class will stand for each control type (such as Text, TextArea, Button, CheckBox etc.). I'm also thinking of introducing a base interface for all controls (IOOFormControl with such properties as Id, Type and, perhaps, Node).
• OOForm will have methods that help to search for any child controls (for example, FindControlById).
  
• Each form has a property that represents child (one level below) forms. We should also remember that top-level form is situated in office:forms tag (unlike for those that are nested)
• TextDocument class will have a series of smart methods that provide search for any form/control in the entire document (using BFS on the nested forms tree).
• TextDocument and, perhaps, OpenDocumentTextExporter and OpenDocumentImporter should be expanded to handle forms correctly while saving/loading a document.
• ..... and, of course, there are tonns of other things that must be listed here, but I've forgotten to mention them ;)))
  

One more thing that I ponder now is synchronizing draw:control and form:id. Inserting draw:control tags won't be a problem; however, I'm not yet sure about the way I'll handle deleting controls from forms that have their references in draw:control tags.
I see three basic ways:

• No synchronization. The easiest and the most flexible way. While adding new draw:control, you can arbitrary reference any control, including non-existing ones (just passing their id as a string). And when you delete a control reference from a form's control list, nothing extra happens. The contras of this approach are obvious.
• Basic synchronization: the same as above, but while deleting some control all tags that reference it are deleted.
• You cannot reference non-existent controls. When you delete some control all tags that reference it are deleted.

That's it :) Of course, I'm going to extend these ideas a lot in the future...

Hi folks,
This blog will be dedicated to my participation in Google Summer of Code program.
I will be working on the AODL project. AODL is an open source C# library that allows you to create, load and manipulate OpenOffice documents (currently *.odt and *.ods are supported) directly (no instance of installed OO is required). You can read the project wiki to learn the details:
http://wiki.services.openoffice.org/wiki/AODL

My responsibilities within GSoC are to create full support for forms (and, perhaps, the XForm model) and fields. I will be posting messages about my progress here in this blog and on a special wiki page:
http://wiki.services.openoffice.org/wiki/.net_Module_AODL:_Forms_and_Fields_implementation

Cheers!