abdera-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James M Snell <jasn...@gmail.com>
Subject Re: Simplifying Server Side Development
Date Tue, 25 Sep 2007 22:08:53 GMT
Dan, I've just finished going through this.  It looks very good to me.
If none of the other comitters object, I'll go ahead and check it in.

- James

Dan Diephouse wrote:
> Anyone had a chance to look at this at all? I updated the patch a while
> back to make it a lot more cleaner/extensible/dynamic..
> 
> - Dan
> 
> Dan Diephouse wrote:
>> I'm thinking about a couple changes which would improve this mechanism
>> a bit. First, I think the whole ContentInfo thing should go and it
>> should just use the Content object instead.
>>
>> Second, I think instead of making ContentProvider so high level, it
>> could be modeled after the Provider interface a bit more. This
>> ContentProvider would continue to handle the work of manging the
>> Collection, but it would provide access to the
>> Request/ResponseContext. There could then be an
>> AbstractSimpleContentProvider which looks like ContentProvider does
>> now. This would allow more low level access to the Entry/Feed/etc when
>> needed.
>>
>> This would mean there would be essentially 3 levels:
>> 1. Provider - manages the whole APP service
>> 2. ContentProvider (maybe better called CollectionProvider?) &
>> WorkspaceInfo: These provide metadata about the workspace and back the
>> collcetions
>> 3. AbstractSimpleContentProvider - provides simple APIs like "T
>> getEntry(String id)" which users could override.
>>
>> Regards,
>>
>> - Dan
>>
>> James M Snell wrote:
>>> Dan, very cool to see you thinking through this stuff. Give me a couple
>>> of days to stew on it and I'll post some thoughts next week.
>>>
>>> - James
>>>
>>> Dan Diephouse wrote:
>>>> Hi All,
>>>>
>>>> I think there is some agreement that server side development needs
>>>> to be
>>>> made a bit easier. This last week I've been hacking on a way to make it
>>>> as easy as possible, yet still be fairly extensible. I think its a
>>>> rather naive first attempt and I don't know if I've succeeded at
>>>> all, so
>>>> I was hoping to get some feedback.
>>>>
>>>> The basic idea is that you write against the ContentProvider interface
>>>> and "fill in the blanks". I.e.
>>>>
>>>> BlogProvider extends ContentProvider<BlogEntry> {
>>>>   public String getTitle(BlogEntry b) {
>>>>     return b.getName();
>>>>   }
>>>> ....
>>>> }
>>>>
>>>> It is FAR from done. For instance:
>>>> 1. No exception handling of any kind - i.e. no way to throw a 404
>>>> 2. Doesn't provide ways to map things like categories or other metdata
>>>> on the entry.
>>>> 3. Resolver/Provider URL handling needs to come together somehow
>>>> (per my
>>>> previous thread)
>>>> 4. I have no idea if this is even conformant to the atompub spec, I'm
>>>> really just making this up as I go along - so it could seriously suck.
>>>> How IDs are supposed to work is particularly fuzzy. (I know I have to
>>>> read that part of the Atompub spec soon, but I wanted to get this out
>>>> here for feedback)
>>>> 5. The example/test is a very naive attempt to figure out what it would
>>>> be like to expose a customer database over AtomPub.
>>>> 6. Not sure I like how the classes are named
>>>> 7. Apache license headers aren't in tack, figure it needs more work
>>>> anyway before committing
>>>>
>>>> Code is here:
>>>>
>>>> https://issues.apache.org/jira/browse/ABDERA-63
>>>>
>>>> Cheers,
>>>> - Dan
>>>>
>>>> PS I'm gathering that the conversion stuff James recently committed may
>>>> play along with the whole idea of simplifying things a bit for server
>>>> side developers. James: any chance you can give us a run down of the
>>>> ideas behind it?
>>>>
>>
>>
> 
> 

Mime
View raw message