abdera-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "joe kim" <joe....@gmail.com>
Subject Re: Atom Data Model and Testing
Date Fri, 30 Jun 2006 23:09:41 GMT

Thanks for the reply.  I will go ahead and keep testing out of this thread.

To summarize my argument, there should be a cleaner seperation between
the data model and parsing framework.  The data model can be
implemented as pure, dependency-free pojos and that does not have to
come at the cost of "fancy ways to add support for new extensions".

For example, to add support for "<garretts-cool-element>With stuff in
it</garretts-cool-element>", two things would need to occur: 1) Extend
the base, data model 2) Add parsing support

With pojo's extending the base, data model is pretty easy.

For adding parsing support the developer should have options: a) Use
their own custom parsing code b) code a custom extension to a built in
abdera parser

Option b) should not be mandatory.  For example, suppose I wanted to
use a jdom based parser.  The current code base makes it difficult to
do that.  In this scenario, I would be much happier going with option
a) and manipulating pojo's.

> > 1. Build a pojo module free of any dependencies to represent the Atom
> > data model
> >
> > Pojo's have a programming model with a very low cost to entry.  If the
> > data model was implemented as pojo's then there would be much less
> > added programming model complexity for tasks that focus in on data
> > manipulation.
> >
> > For example take a look at how an object is created.
> >
> > To create a feed you do:
> >
> > Feed feed = Factory.INSTANCE.newFeed();
> >
> > In the Factory class, INSTANCE is defined as:
> >
> > public static final Factory INSTANCE = ServiceUtil.newFactoryInstance();
> >
> > ServiceUtil creates the factory with:
> >
> >   public static Factory newFactoryInstance() {
> >     return (Factory) newInstance(
> >       ConfigProperties.getDefaultFactory());
> >   }
> >
> > ConfigProperties will then try to read from a configuration file or
> > return a default value.  But, apparently to use a different factory
> > you have to modify a file. Wouldn't it be much nicer if you could just
> > do this:
> >
> > Feed f = new Feed();
> Well, keep in mind that by default you can just do
> Factory.INSTANCE.newFeed(), sure, it's a little more writing, but it's
> also part of what gives us the fancy ways to add support for new
> extensions...
> Also, if you want to access the objects directly, you could skip over
> the interfaces and do something like:
> Feed f = new FOMFeed();

FOMFeed might be a good starting point to begin pojo-izing the code.
As it is written now, if I am using a totally different XML parser,
then it does not make sense for me to have to depend on axiom because
it is integrated with the data model for the sake of "optimization".

> > The difference between the two ways of instantiating an Object becomes
> > more apparent to the developer when he/she needs to make some changes.
> >  Let's look at extensions.  From the javadoc:
> >
> >  * There are four ways of supporting extension elements.
> >  *
> >  * 1. Implement your own Factory (hard)
> >  * 2. Subclass the default Axiom-based Factory (also somewhat difficult)
> >  * 3. Implement and register an ExtensionFactory (wonderfully simple)
> >  * 4. Use the Feed Object Model's dynamic support for extensions (also
> > very simple)
> >
> > Being mentally challenged as I am, I do not really understand what
> > that means.  My conclusion is that I would have to do some extra
> > reading to understand the options and that translates to overhead with
> > regard to my extension.  If all I wanted to do was add an extra field,
> > Java's core object oriented syntax suits me just fine.
> >
> > class PersonalFeed extends Feed {
> > private boolean markedAsRead = false;
> > public boolean isMarkedAsRead(){ return markedAsRead ; }
> > public void setMarkedAsRead(boolean m){ markedAsRead = m };
> > }
> The problem is that your code doesn't actually do what that comment
> talks about.  It's talking about adding support to the parser for
> parsing new and different types of content within an atom feed.  For
> example, if I wanted to add support for the
> <garretts-cool-element>With stuff in it</garretts-cool-element> I
> could use the kind of extensibility it's talking about to do so.  This
> is a bit more complex than a "marked as read" flag.

My code does part of what the comment is talking about.  It extends
the data model.  For the parsing portion, the extensibility provided
by the abdera code provides a lot of levels of indirection, but not I
do not see a compelling case supporting "flexibility".  To add jdom
support it looks like I have to create a whole new Factory, deemed
"hard" by James, or I have to use FOMFeed, a class that depends on


View raw message