On 6/30/06, joe kim <[EMAIL PROTECTED]> 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
