[jsword-devel] BookDataListener: Question 1

[Joe Walker]

Hi,

Thanks for the ideas Eric, I've re-numbered them 6[abc] rather than
5[abc] to save conflict with Jacky's ideas

Eric Galluzzo wrote:
> How about this one.  We can make the existing interface even more
> SAX-like by passing each method a map of attributes.  In general I
> strongly dislike what I call "map-oriented programming" (i.e. no objects
> but just maps of maps of maps -- generic but meaningless), but I think
> that perhaps in this case the map is warranted.
> 
> This could be expressed in three ways:
> 
> 6a.
> 
> public interface BookDataListener
> {
>     void startWord( Map attributes );
>     void endWord();
>     void startReference( Map attributes );
>     void endReference();
> }
> 
> Advantages:
>     - very extensible
>     - small API to maintain
> 
> Disadvantages:
>     - hard to use (what goes in the map?)
>     - tied tightly to XML

Unless I misunderstand what "tied tightly to XML" means, I think
everything will have the same problem, since we are modelling OSIS which
is XML.
Oh, hang on - explained below, I think that all attributes must be
strings, and we can't use types like Passage?
There is only one place I can think of that use of non-obvious types
(String, int, etc) is required, and that is osisID, which maps well to
Verse. (We can convert using verse.getOsisName();)

> 6b.
> 
> public interface BookDataListener
> {
>     void startWord( OSISAttributes attributes );
>     void endWord();
>     void startReference( OSISAttributes attributes );
>     void endReference();
> }
> 
> public class OSISAttributes
> {
>     Passage fPassage;
>     String fMorph;
> 
>     public Passage getPassage()
>     {
>         return fPassage;
>     }
...

There is a simpler half-way house (call it 6d?) - we define a list of
attributes using a typesafe Enum pattern (like jakarta commons-lang
Enum), and then definde OSISAttributes to have:

void setAttribute(OSISAttrName name, String value)
String getAttribute(OSISAttrName name)

Which in my book gets the benefits of 6b and 6a

> 6c.
> 
> public interface BookDataListener
> {
>     void startWord( WordAttributes attributes );
>     void endWord();
>     void startReference( ReferenceAttributes attributes );
>     void endReference();
> }
> 
> public class CommonAttributes
> {
>     // common attributes here
> }
> 
> public class WordAttributes extends CommonAttributes
> {
>     protected String fMorph;
> 
>     public String getMorph()
>     {
>         return fMorph;
>     }
> 
>     public void setMorph( String morph )
>     {
>         fMorph = morph;
>     }
> 
>     // ...
> }

Like you I'm not keen on this, mostly because it creates lots of classes


> I'd probably favor 5b myself.  Failing that, I'd favor the original #2
> (populating an XML-like tree ourselves).  The only problem with that, as
> you said, is depending heavily on auto-generated classes, which means
> that if JAXB suddenly changes, we're out of luck; and we can't add our
> own "business methods."

I don't see changes to JAXB as being a huge issue, partly because Sun
are usually very careful about deprecating stuff, and partly because I
think we can do a lot to customize the way things are done using
binding-schema.

See http://java.sun.com/xml/jaxb/faq.html under "Do I have any control
over how the schema compiler generates the Java classes?"

And to the business-method point:
See http://java.sun.com/xml/jaxb/extendingJaxbGeneratedClasses.html at
the top under "How can I extend JAXB's generated implementation
classes?"

I can't say I've done either of the above, but I did feel happier
knowing that it can be done.

For me, I think I like 2 best and then 5b/d.

> Well, I'm certainly not an expert; however, that's never stopped me
> before. ;)  As far as I have seen, there is a large difference between,
> say, MIDP (built on CLDC) and Personal Profile (built on CDC).  MIDP is
> extremely limited in application size (e.g. <50K for an application's
> jar file), API richness, screen size, and language features (e.g. no
> finalizers, no floating point, no native methods).  On the other hand,
> the Personal Profile often uses a "real" JVM and has access to almost
> all of the JDK 1.1.8 APIs.  So perhaps we need:
> 
>     - JSword
>     - KSword
>         - base library using kSOAP
>         - MIDP UI (e.g. options, search screen, unformatted text
>           display, book browser, and that's about it)
>         - Personal Profile UI (e.g. rich-ish UI with formatted text
>           display)
> 
> We'd have to design the KSword API so that it could return formatted or
> unformatted text, I suppose.  Also, KSword may not be the best name,
> since it wouldn't necessarily be limited to the KVM; and the KDE folks
> might get upset. :)

Agreed.
When we start work on the "project formerly referred to by the codename
KSword" we should consider giving it a better name. ;-)

Joe.