[jsword-devel] BookDataListener: Question 1

[Jacky Cheung]

Hi,

I think we have to make a deadline and decide which approach we will 
adopt. I am working on <WH>, etc support on GBF and pending to wait for 
this decision (existing BookDataListener does not work for these tags).

Jacky

Joe Walker wrote:

>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.
>
>
>
>
>
>_______________________________________________
>jsword-devel mailing list
>jsword-devel@crosswire.org
>http://www.crosswire.org/mailman/listinfo/jsword-devel
>
>  
>