Extension Development

[Rob Evans <ob...@gmail.com>]

I have a large'ish information model that I'd like to expose via a feed. I
started looking at the OpenSearch extension to learn how to structure an
extension and I have a simple extension and factory working. My information
model has already been described in xml schema and I'm wondering if there is
a way to use leverage that schema. For example, could I use apache ADB to
generate the classes? It looks like my generated classes would need to
implement org.apache.abdera.model.Element in order for them to be added as
Extensions.

Is there a simpler approach?

Thanks

Re: Extension Development

[Rob Evans <ob...@gmail.com>]

On 9/6/06, James M Snell <ja...@gmail.com> wrote:
> I made a change in the trunk today that would allow you to do stuff like...
>
> QName FOO = ...
> QName BAR = ...
> QName BAZ = ...
> ExtensibleElement foo = (ExtensibleElement)factory.newElement(FOO);
> foo.addExtension(BAR);
> foo.addExtension(BAZ);
>
> Grab the trunk to test it out.
[snip]

I grabbed the trunk, performed a build, wrote some unit tests and it
satisfies my needs.

Cheers

Re: Extension Development

[James M Snell <ja...@gmail.com>]

I made a change in the trunk today that would allow you to do stuff like...

QName FOO = ...
QName BAR = ...
QName BAZ = ...
ExtensibleElement foo = (ExtensibleElement)factory.newElement(FOO);
foo.addExtension(BAR);
foo.addExtension(BAZ);

Grab the trunk to test it out.

- James

Rob Evans wrote:
> Thanks, James.
> 
> I'll give this a shot; however, it's not immediately clear to me how Iame
> would nest elements to get something like:
> 
>  <sc:foo>
>     <sc:bar/>
>     <sc:baz/>
>  </sc:foo>
> 
> Chances are good that I just need to write some test code to learn how
> this works. ;-)
> 
> On 9/6/06, James M Snell <ja...@gmail.com> wrote:
>> One way of implementing extensions that do not rely on the underlying
>> parser implementation would be to implement wrappers around the Feed
>> Object Model interfaces.  For instance,
>>
>>   Document<Feed> doc = ...
>>   Feed feed = doc.getRoot();
>>   QName myExtensionQName = new QName("urn:foo:bar", "Test");
>>   Element test_el = feed.getExtension(myExtensionQName);
>>   Test test = new TestImpl(test_el);
>>   test.getFoo();
>>   test.getBar();
> [snip]
> 

Re: Extension Development

[Rob Evans <ob...@gmail.com>]

Thanks, James.

I'll give this a shot; however, it's not immediately clear to me how I
would nest elements to get something like:

  <sc:foo>
     <sc:bar/>
     <sc:baz/>
  </sc:foo>

Chances are good that I just need to write some test code to learn how
this works. ;-)

On 9/6/06, James M Snell <ja...@gmail.com> wrote:
> One way of implementing extensions that do not rely on the underlying
> parser implementation would be to implement wrappers around the Feed
> Object Model interfaces.  For instance,
>
>   Document<Feed> doc = ...
>   Feed feed = doc.getRoot();
>   QName myExtensionQName = new QName("urn:foo:bar", "Test");
>   Element test_el = feed.getExtension(myExtensionQName);
>   Test test = new TestImpl(test_el);
>   test.getFoo();
>   test.getBar();
[snip]

Re: Extension Development

[James M Snell <ja...@gmail.com>]

One way of implementing extensions that do not rely on the underlying
parser implementation would be to implement wrappers around the Feed
Object Model interfaces.  For instance,

  Document<Feed> doc = ...
  Feed feed = doc.getRoot();
  QName myExtensionQName = new QName("urn:foo:bar", "Test");
  Element test_el = feed.getExtension(myExtensionQName);
  Test test = new TestImpl(test_el);
  test.getFoo();
  test.getBar();

With this approach, you could use some form of XSD-to-Java  skeleton
generator to define the API of your wrapper interfaces then fill in the
implementation by delegating to the FOM object.

- James

Garrett Rooney wrote:
> On 9/1/06, Rob Evans <ob...@gmail.com> wrote:
>> I have a large'ish information model that I'd like to expose via a
>> feed. I
>> started looking at the OpenSearch extension to learn how to structure an
>> extension and I have a simple extension and factory working. My
>> information
>> model has already been described in xml schema and I'm wondering if
>> there is
>> a way to use leverage that schema. For example, could I use apache ADB to
>> generate the classes? It looks like my generated classes would need to
>> implement org.apache.abdera.model.Element in order for them to be
>> added as
>> Extensions.
>>
>> Is there a simpler approach?
> 
> It's actually worse than that.  Not only do your classes have to
> implement Element, but these days they also have to be intimately
> familiar with the parser implementation.  If you look at the
> implementations of the OpenSearch classes, you'll see that they
> reference FOM classes.
> 
> I'd really like to make that go away.  It would be awfully nice if the
> extensions didn't have to know anything at all about the parser,
> perhaps the parser would just hand off an Element object to the
> extension factory, and it would be responsible for converting that
> element into the particular type of element it cares to generate.
> 
> Anyway, that's the state of the union at this point.  No there's no
> "easy" way to automatically generate extensions, and when you do
> generate them they need to have a lot of knowledge about the parser
> they work with, although that may change in the future.
> 
> -garrett
> 

Re: Extension Development

[Garrett Rooney <ro...@electricjellyfish.net>]

On 9/1/06, Rob Evans <ob...@gmail.com> wrote:
> I have a large'ish information model that I'd like to expose via a feed. I
> started looking at the OpenSearch extension to learn how to structure an
> extension and I have a simple extension and factory working. My information
> model has already been described in xml schema and I'm wondering if there is
> a way to use leverage that schema. For example, could I use apache ADB to
> generate the classes? It looks like my generated classes would need to
> implement org.apache.abdera.model.Element in order for them to be added as
> Extensions.
>
> Is there a simpler approach?

It's actually worse than that.  Not only do your classes have to
implement Element, but these days they also have to be intimately
familiar with the parser implementation.  If you look at the
implementations of the OpenSearch classes, you'll see that they
reference FOM classes.

I'd really like to make that go away.  It would be awfully nice if the
extensions didn't have to know anything at all about the parser,
perhaps the parser would just hand off an Element object to the
extension factory, and it would be responsible for converting that
element into the particular type of element it cares to generate.

Anyway, that's the state of the union at this point.  No there's no
"easy" way to automatically generate extensions, and when you do
generate them they need to have a lot of knowledge about the parser
they work with, although that may change in the future.

-garrett

Re: Extension Development

[James M Snell <ja...@gmail.com>]

There are ways of supporting this that do not require implementing
extensions.  Abdera's dynamic extension support makes it possible to get
to the complete infoset of XML content without implementing an Extension
Factory and without having to deal with the specific parser
implementation.  That approach, however, does have it's own issues.  As
Garrett indicated in his note, however, it would be nice if we could
make extension development even easier.

- James

Rob Evans wrote:
> I have a large'ish information model that I'd like to expose via a feed. I
> started looking at the OpenSearch extension to learn how to structure an
> extension and I have a simple extension and factory working. My information
> model has already been described in xml schema and I'm wondering if
> there is
> a way to use leverage that schema. For example, could I use apache ADB to
> generate the classes? It looks like my generated classes would need to
> implement org.apache.abdera.model.Element in order for them to be added as
> Extensions.
> 
> Is there a simpler approach?
> 
> Thanks
>