abdera-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Diephouse <dan.diepho...@mulesource.com>
Subject Re: Simplifying Server Side Development
Date Mon, 24 Sep 2007 18:46:27 GMT
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?
>>>
>
>


-- 
Dan Diephouse
MuleSource
http://mulesource.com | http://netzooid.com/blog


Mime
View raw message