abdera-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James M Snell <jasn...@gmail.com>
Subject Re: Atom Data Model and Testing
Date Fri, 30 Jun 2006 22:38:37 GMT


joe kim wrote:
> Hey Guys,
> 
> I've been spending some time getting situated with Abdera.  I have a
> two thoughts that I would be willing to drive implementation on.  I am
> still getting started, so feel free to provide feedback or redirect
> me.  I am still an atom novice compared to you guys.
> 
> 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:
> 
> http://ptrthomas.wordpress.com/2006/06/06/java-call-stack-from-http-upto-jdbc-as-a-picture/
> 
> 
> 1. Build a pojo module free of any dependencies to represent the Atom
> data model
> 

-1. The current interface+impl mechanism provides a great deal of
flexibility in the implementation and gives us built-in serialization to
and from XML using Axiom that is very high performance and efficient.

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

You can also do:

  Feed feed = new FOMFeed();


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

The ConfigProperties is only used to register the default
factory/parser/etc implementation.  If you want to use alternative
implementations, you could use

Factory factory = new MyFactory();

Or, you could also...

Factory factory = new FOMFactory();

The current configuration model is in place to allow for alternative
default implementations of the object model.  For example, we currently
have at least one project going on internally that is working on
replacing the Axiom-based implementation with an SDO based
implementation, using the exact same set of interfaces.

> Feed f = new Feed();
> 
> 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 };
> }
> 

We can already do this.

class MyFeed extends FOMFeed {
  ...
}

> I would really like to see a pojo module that represents the Atom model.
> 

I don't see this as buying us anything relative to what we already have
and would likely degrade the performance advantages of the Axiom-based
impl we already have in place.

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

-0.5. JUnit has much broader support and, so far, has done everything
we've needed it to do.  Unless there is something that TestNG offers
that we absolutely need and cannot get with JUnit, I don't see the
advantage.

> Any thoughts?
> 
> Cheers,
> Joe
> 

- James

Mime
View raw message