abdera-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Garrett Rooney" <roo...@electricjellyfish.net>
Subject Re: Atom Data Model and Testing
Date Fri, 30 Jun 2006 22:13:34 GMT
On 6/30/06, joe kim <joe.kim@gmail.com> wrote:

> In general, I feel like Abdera could be simplified.  Java frameworks
> are becoming extreme in terms of providing levels of indirection.  You
> guys may have seen this call stack:

No argument there, simplification is great.

> 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(
>       CONFIG_FACTORY,
>       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();

> 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.

> I would really like to see a pojo module that represents the Atom model.
>
> 2. Use TestNG as a testing framework.
>
> I did some research on Java testing frameworks and it looks like
> TestNG is the most capable of JUnit 3.8, JUnit 4, and TestNG.  It will
> allow us to continue using JUnit 3.8 test cases and provides a much
> more flexible test configuration.  I think org.apache.examples.simple
> would be a good starting place for creating test cases.

The choice of test framework seems like a totally different discussion
than the beginning of your email.  Perhaps you should break it out
into a separate mail.  Personally though, I would want to see some
concrete examples of why a different framework would be better than
what we've got now.  JUnit is well known, and has support from many
other tools.

-garrett

Mime
View raw message