Am Mi, den 14.04.2004 schrieb Guido Casper um 9:08:
Stephan Michels wrote:
The Repository IFs seems be more helper classes than components. And I think we should using the Source objects instead to reflect all aspects like locking, property handling etc.
Care to elaborate why do you think so?
Okay, I try to. For example methods like boolean saveContent(String uri, String content)
shouldn't belong into the interface of a repository. They can easly move
into SourceUtil.
Another point is that you have to specify your repository base path into
cocoon.xconf for the WebDAV. And when you change this, which intention
has the "uri"? Doesn't have you all this with the resolver?
I think a "closed" application shouldn't bother with absolute URIs or where to find the repository root. It may be a matter of taste but if you want to encapsulate that information somewhere the RepositoryImpl certainly is the best place to do so.
If you use flowscript you have to lookup the repository manager IF:
var repositorymanager =
cocoon.getComponent('org.apache.cocoon.components.repository.RepositoryManager');
And not until you login you can lookup the repository
Of cource, if you want authenticated access only. You are free to allow anonymous access though.
userid = cocoon.request.getParameter("userid");
repository = repositorymanager.getRepository("webdav", new CredentialsToken(new Principal(userid, "guest", null), password));
versioninghelper = repository.getVersioningHelper();
And you have a different behaviour if you use the SourceResolver and the Repository IF together.
var source = resolver.resolveURI("webdav://localhost:8888/webdav"+path); repository.save(path, "bla");
Hmm, yes the idea is to don't use the SourceResolver within flow and use Sources only through the sitemap.
I don't want to say that's all crap. I only want to express my concerns, so, please don't get me wrong.
Don't worry, I'm really interested in your opinion.
My question was more about why you think the Source interfaces are best suited for ALL resource access, which is the point I disagree with as it easily leads to mixed concerns.
I found the partition of work - reading operations via Sources (which BTW is their original intention) and modifying operation via Repository - quite useful.
I doesn't think that we should delegate similar aspects into different code parts.
Hmm, if you think MVC then the view layer is quite a different aspect from the controller.
My take is that Sources are designed to be used with the view layer and need to be squeezed to account for the controller (and all the different concerns) as well.
It may be debatable to have different access paths to the model (although with XML this becomes less of a concern IMO). But Sources justify their existance mainly through the flexibility and ease of use they provide for the sitemap and the view layer.
Guido
However I use flowscript (which I suspect you don't like :-) for that.
No, I like flowscript, but prefer Java. But nevertheless I currently write a flowscript application, and I found that it is very cumbersome to access the different aspects of an WebDAV repository.
Stephan.
--
Guido Casper
-------------------------------------------------
S&N AG, Competence Center Open Source
Tel.: +49-5251-1581-87
Klingenderstr. 5 mailto:[EMAIL PROTECTED]
D-33100 Paderborn http://www.s-und-n.de
-------------------------------------------------
