GullFOSS
OpenOffice.org Engineering at Sun
 
Subscribe

Today's Page Hits: 95

 
Archives
 
« October 2008
SunMonTueWedThuFriSat
   
1
2
3
4
5
6
8
9
10
11
12
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
 
       
Today
Links
Flickr Photos
More Flickr photos tagged with openoffice
Locations of visitors to this page
all tags: 3.0 accessibility apache api aqua architecture automated_tests base beta build calc chart code community compiler cws database development directx document download draw eis events export extensions features filter framework graphics gsl gsoc gullfoss i18n import impress installation irc iso26300 java l10n localization mac macros netbeans oasis odf odff ooo ooocon ooxml open opendocument openformula openoffice openoffice.org party patch pdf performance plugin podcast porting qa quality quaste release report scripting sdk security snapshot software specification spreadsheet staroffice statistics statuspage sun svg templates testing toolkit tools usability user-experience vba web wiki writer writerfilter xml xslt
« Juggled by Tasks... | Main | DLL Hell, Everywhere »
Thursday, 29 Nov 2007
Custom properties and fields
Mathias Bauer

Sometimes new features take several releases before they are finally done. That happened and still happens for the custom property text fields in Writer.

In the old StarOffice times a documents could have four “user defined” properties that were stored in the “document summary information” stream of the OLE Storage based file format, along with other meta data like title, subject etc. Each of these properties could have a name and a (string) value. We still have these properties in the current OOo version. We also have text fields in Writer that refer to these properties in the same way as other document info fields refer to the built-in properties “Subject”, “Title” etc. These fields can be found in the “DocInformation” tab of the “Insert Fields - Other” dialog.

ODF is a big improvement over that: it allows for an arbitrary number of user defined properties that also can have other types than string (number and date). Again they are stored together with the built-in properties, now in the meta.xml stream of ODF document.

Until now we didn't provide any Writer text fields to support the user defined properties in OOo, though ODF also knows them. It was just one of all the things we still have to do. And we also didn't support these properties in the “Document Properties” dialog, we still have the notorious four properties with string values there. In the current OOo version adding, removing and changing user defined properties can be done only by manual editing of the meta.xml or by using a UNO API at runtime.

Using this API in Basic is quite simple:

if not ThisComponent.DocumentInfo.PropertySetInfo.HasPropertyByName("MyProp") then
    ThisComponent.DocumentInfo.AddProperty("MyProp",0,"")
endif
ThisComponent.DocumentInfo.MyProp = "MyValue"
print ThisComponent.DocumentInfo.MyProp

adds a user defined property called “ MyProp” and assigns the value “MyValue” to it and then displays the value of the property in a message box.

ThisComponent.DocumentInfo.RemoveProperty("MyProp")

will remove the property again.

In OOo2.0 we added the import of Word, Excel and Powerpoint custom properties and document variables into ODF user defined properties by using this API internally in our import filter. This enabled users to port their solutions (mostly VBA macros) using the properties in Word documents into OOo Basic, Java, Python or whatever language they used for automating OOo.

In OOo2.4 we now add Writer text fields that directly support these properties. If a document has user defined properties, the “Insert Fields - Other” dialog will show them in the tab “DocInformation” so that users can create fields based on them. Though the ODF specification uses the term “ user defined” for both the properties and the text fields we think that users are more accustomed to “custom” properties and fields and so we decided to use that in our user interface. Another reason was that we don't want to confuse the “user defined fields” with the “user fields” we already have.


These new text fields will of course also be used for importing Word custom fields. Until now they had been imported as “user fields” that just show a snapshot of the property value but don't get updated when this value is changed (e.g. by the API shown above).

What we are now missing is a UI that allows to add, remove and change custom properties like it is possible for our current four string properties. This new UI will be provided in OOo3.0 and it will replace the “user defined” tab page in the “document properties” dialog.


Feedback is welcome – either on the dev[at]sw.openoffice.org mailing list if your comment is more development related or on discuss[at]ux.openoffice.org if you want to discuss the user interface.


tags:

