Hi, i started to use abdera to build an api few weeks ago and i was thinking
on this mechanism too. It could be useful converter could be introspection
on objects in the Foo with another annotation. Extending the foo example:
@AtomEntry
public class Foo{
...
@AtomMoreData //for example
public Object getBar() {
return bar;
}
}
public class Bar {
@AtomContent(type=Content.Type.XHTML)
public String getContent() {
return content;
}
}
I think it could be useful for people that use ORM. What do you think about
it?
Best regards
On 7/31/07, James M Snell <[EMAIL PROTECTED]> wrote:
>
> We could easily do something like...
>
> @AtomEntry
> @AtomConverter(impl="com.example.foo.MyConverter")
> public class Foo { ... }
>
> Under the covers, this would lead to a call like:
>
> Converter<Entry> converter = new MyConverter()
> Entry entry = converter.convert(foo);
>
> Where the converter is defined as:
>
> public class MyConverter implements Converter<Entry>{
> public static Entry convert(Object annotatedObject) {
> ...
> }
> }
>
> public interface Converter<T extends Base> {
> T convert(Object annotatedObject);
> }
>
> Anyway, yeah, it's definitely possible.
>
> - James
>
> Brian Moseley wrote:
> > On 7/30/07, James M Snell <[EMAIL PROTECTED]> wrote:
> >
> >> The main question I have is whether or not this would be useful enough
> >> to go through the trouble of implementing it. Thoughts?
> >
> > i can certainly imagine this mechanism being useful.
> >
> > you'd need to account for the fact that sometimes (often?) the
> > conversion of a bean to an entry requires calculation of element
> > values in collaboration with objects that aren't directly associated
> > with the bean itself. for instance, imagine a converter that uses a
> > ResourceLocator to serialize a bean into an entry with IRIs calculated
> > based on the state of the ResourceLocator. one way to handle this
> > would be to let converters be pluggable.
> >
>
--
David Calavera
http://www.thinkincode.net