Mailing-List: contact abdera-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: abdera-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of david.calavera@gmail.com
 designates 209.85.198.189 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
        b=qdn5a72rH7VIeaGkcCOR2wRhndx+nimBpywgR52TdHrWgfEjBsQ+P9fODKVLG979CJENAxNrZ5a4HFn4GWHl1x3JHraQiC/hkSvxByIbVdcQPfFS2mPM6i0LiMt+ubBAXTYWyY/OPBoNT3UQNFssjnQe9kpggSOoAAak2vxo7AI=
Message-ID: <baf7e05c0707310304p3110d7e2y19d0e9e95d07eca1@mail.gmail.com>
Date: Tue, 31 Jul 2007 12:04:04 +0200
From: "David Calavera" <david.calavera@gmail.com>
To: abdera-dev@incubator.apache.org
Subject: Re: Annotations
In-Reply-To: <46AE6E4A.1050907@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_44242_20343732.1185876244598"
References: <46AE4F43.3050608@gmail.com>
	 <29a761a00707301456t1ccfb117xa98aee9c48e02e8@mail.gmail.com>
	 <46AE6E4A.1050907@gmail.com>

------=_Part_44242_20343732.1185876244598
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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 <jasnell@gmail.com> 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 <jasnell@gmail.com> 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

------=_Part_44242_20343732.1185876244598--