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: Feedback round 2 [was Re: Server Refactoring - Overview]
Date Wed, 23 Jan 2008 19:03:16 GMT
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 
* 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.
- 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.

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

View raw message