2.0x --> 2.1x user field behavior change

Posted on 2010-01-26 04:33:28.456023-08 by ads

Hello All,

At $DAYJOB I've recently inherited a codebase using OO::OODoc to insert provided values into fields of existing templates in the OpenOffice 1.0 format. The code (unmaintained for years) is currently running on an old OO::OODoc version 2.011, and does not work correctly on any version newer than than 2.035 (the last in the 2.0x series still available on CPAN). I'd like to get it running on 2.111.

The code basically invokes userFieldValue( $field_name, $new_value ) to set the values of the fields. When using OO::OODoc 2.0x, the field values are visible when viewing the saved .sxw file in OpenOffice.org Writer (tried with several OOo versions, both 2.x and 3.x). When using OO::OODoc 2.1x, the field values are not visible when viewing the saved .sxw file.

In all cases, I can see that the values are actually present in the saved .sxw file, since userFieldValue( $field_name ) returns them, regardless of whether or not the fields are visible in Writer. This leads me to suspect that the behavior I'm seeing is related to styles, and that something has changed in this regard between OO::OODoc 2.0x and 2.1x; but I confess that I'm entirely ignorant the OpenOffice file format and how this stuff hangs together.

Just frobbing, I've tried invoking updateUserFieldReferences( $field ) when running the code under OO::OODoc 2.1x to no avail. Ditto for replacing 'member' with 'part' when creating various doc instances. Both were just clumsy attempts to "modernize" the code based on some initial investigations; obviously I need to delve deeper.

As I work through the learning curve, my workaround for the moment is to simply run the code on OO::OODoc 2.035.

I would be grateful for any enlightenment and/or nudges in the right direction.

Thanks,
-Al

Direct Responses: 12246 | Write a response

Posted on 2010-01-26 08:25:11.238097-08 by ads in response to 12243

Re: 2.0x --> 2.1x user field behavior change

Just want to provide some additional information:
The user defined field I'm looking at are in table cells.
With OO::OODoc 2.0x, the content.xml portion of the .sxw file contains:

<text:user-field-decl text:name="my_field" text:string-value="whatever" text:value-type="string" />

With OO::OODoc 2.1x, the content.xml contains:

<text:user-field-decl text:name="my_field" text:string-value="" table:value="whatever" text:value-type="string" />

If I explicitly set the 'string-value' attribute, I then see the value when viewing the .sxw file in Writer:

$element->set_att('text:string-value', q{WHATEVER} );

I'll be digging into the OpenOffice 1.0 file spec for info related to the above. Could someone confirm that setting 'table:value' when invoking $doc->userFieldValue( $field_name, $new_value ) is correct behavior?
Thanks,
-Al

Direct Responses: 12248 | 12252 | Write a response

Posted on 2010-01-26 12:07:18.974451-08 by jmgdoc in response to 12246

Re: 2.0x --> 2.1x user field behavior change

Hello,

The userFieldValue() apparently works fine with the current standard, i.e. the OpenDocument format (ODT, ODS, ODP files and so on), but it doesn't correctly support the old OpenOffice 1.0 format (SXW, SXC, SXI, etc). Up to know, this bug was unnoticed because the SXW format was already deprecated when OpenOffice::OODoc 2.1x got out (2008), so nobody complained in this forum.

As a possible immediate workaround, you can convert your SXW document(s) into ODT then check if everything goes right with OODoc 2.111 (please let's know if it works). For later, knowing that the bug has been reported in the tracker (#54004), I'll try to fix it in the future release.

Direct Responses: 12259 | Write a response

Posted on 2010-01-26 13:13:48.42881-08 by jmgdoc in response to 12246

Re: 2.0x --> 2.1x user field behavior change

To answer the last question, the following code is OK to update user fields with text content:

$element->set_att('text:string-value', "whatever");

Provided that, of course, $element is a user field element previously retrieved by name using getUserField("name").

However, it's just a hack that allows to wait either a new release of OpenOODoc (where, hopefully, the userFieldValue() bug will be fixed) or the full replacement of SXW by ODT. It will *not* work with user fields whose value type is not text; for example, the right attributes are "text:date-value", "text:time-value", and "text:value" respectively for date, time and numeric fields.

Direct Responses: Write a response

Posted on 2010-01-27 03:08:40.58941-08 by ads in response to 12248

Re: 2.0x --> 2.1x user field behavior change

> As a possible immediate workaround, you can convert your SXW document(s) into > ODT then check if everything goes right with OODoc 2.111 (please let's know if > it works).

I'll give that a shot and report back. Thanks much for all the info.

-Al

Direct Responses: 12262 | Write a response

Posted on 2010-01-27 05:21:25.69493-08 by ads in response to 12259

Re: 2.0x --> 2.1x user field behavior change

Posted on 2010-01-27 03:08:40.58941-08 by ads in response to 12248

> > As a possible immediate workaround, you can convert your SXW document(s) into > > ODT then check if everything goes right with OODoc 2.111 (please let's know if > > it works). > > I'll give that a shot and report back. Thanks much for all the info. > > -Al

Unfortunately it seems that our codebase contains some processing specific to the SXW format; I converted the templates to ODT, but our code choked on 'em. I see that you've released OO::OODoc 2.112. I'll take that for a whirl...

-Al

Direct Responses: 12263 | Write a response

Posted on 2010-01-27 05:32:17.405845-08 by ads in response to 12262

Re: 2.0x --> 2.1x user field behavior change SOLVED

Posted on 2010-01-27 05:21:25.69493-08 by ads in response to 12259

> I see that you've released OO::OODoc 2.112. I'll take that for a whirl... > > -Al

OO:OODoc 2.112 fixes the issue for us. Thank you very much for this new release!

-Al

Direct Responses: Write a response

Perl Weekly newsletter
A free weekly newsletter for people who are busy to read all the blogs. click here to check it out.