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.
