Style Handling in odf4j - Text Documents

Hi Lars,

The background of my idea is that once i get the
"style-name" for an
element, I query the style information associated with that
"style-name" in <office:automatic-styles> in
"content.xml" so that I
can retrieve all the "local" style information.

I am trying to do that using:

CODE
---------

 NodeList nl =
doc.getElementsByTagNameNS(Namespaces.office,
"automatic-styles");

        try{
        System.out.println("Dummy" +
nl.item(0).getFirstChild().getLocalName());
        }catch(NullPointerException e){

----------

However,I get a NullPointerException which should not be the
case
since the first child  of
"office:automatic-styles" is the style
information associated and enclosed between
<style:style>..</>

Once i get the attribute list associated with each
"style-name" I can
retrieve all the style properties.

This is how I intend to proceed.

Is this the correct approach? What am I missing?

Regards,

-- 
Amit krishna Saha
[URL]:http://amitsaha.in
.googlepages.com

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribeodftoolkit.openoffice.org
For additional commands, e-mail: dev-helpodftoolkit.openoffice.org

Amit,

I looked through the code that you sent to me...

In this particulat case, the NullPointerException occurs
because the 
automatic-styles element of the testdocuemnt1.odt file is
empty. 
Node.getFirstChild() consequently returns null thus the
chained 
getLocalName message gets sent to a null-reference,
resulting in an 
exception.

You must be much more careful when working with DOM
interfaces to check 
returned values for validity and nodeType. Otherwise you
will create 
many similar bugs which in unlucky cases may not be as easy
to spot as 
this one. Since we agreed to use java 1.5 as a baseline for
the odf4j 
work, I'd recommend using XPath to search for nodes rather
than 
traversing the DOM tree manually - at XML Prague, Oleg
Parashchenko used 
a rephrased version Greenspun’s Tenth Rule of Programming:
"Any 
sufficiently complicated tree navigation library contains an
ad hoc 
informally-specified bug-ridden slow implementation of half
of Xpath." - 
Since we do have XPath available in Java, we should use it
instead 
manually navigating the tree and falling into the trap
described above.

The getStyle call on the TextDocument class should take a
parameter of 
type String and return the Style object corresponding to
that named 
style - not a NodeList.

Navigating the styles should not be the responsibility of
the 
TextDocument class but rather be handled by the
StyleFactory.

Element.getStyle should not return the style name as string
but rather 
the actual Style object retrieved from the StyleFactory. An
additional 
method getStyleName can be used for just getting the name.

Element.getStyle was declared to take a parameter of type
Element, which 
didn't make any sense to me. It should operate on the
instance to which 
the message was sent and not on the object passed as a
parameter.

We may need to distinguish between style families. I.e.
charactzer 
style, paragraph style etc... I'm not sure whether we should
have 
individual accessors (getParagrapgStyle, getCharacterStyle
etc) or 
whether we should work with lists of applicable style...
What di you think?

Cheers,
Lars

Amit krishna Saha wrote:
> Hi Lars,
> 
> The background of my idea is that once i get the
"style-name" for an
> element, I query the style information associated with
that
> "style-name" in
<office:automatic-styles> in "content.xml"
so that I
> can retrieve all the "local" style
information.
> 
> I am trying to do that using:
> 
> CODE
> ---------
> 
> NodeList nl =
doc.getElementsByTagNameNS(Namespaces.office,
> "automatic-styles");
> 
>        try{
>        System.out.println("Dummy" + 
> nl.item(0).getFirstChild().getLocalName());
>        }catch(NullPointerException e){
> 
> ----------
> 
> However,I get a NullPointerException which should not
be the case
> since the first child  of
"office:automatic-styles" is the style
> information associated and enclosed between
<style:style>..</>
> 
> Once i get the attribute list associated with each
"style-name" I can
> retrieve all the style properties.
> 
> This is how I intend to proceed.
> 
> Is this the correct approach? What am I missing?
> 
> Regards,
> 


-- 
Sun Microsystems                Lars Oppermann
<lars.oppermannsun.com>
Nagelsweg 55                    Software Engineer
20097 Hamburg, Germany          Phone: +49 40 23646 959
http://www.sun.com/       
     Fax:   +49 40 23646 550
------------------------------------------------------------
-----------
Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee
1,
D-85551 Kirchheim-Heimstetten, Amtsgericht Muenchen: HRB
161028
Geschaeftsfuehrer: Wolfgang Engels, Dr. Roland Boemer
Vorsitzender des Aufsichtsrates: Martin Haering

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribeodftoolkit.openoffice.org
For additional commands, e-mail: dev-helpodftoolkit.openoffice.org

> You must be much more careful when working with DOM
interfaces to check
> returned values for validity and nodeType. Otherwise
you will create
> many similar bugs which in unlucky cases may not be as
easy to spot as
> this one. Since we agreed to use java 1.5 as a baseline
for the odf4j
> work, I'd recommend using XPath to search for nodes
rather than
> traversing the DOM tree manually - at XML Prague, Oleg
Parashchenko used
> a rephrased version Greenspun’s Tenth Rule of
Programming: "Any
> sufficiently complicated tree navigation library
contains an ad hoc
> informally-specified bug-ridden slow implementation of
half of Xpath." -
> Since we do have XPath available in Java, we should use
it instead
> manually navigating the tree and falling into the trap
described above.

What do you mean in particular? Id not get the point here

> Element.getStyle should not return the style name as
string but rather
> the actual Style object retrieved from the
StyleFactory. 
Agreed

> An additional method getStyleName can be used for just
getting the name.
Why is this needed?
We can simply use GetStyle(...).Name to get the style name

getStyleName i deem is not needed


> We may need to distinguish between style families. I.e.
charactzer
> style, paragraph style etc... I'm not sure whether we
should have
> individual accessors (getParagrapgStyle,
getCharacterStyle etc) or
> whether we should work with lists of applicable
style... What di you think?
it's not a good idea to have many different accessors for
style (like
getParagrapgStyle, getCharacterStyle). We should have
something more
abstract and consistent.



------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribeodftoolkit.openoffice.org
For additional commands, e-mail: dev-helpodftoolkit.openoffice.org

Hi Darius,


On 7/13/07, Darius Damalakas <darius.damalakasgmail.com> wrote:
>
> What do you mean in particular? Id not get the point
here

Pretty obvious. This is an extension of the IRC meeting
between me and
LO + the code i sent him. So you are missing the context
here


Cheers ,
-- 
Amit krishna Saha
[URL]:http://amitsaha.in
.googlepages.com

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribeodftoolkit.openoffice.org
For additional commands, e-mail: dev-helpodftoolkit.openoffice.org

Hi Lars,

I am working on the "XPath" stuff to query the
"style information". I
have also noted the other points you mentioned.

I should be able to update you in the coming few days.

Regards

-- 
Amit krishna Saha
[URL]:http://amitsaha.in
.googlepages.com

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribeodftoolkit.openoffice.org
For additional commands, e-mail: dev-helpodftoolkit.openoffice.org

Darius Damalakas wrote:
>> Since we do have XPath available in Java, we should
use it instead
>> manually navigating the tree and falling into the
trap described above.
> 
> What do you mean in particular? Id not get the point
here

Since XPath is available in J2SE 1.5, it is not worth the
effort to 
manually write code to search for particular nodes in the
DOM. This is 
more conveniently achieved by using the existing
functionality offered 
by the platform. More conveniently both in terms of code
complexity and 
programmer productivity.

>> Element.getStyle should not return the style name
as string but rather
>> the actual Style object retrieved from the
StyleFactory. 
> Agreed
> 
>> An additional method getStyleName can be used for
just getting the name.
> Why is this needed?
> We can simply use GetStyle(...).Name to get the style
name
> 
> getStyleName i deem is not needed

My reasoning was that getting the style name directly from
the element 
is a convenient functionality that does not add any
additional cost to 
any of the other functionality. I thus saw no reason for
excluding it.

On further examination you may actually be correct since the
value of 
the style-name property is in fact not the UI style name but
rather a 
style identifier which is purely used to reference the style
structure 
which contains the real name which can be presented to the
user.

It may still be good to include shortcut versions to
frequently used 
style properties (such as the name) at the the content
object level as 
convenience functions.

Cheers,
Lars

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribeodftoolkit.openoffice.org
For additional commands, e-mail: dev-helpodftoolkit.openoffice.org

Hi,

>>> An additional method getStyleName can be used
for just getting the name.
>> Why is this needed?
>> We can simply use GetStyle(...).Name to get the
style name
>>
>> getStyleName i deem is not needed
> 
> My reasoning was that getting the style name directly
from the element
> is a convenient functionality that does not add any
additional cost to
> any of the other functionality. I thus saw no reason
for excluding it.

Ok, understand your reasoning.

My basic point is that it makes the code not very elegant
and not truely
object oriented.

Basically, if there is an object style, then all info must
be taken from
that object. So an additional getStyleName makes much higher
coupling
between objects, and that is exactly what we do not want.

If we decide to remove the getStyleName, i suggest we mark
this method
as Obsolete, so that the change will be made gradually


------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribeodftoolkit.openoffice.org
For additional commands, e-mail: dev-helpodftoolkit.openoffice.org

Hi Darius,

As odf4j is in a prototype stage and there is no official
release yet, I 
do not think that it is necessary to make methods as
obsolete/deprecated 
at this point. We simply remove them as a normal refactoring
activity. 
Once we start to stabilize the API that is another thing,
but right now 
there is no need to maintain such clutter.

Thanks,
Lars

Darius Damalakas wrote:
> Hi,
> 
>>>> An additional method getStyleName can be
used for just getting the name.
>>> Why is this needed?
>>> We can simply use GetStyle(...).Name to get the
style name
>>>
>>> getStyleName i deem is not needed
>> My reasoning was that getting the style name
directly from the element
>> is a convenient functionality that does not add any
additional cost to
>> any of the other functionality. I thus saw no
reason for excluding it.
> 
> Ok, understand your reasoning.
> 
> My basic point is that it makes the code not very
elegant and not truely
> object oriented.
> 
> Basically, if there is an object style, then all info
must be taken from
> that object. So an additional getStyleName makes much
higher coupling
> between objects, and that is exactly what we do not
want.
> 
> If we decide to remove the getStyleName, i suggest we
mark this method
> as Obsolete, so that the change will be made gradually
> 
> 
>
------------------------------------------------------------
---------
> To unsubscribe, e-mail: dev-unsubscribeodftoolkit.openoffice.org
> For additional commands, e-mail: dev-helpodftoolkit.openoffice.org
> 


-- 
Sun Microsystems                Lars Oppermann
<lars.oppermannsun.com>
Nagelsweg 55                    Software Engineer
20097 Hamburg, Germany          Phone: +49 40 23646 959
http://www.sun.com/       
     Fax:   +49 40 23646 550
------------------------------------------------------------
-----------
Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee
1,
D-85551 Kirchheim-Heimstetten, Amtsgericht Muenchen: HRB
161028
Geschaeftsfuehrer: Wolfgang Engels, Dr. Roland Boemer
Vorsitzender des Aufsichtsrates: Martin Haering

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribeodftoolkit.openoffice.org
For additional commands, e-mail: dev-helpodftoolkit.openoffice.org

Hi Lars,

Given the "style-name" of an element, say
"P1", is the following Xpath
2.0 query correct/valid to extract the other details of the
"style-name" enclosed in
<office:automatic-styles>

XPath Query
------------------

for $style in
/office:document-content/office:automatic-styles/

 if $style/style:name = 'P1' then return
$style/style:family,
$style/style:parent-style-name



Please let me know, so that I can proceed with the Java
implementation

Regards,

-- 
Amit krishna Saha
[URL]:http://amitsaha.in
.googlepages.com

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribeodftoolkit.openoffice.org
For additional commands, e-mail: dev-helpodftoolkit.openoffice.org

Hi Lars,

The CVS version of "Element.java" defines the
method "getStyle() " as follows:

public String getStyle() {
        NamedNodeMap map = getNode().getAttributes();
        Node attr =
map.getNamedItem("text:style-name");

        // if there is a text:style-name attribute return
its value,
null otherwise
        if (node != null) {
            return node.getNodeValue();
        } else {
            return null;
        }
    }

I think there is a small mistake here and we should have
"node" in
place of "attr"
Please find the modified "Element.java"

Regards & Thanks

-- 
Amit krishna Saha
[URL]:http://amitsaha.in
.googlepages.com

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribeodftoolkit.openoffice.org
For additional commands, e-mail: dev-helpodftoolkit.openoffice.org

Hi Amit,

Yep thanks. attr is alright. We just need to return
attr.getNodeValue 
and not node.getNodeValue...

Anyway. This method will return the actual Style object
anyway 
referenced by the element. How is that coming along?

Bests,
Lars

Amit krishna Saha wrote:
> Hi Lars,
> 
> The CVS version of "Element.java" defines the
method "getStyle() " as 
> follows:
> 
> public String getStyle() {
>        NamedNodeMap map = getNode().getAttributes();
>        Node attr =
map.getNamedItem("text:style-name");
> 
>        // if there is a text:style-name attribute
return its value,
> null otherwise
>        if (node != null) {
>            return node.getNodeValue();
>        } else {
>            return null;
>        }
>    }
> 
> I think there is a small mistake here and we should
have "node" in
> place of "attr"
> Please find the modified "Element.java"
> 
> Regards & Thanks
> 
> 
>
------------------------------------------------------------
------------
> 
>
------------------------------------------------------------
---------
> To unsubscribe, e-mail: dev-unsubscribeodftoolkit.openoffice.org
> For additional commands, e-mail: dev-helpodftoolkit.openoffice.org

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribeodftoolkit.openoffice.org
For additional commands, e-mail: dev-helpodftoolkit.openoffice.org

Hi Lars,

Please find the updated "Style.java" and
"Element.java"

Regards
-- 
Amit krishna Saha
[URL]:http://amitsaha.in
.googlepages.com

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribeodftoolkit.openoffice.org
For additional commands, e-mail: dev-helpodftoolkit.openoffice.org