Difference between revisions of ".net Module AODL: Forms and Fields implementation"

Revision as of 17:19, 29 April 2007

This is the wiki page for the Google Summer_of_Code_2007 proposal by Oleg Yegorov and mentored by Dieter Löschky and Lars Behrmann.

Proposal

FORMS
The first part of my project is to implement Forms support for the AODL library. My vision of it (briefly):

1. The main classes for Forms support are located in the AODL.Document.Forms namespace.
2. 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)
3. Those properties that have several possible values should have an enum type.
4. 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.
5. Each form should have a collection of child controls (ControlList); ControlList will be a class derived from CollectionWithEvents.
6. Everything connected with controls will be located in AODL.Document.Forms.Controls
7. A separate class will stand for each control type (such as Text, TextArea, Button, CheckBox etc.).
8. OOForm will have methods that help to search for any child controls (for example, FindControlById).
9. 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)
10. 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).
11. TextDocument, OpenDocumentTextExporter and OpenDocumentImporter should be expanded to handle forms correctly while saving/loading a document.

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:

1. 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.
2. 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.
3. 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.
4. OOForm's controls collection will have appropriate Inserted and Removed events to implement the synchronization.
5. I'll also add synchronous deletion of control in form:form tag when the reference is deleted.

FIELDS
The implementation of Fields is quite similar to the implementation of Forms (even less tricky).
TODO
Create UML diagram for Forms classes

Current Status

Current status: investigating the current implementation of AODL, creating a detailed project specification
Project blog: http://soc-aodl.blogspot.com

Student Task List

• Subscribe to ODF Toolkit mailing list. Done.
• Submit a filled-out copy of the Joint Copyright Assignment form (JCA). Done.
• Workout initial implementation details. Done
• Create a detailed project proposal. In progress

Further information about the ODF Toolkit

AODL code AODL Wiki page
The ODF Toolkit Wiki page.
The ODF Toolkit project homepage on the OpenOffice.org website.