Posted by Mathias Bauer on 29 Nov 2007  |  PermaLink |  Bookmark to del.icio.us Bookmark to del.icio.us |  Digg this Digg this  |  Comments[7]

Comments:

While this is a solid improvement, I'm afraid the larger picture dampens my enthusiasm a bit. Is it so good to have a half-dozen different kinds of property storage[*]--all doing basically the same job--but with slightly different capabilities, limitations and interfaces?

I could really get excited about unifying Writer's menagerie of fields behind a single nice property UI and a solid expression language that allowed flexible access to all the properties, and was shared among all the OOo apps.

And have that ready sometime next week, would you? ;-) ;-)

I'm no XML whiz, but could we do something like storing an RDF file under META-INF, and build in access to that? That would use existing standards and be completely open-ended, no?

[*] Variables, user fields, number ranges, input fields, "DocInformation" fields, "Document" fields, page variables, ...

Posted by Joe on November 29, 2007 at 07:10 PM CET #

It's as I wrote: many things can be done step by step. Re-thinking the text fields zoo a bit - why not? But should we wait with the custom fields until we have to time to actually do that? I believe many users will prefer to get something now and not the "big bang" solution in one or two years.

The problem is that we have many things to do and also many of them didn't get fixed until now because we always wanted to do everything in one step. I think it's good to start with what you can get done in the next release and then proceed from there.

Though I agree in general that something can be done wrt. to the text fields UI I'm not sure if I agree to all of your suggestions in particular. But at least I can say that ODF 1.2 with support for meta data and the meta data text field will perhaps be exactly what you described in your last sentence. We will start working on that soon.

Posted by Mathias Bauer on November 29, 2007 at 07:57 PM CET #

Yeah, Matthias, WRT to Joe's points, I'm really surprised you don't even mention the new metadata system in your post, which is ALL about custom descriptions (properties, but not only; since it's based on RDF, it gives you more flexibility).

It might be good to coordinate such that the new work on metadata will be a complement to the more incremental work you're doing now? I honestly don't see how you can be talking about proposals for a new UI for custom properties without doing that alongside the metadata development.

Posted by Bruce D'Arcus on November 29, 2007 at 08:38 PM CET #

Hi Bruce,

I want to have something for my next blog. :-)
Seriously: as the meta data spec is still not final and we didn't even start to work on implementing it in OOo, I think it's too early to talk about UI for it now. And Svante already blogged about the general aspects some time ago.

But promised, you will read something about meta data here from the Writer team soon. I'm thrilled about what we can do with it, especially with the meta text field. But now is 2.4 - let's talk about 3.0 later.

For the moment I think pleasing many users that want to migrate from Word to Writer but couldn't because of the missing custom fields is a good story also.

Posted by Mathias Bauer on November 29, 2007 at 08:56 PM CET #

Rather than complain, let me be specific with some suggestions that would allow this work to be used with the new metadata support in ODF 1.2.

Take a look at this post of mine on a web UI Norm Walsh was working on:

<http://netapps.muohio.edu/blogs/darcusb/darcusb/archives/2006/09/14/photo-metadata>

So he had a separate UI to configure the property display (where, in RDF fashion, the property is named using a URI). Also, values should not only be allowed to be strings, but also other objects (where the target is a URI, and the UI is perhaps a select list).

That's the kind of thing that would be good to think about now rather than later.

Posted by Bruce D'Arcus on November 29, 2007 at 09:04 PM CET #

Oops, we crossed paths. OK, sounds good. But my second reply still applies I guess.

Posted by Bruce D'Arcus on November 29, 2007 at 09:06 PM CET #

Until now we're using these properties to hide some information from the user (e.g. where the document is stored in our database, some information on work-flow and others).
In Word the same can be done using the "Document Variables". If the user doesn't know the name, the variables are only visible with VBA-code, which is forbidden.

So - in which way can we use confidential information in versions =>2.4?

(Of course I know that with unzipping the file all information can be seen, but for the user this is impossible.)

Posted by Peter Eberlein on December 03, 2007 at 11:15 AM CET #

Post a Comment:
Comments are closed for this entry.
« Juggled by Tasks... | Main | DLL Hell, Everywhere » GullFOSS