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: Feedback round 2 [was Re: Server Refactoring - Overview]
Date Wed, 23 Jan 2008 19:52:59 GMT
Sweet. I'm checking out the complete branch now and will go through it. 
   A bit later today I will add in the Filter stuff.

Before we cut over to this in the trunk, I'd like to take a stab at 
writing up some docs and post a note on the user list to solicit 
feedback on the revised design.

- James

Dan Diephouse wrote:
> OK I'm done for the moment I think. Some outstanding issues/comments:
> 
> * I think things are simplified even more. I removed even more stuff 
> from interfaces and went with a convention over configuration type 
> approach for Providers. You only have to supply the bare minimum amount 
> of information to get a Provider/CollectionAdapter set up now. This can 
> easily be overridden though. Any use case that was supported previously 
> should be supported now.
> * BasicAdapter stuff needs a once over for my changes. James - any 
> chance you can take a look at this? I'm pretty much out of Abdera time 
> for the day. I kind of think BasicAdapter needs a once over anyway.
> * The biggest thing that is still ugly is the resolution. I think the 
> API is fine, but the default implementation may be a little big ugly yet 
> (but it works! :-))
> * If you notice inside the StructuredResolver I do a MimeType check to 
> support POSTing of media collections. If you use the RegexTargetResolver 
> it is currently impossible to do media posts to the same URL as non 
> media entries.
> * I have the JCR test working locally as well, but I need to rebranch 
> the build to include all modules.
> * Do we really need getProperty/getPropertyNames on Provider?
> 
> Some more general coding suggestions:
> * For tests like SimpleTest where we're starting/stopping servers we 
> should use the @BeforeClass/@AfterClass annotations to set up and tear 
> down the server.
> * I noticed a lot of the tests have the assertFoo(...) arguments 
> reversed. The thing you want the assertion to match should be the first 
> argument.
> * The "test" package in the server module is a little redundant.
> * If we refactor in the future we should make sure to do it over the 
> whole build. For instance, it would've been nice if we did a global 
> method rename for createEntry on CollectionProvider to 
> CollectionAdapter.postEntry as it would've saved a bit time. :-)
> 
> Let me know your thoughts.
> Cheers,
> - Dan
> 
> James M Snell wrote:
>> Dan, let me know when you're done with the branch. I've implemented 
>> support for a Filter mechanism that is modeled after the Servlet 
>> Filter design.  It allows a Provider to insert a chain of filters that 
>> are invoked by the AbderaServlet prior to invoking the Provider.  The 
>> initial example I have is an OpenSearchFilter that is capable of 
>> serving up an OpenSearchDescription document and maps Target 
>> parameters to standard OpenSearch query parameters in the RequestContext.
> 
> 

Mime
View raw message