Re: [jira] Commented: (JCR-165) add ability to ignore specific node types when generating webdav directory listing

[Angela Schreiber <an...@day.com>]

> one final comment is that using the existing dirlisting command, even 
> with all of these changes, is just a stepping stone for me. eventually 
> i'm going to make an export command that will place the parent node and 
> its child nodes in request attributes and then forward the request to 
> another uri - in this case a jsp which generates html that matches the 
> rest of my server's ui.
> 
> of course this means i'll have to extend the export context to carry the 
> servlet request and response, which is something tobias avoided in his 
> initial implementation, but i think there's a compelling reason to do it.

perhaps a compelling reason not to use the command-chains in
that particular case? ;)

regards
angela

Re: [jira] Commented: (JCR-165) add ability to ignore specific node types when generating webdav directory listing

[Brian Moseley <bc...@osafoundation.org>]

Tobias Strasser wrote:

> what i like of the chain approach is the easy configurability. but it
> needs a very good understanding what the respective commands do, and
> they have to work properly together. maybe we have to define some
> proper constraints and invariants for the commands; without having
> access to the sourcecode or a very good documentation, you will
> probably not be able to configure proper chains.

can you imagine a situation in which one would want to 
configure an import or export chain without being able to 
look at the sourc code?

i think tweaking the default import/export behavior is an 
advanced activity that relatively few people will want to 
do, and those who try will almost certainly be developers 
who will understand how to read source code and 
developer-level docs.

i do think that documenting how the chains work and what the 
default commands and configuration do would be valuable, but 
i was able to figure it out with a relatively quick 
inspection of the source code, so i don't see it as a 
pressing concern.

> i also stumbled over a (what i think is) design flaw of the chains,
> that they 'store' the catalog in class-static fields. this makes it
> for example in a j2ee impossible to hold different catalogs (with the
> same name) in the same webapp (or worse, in the entire server, if you
> place the commons-chain.jar in the wrong place). correct me if i'm
> wrong here. as next step, i would also try to use the catalogs more
> strictly, and not via class-loader magic.

in a j2ee context you could store the catalog in jndi or in 
a servlet context attribute. you could load the catalog 
during servlet initialization or with a servlet context 
listener.

you could also write container-specific components to make 
the chain available as a jndi resource, although that seems 
like overkill in a couple of different ways.

> the idea here was, that the export/import chains could also be used in
> a non-j2ee environment, where request/response are not available.

sure, but when you are guaranteed to be in a j2ee 
environment, such as when a servlet sets up the chains, it 
could provide them with servlet-aware contexts.

perhaps you could retain the existing import and export 
context classes, and then create j2ee-aware subclasses with 
access to the request, response, and servlet, and have the 
webdav servlet give those to the chains.

this would give me the flexibility i need for generating a 
custom directory listing but also make the chains available 
for use in non-j2ee environments.

if you like this approach, i can send you a patch. it's 
basically the strategy i was going to follow on my own anyway :)

> we can do that. no problem.

great. i think that's the appropriate design approach for 
pretty much all of the jcr-server classes. i find that 
implementing my webdav protocol extensions calls for 
overriding the jcr-server classes in many different places, 
and right now i'm maintaining an extensive set of small 
patches that add accessor methods to jcr-server classes 
and/or make private methods protected or public.

Re: [jira] Commented: (JCR-165) add ability to ignore specific node types when generating webdav directory listing

[Tobias Strasser <to...@gmail.com>]

> > perhaps a compelling reason not to use the command-chains in
> > that particular case? ;)
> 
> what's the alternative - major surgery on DavResourceImpl?
> 
> nah, i like the chain approach. hey i suggested it, right? :)
what i like of the chain approach is the easy configurability. but it
needs a very good understanding what the respective commands do, and
they have to work properly together. maybe we have to define some
proper constraints and invariants for the commands; without having
access to the sourcecode or a very good documentation, you will
probably not be able to configure proper chains.
i also stumbled over a (what i think is) design flaw of the chains,
that they 'store' the catalog in class-static fields. this makes it
for example in a j2ee impossible to hold different catalogs (with the
same name) in the same webapp (or worse, in the entire server, if you
place the commons-chain.jar in the wrong place). correct me if i'm
wrong here. as next step, i would also try to use the catalogs more
strictly, and not via class-loader magic.

> if y'all are really dead set on not having contexts that
> include the request and the response (i'm not sure why you
> would be),
the idea here was, that the export/import chains could also be used in
a non-j2ee environment, where request/response are not available.

> then maybe you can move the instantiation of each
> chain into a protected method that a subclass can override?
we can do that. no problem.

cheers, tobi
-- 
------------------------------------------< tobias.strasser@day.com >---
Tobias Strasser, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
T +41 61 226 98 98, F +41 61 226 98 97 
-----------------------------------------------< http://www.day.com >---

Re: [jira] Commented: (JCR-165) add ability to ignore specific node types when generating webdav directory listing

[Brian Moseley <bc...@osafoundation.org>]

Angela Schreiber wrote:

> perhaps a compelling reason not to use the command-chains in
> that particular case? ;)

what's the alternative - major surgery on DavResourceImpl?

nah, i like the chain approach. hey i suggested it, right? :)

if y'all are really dead set on not having contexts that 
include the request and the response (i'm not sure why you 
would be), then maybe you can move the instantiation of each 
chain into a protected method that a subclass can override?