[jsword-devel] BookDataListener: Question 1
Joe Walker
jsword-devel@crosswire.org
16 May 2003 18:55:44 +0100
Hi,
OK, then I'll work on swapping BookDataListener to JAXB. I've not had
much spare time this week with a funeral of a friend, and a holiday next
week. I hope to have some time this weekend - I'll keep you posted.
Joe.
On Fri, 2003-05-16 at 03:23, Jacky Cheung wrote:
> 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
> >
> >
> >
>
>
> _______________________________________________
> jsword-devel mailing list
> jsword-devel@crosswire.org
> http://www.crosswire.org/mailman/listinfo/jsword-devel