Hi Paul!
Paul Fremantle wrote:
Firstly, I really like this proposal. I agree this makes it much cleaner.
:)
I have a question.
Would developers be "allowed" to create their own ResourceImpl
Resource r = new ResourceImpl();
or must they use the factory method:
Resource r = Registry.newResource();
Depends on which "developers" you're talking about. People building on
or modifying our JDBCRegistry internals would certainly be able to
directly use ResourceImpl - in fact they have to in many cases.
But people using the Registry from the outside should always be using
the factory, yes. Now that said, there's nothing *preventing* them from
getting at the ResourceImpl, but we wouldn't encourage that and in most
cases there'd be no real benefit. For example, even if you could set
the author name on a Resource before doing a registry.put(), the
registry implementation would still ignore it in favor of your actual
authenticated username on the Registry session.
Make sense?
Thanks,
--Glen
Glen Daniels wrote:
Hi folks!
So currently Resource is a very simple data object, with getters and
setters for pretty much everything... including, unfortunately, fields
that really should not be mutable by anyone except the inner workings
of Registry implementations. :( Simplifying this would be a) more
correct, and b) much less confusing for users confronted with a host
of methods that they can't really use.
I'd like to propose we do the following, in order to achieve a better
design as we move into wider usage.
* Refactor Resource into an interface:
interface Resource {
// These are all accessors, since setting these values
// only makes sense for the backend.
String getAuthorName();
String getLastUpdaterName();
Date getCreated();
Date getModified();
String getParentPath();
String getPath();
String [] getDependencies();
String [] getDependants();
// Content
Object getContent();
void setContent(Object content);
String getMediaType();
void setMediaType(String mediaType);
String getDescription();
void setDescription();
// Properties (these will change if we support
// multi-values)
String getProperty(String name);
void setProperty(String name, String value);
}
* I'd propose at the same time we do this we get rid of
"isDirectory()" and get back to the (IMO much better) design of
Collection extends Resource, which will allow us to implement
pagination as well as easier access to collection entries.... So
something like:
interface Collection extends Resource {
String [] getChildren(); // Get 'em all
String [] getChildren(int start, int pageSize); // Paged
}
* Provide the following methods in CoreRegistry:
/**
* Factory for Resources pre-initialized with correct date, author,
* etc.
*/
Resource newResource() throws RegistryException;
/**
* Make a collection at the given path, returning the actual
* path if successful.
*/
String createCollection(String path) throws RegistryException;
* So usage would look something like:
Resource resource = registry.newResource();
resource.setContent("hi there");
resource.setMediaType("text/plain");
resource.setDescription("A simple greeting");
registry.put("/helloWorld", resource);
* We'd then have "ResourceImpl implements Resource", and ResourceImpl
would have all the setters - that's what gets used by JDBCRegistry.
Thoughts?
--Glen
_______________________________________________
Registry-dev mailing list
[email protected]
http://wso2.org/cgi-bin/mailman/listinfo/registry-dev
_______________________________________________
Registry-dev mailing list
[email protected]
http://wso2.org/cgi-bin/mailman/listinfo/registry-dev
