abdera-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Garrett Rooney" <roo...@electricjellyfish.net>
Subject Problems decoupling extensions from parser back end
Date Mon, 09 Oct 2006 01:36:56 GMT
So, on the flight out to ApacheCon I finally got a chance to hack on
my "stop requiring extensions to be intimately familiar with the
parser back end" project.  I played around enough to flesh out my
ideas for how to make that work, but I ended up running into a brick
wall, and I'm curious if others have any ideas for how to go forward
from here.

So, my plan was to make Factory.newExtensionElement actually take an
Element object representing the current element as one of its
arguments.  The ExtensionFactory implementations would be responsible
for taking this Element and returning a new one of the proper type,
most likely by returning a wrapper class that forwards through to the
underlying Element for all but the extension specific functionality.
i.e. my OpenSearch ItemsPerPage implementation would look like this:

public class ItemsPerPageImpl
  extends WrapperElement
  implements ItemsPerPage {

  private static final long serialVersionUID = 4343427206133794002L;

  public ItemsPerPageImpl(Element wrapped)
  {
    super(wrapped);
  }

  public int getCount()
  {
    return Integer.parseInt(getText());
  }

  public void setCount(int count)
  {
    setText(String.valueOf(count));
  }
}

If you wanted to provide a constructor that gives back an empty
ItemsPerPage that someone could use to construct a feed you'd just
provide a constructor or helper method that takes a Factory object as
an argument.  Actually, it really should have that, it's just that I
never implemented that side of things for the OpenSearch extensions.
Also, assume a WrapperElement class that just implements all methods
as forwarding to another element object.

So, what's the problem with this?  Well, the issue is that the current
parser back end REALLY wants all Elements that it messes with to
extend from OMElement, like FOMElement does, and in
FOMFactory.createElement we die with a ClassCastException when we try
to cast from the return value of newExtensionElement to an OMElement,
because the element we get back extends from WrapperElement not
OMElement.

So to make this work, we need to make the FOM* stuff not assume that
all Element objects are OMElements.  I started working on pushing that
change through, but got frustrated at all the places that seem to make
that assumption.  Obviously, as long as those assumptions remain each
extension is going to have to have some intimate knowledge of the
underlying parser, or it won't be able to return the appropriate type
of objects.

My question is, is there any other solution I'm missing?  Is it
reasonable to expect our parser internals to just speak in terms of
Elements?  Should I head down that road first, before making the
actual extension changes?  If not, shouldn't we be asking why our code
needs to know more about the underlying objects but our consumers
shouldn't?  If we find that functionality useful, wouldn't other
people?  Just thinking out loud at this point, I really don't know
enough about the parser implementation to know if I'm even on the
right track here.

Thoughts?

-garrett

Mime
View raw message