hi *!
following up on my earlier post.
currently, it seems that when new publications are created using the
"new publication" usecase (publication.createPublicationFromTemplate),
the new pub always uses the access control settings of the default
publication, regardless of the templates it is derived from.
solprovider explains:
> FILE: {pub}\config\ac\ac.xconf Contains absolute paths to the passwd
> directory. Since you just copied an entire publication, the absolute
> paths are pointing to the old publication's directory. This file
> must be manually updated if the publication id (directory) is changed
> from where the file was copied.
>
> IMO, this is silly. The paths should be relative so each publication
> uses its own security without requiring manually changing files.
> Publications sharing security settings should be the special case
> rather than the default.
i second this and suggest to change the behaviour of the
publication.createPublicationFromTemplate usecase as follows:
1. modify the new config/ac/ac.xconf so that it uses its own passwords
and policies. iiuc simply changing all occurences of "default/" to
"<my-pub>/" will do that - it worked when i tried it.
2. copy over all existing accounts from the template.
<mini-rant obnoxiousness="elevated">
i tried to have a go at this, but i got frightened by Instantiator.java
and went home sobbing. this makes me really really unhappy, so much
arcane java stuff for a simple copy-and-patch operation that could be
done in 2 lines of shell. (but maybe that's just my java skills sucking
bad...)
however, imnsho any development framework that forces its users to deal
with paths like
"lenya_1_4_X/src/webapp/lenya/pubs/default/java/src/org/apache/lenya/defaultpub/cms/publication/templating/Instantiator.java"
should get a day off and maybe start practising zen or something.
my fundamental gripe with lenya at this point is that i need to
understand (and be able to debug) too many different concepts in order
to be able to work with it: xsl, server-side javascript (!), java
classes in a servlet container, jsp, cocoon codepaths, lenya-specific
codepaths etc.)
instantiating instances of a template is a very basic feature that
should not require java hacking imho. don't get me wrong, i understand
that this feature is very new and the instantiator is just a q&d demo
implementation, but oh would i love to be able to use templating rsn.
</mini-rant>
for a more productive elaboration on this topic, see my other post "RFC:
suggestions for a ConfigurableInstantiator" :)
again i wonder whether a more simple interim solution for
java-challenged people like me might be to use "fallback:///config/ac/"
throughout config/ac/ac.xconf, but andreas said in an earlier posting:
> IMO that would add confusion. Maybe the instantiator should change
> this path when a publication is created.
andreas, can you elaborate? to me it looks quite appealing (no java
involved :), and it seems to lead to the behaviour that solprovider and
me are looking for. i tried it, and it seems to work ok.
best,
jörn
--
"Án nýrra verka, án nútimans, hættir fortíðin að vekja áhuga."
"Without new works, without the present the past will cease to be of
interest."
- Ásmundur Sveinsson (1893-1982)
--
Jörn Nettingsmeier, EDV-Administrator
Institut für Politikwissenschaft
Universität Duisburg-Essen, Standort Duisburg
Mail: [EMAIL PROTECTED], Telefon: 0203/379-2736
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
