Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Lenya Wiki" for change 
notification.

The following page has been changed by JörnNettingsmeier:
http://wiki.apache.org/lenya/RandomThingsLearnedWhilePlayingWith1%2e4HEAD

------------------------------------------------------------------------------
  This is another brain-dump area while I'm learning my way around Lenya 
1.4-HEAD. --JörnNettingsmeier
  
  ''All paths mentioned below are relative to the pubs dir 
(build/lenya/webapps/lenya/pubs).''
+ 
  
  == New Publication Wizard / Publication templating ==
  
  I'm trying to set up two publications that follow a common corporate design. 
The idea is to use 
[http://lenya.apache.org/1_4/reference/publication-templating/index.html 
publication templating], so that changes to the design will automatically be 
propagated to the derived publications. This does not work very well for me atm 
- I need to understand which settings and files are hard-copied once during 
creation and which are referenced. I'm dumping my findings here as I go along.
  
+ Important note (quoting AndreasHartmann): 
+  ''The default publication's instantiator [i.e. the "New publication Wizard] 
is just an example how it could be done, it is not thoroughly designed and 
tested. You can fine-tune your own instantiator just as you please.''
+ 
+ Ok. This means I have raised my status from RTFM to WTFC :-D Unfortunately, 
my Java skills are nil for very small values of nil... Let's see.
+ 
  === Observations ===
+ 
+ The grunt work of creating a new publication is done by 
lenya_1_4_X/src/webapp/lenya/pubs/default/java/src/org/apache/lenya/defaultpub/cms/publication/templating/Instantiator.java.
 You should browse this file only if you are mentally and emotionally stable ;)
  
  ==== Access Control: ====
  
-  * <newpub>/config/ac/ac.xconf uses 
"context:///lenya/pubs/default/config/ac/passwd" etc. *But*: it always uses the 
"default" publication, not the actual template that is used.
+  * <newpub>/config/ac/ac.xconf uses 
"context:///lenya/pubs/default/config/ac/passwd" etc. *But*: it always uses the 
"default" publication, not the actual template that is used. This can be 
corrected by using "fallback:///confic/ac/..." throughout /config/ac/ac.xconf.
-  ''Bug or feature? Should this also use "fallback:///"?''
- 
-  * The contents of the passwd/ and policy/ dirs are copied into <newpub>, 
probably also from the default publication. 
+  * The contents of the passwd/ and policy/ dirs are copied into <newpub> from 
the default publication. 
+  * Changes to config/ac/ settings require lenya to be restarted in order to 
become active.
-   ''Why? Either the whole mechanism should fall back to the default 
publication (including all users/groups/hosts etc.), or it is independent. Can 
anyone explain?''
- 
-  * When I create a new user in the template publication, log out and into a 
derived publication, the user is there as well. Ok. But there is no entry in 
<derived publication>/config/ac/passwd.
-   ''Why? Either the entire passwd dir is not used, in which case it should 
not be created in the first place, or it should reflect the current state of 
the things.''
- 
-  * When I create a new user in a derived publication, the user is also 
visible in the template publication. So there is a common ac repository.
-   ''Ok, it seems that all users go to the config/ac/passwd of the default 
publication. This is consistent with the first observation above.''
  
  ==== Configuration: ====
  
-  * publication.xml is copied from the template, and the publication name is 
changed.
+  * publication.xml is copied from the template, and the publication name is 
changed. This seems to be accomplished by weird tricks with the document tree 
within the Instantiator class.
  
  ==== Content: ====
+ 
   * content/*/* is copied from the template without changes.
+  * When the user creates new pages of a certain resource type, s/he will see 
sample pages which are read from ../modules/<doctype>/samples/<doctype>.xml.
+   ''How can these be overridden in individual publications? Why are there 
sometimes multiple files (such as xhtml-2col.xml and xhtml.xml)? How are 
resource types defined globally?''
- 
-  * When creating a new xhtml page, I see the standard "Default Publication - 
Welcome to the default Lenya publication! The purpose of this publication 
is..." page. 
-   ''How can I edit this? It should be an example page from the publication 
template.''
- 
-  * When I create a "links" type page, I see the standard "links" example 
page. 
-   ''Again, how do I edit this? I want it to show an example page for the 
proper resource type from the template.''
- 
   * As mentioned in 
[http://lenya.apache.org/1_4/reference/publication-templating/index.html], 
templates are defined in <newpub>/config/publication.xconf. 
    ''I want to be able to add new resource types to the *template* that will 
automatically be available in all derived publications. possible? IIUC, as it 
is now I have to add a new fallback entry to each derived publication's config 
file by hand, which is not so nice.''
    ''Is there a way to say "take all configuration options from the template 
except those which are explicitly overwritten in the publication's .xconf"? 
This would be a lot saner IMHO.''
  
+   AndreasHartmann says ''"not yet"'', but welcomes patches.
-  * indexing: in <newpub>/config/index_manager.xconf it says '<indexer 
role="org.apache.cocoon.components.search.components.Indexer/default" />'. Does 
this relate to the default publication, or is it just the "default" indexer 
behaviour?
+  * indexing: in <newpub>/config/index_manager.xconf it says '<indexer 
role="org.apache.cocoon.components.search.components.Indexer/default" />'. 
- 
+   ''Does this relate to the default publication, or is it just the "default" 
indexer behaviour?''
+   AndreasHartmann guesses it's the latter, but is not sure.
  
  === Other open issues ===
  
   * Is there a fallback mechanism for the "resources" subdir? What I'd like to 
have is reference a .css, lenya looks in the resources dir of the current 
publication, and if it's not there, look in the template. Or better yet, 
concatenate both css files so that I can overload selected style declarations 
while the rest is taken from the template.
+   ''Yes, there is.'' AndreasHartmann: ''"Actually that should already work 
(see global-sitemap.xmap): <!-- Ancestors resources, css, js, etc... --><!-- 
{publication-id}/{area}/{filename}.inherited.{extention} -->"''
- 
-  * Such a fallback would be nice for images and javascript as well (think 
corporate design). Possible?
   
   * How is access control supposed to work? Ideally, users created in a 
template are valid for all the derived publications, and each publication also 
has its own local user list. Possible?
- 
+   AndreasHartmann: ''"Not yet. That would require a custom accreditable 
manager."'' (Cf. config/ac/ac.conf -> <accreditable-manager type="file"/>)
   * How does the searching behave? (Need to look into that.) Ideally, I want 
to be able to search only the current publication or all publications derived 
from the same template(s).
  

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to