Joern Nettingsmeier wrote:

[...]

Let me start with a small note:

The default publication's instantiator 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.


  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.
Bug or feature? Should this also use "fallback:///"?

IMO that would add confusion. Maybe the instantiator should change this
path when a publication is created.


    * The contents of the passwd/ and policy/ dirs are copied into
<newpub>, probably also from the default publication.

          o 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?

See above - if the path reference in ac.xconf is patched, then these
directories will be needed.

[...]


  Configuration:

    * publication.xml is copied from the template, and the publication
name is changed.

  Content:


    * content/*/* is copied from the template without changes.

Really? IIRC I removed this behaviour some weeks ago ...


    * 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.

Just change the sample.


          o How can I edit this? It should be an example page from the
publication template.

modules/xhtml/samples/*.xml


    * When I create a "links" type page, I see the standard "links"
example page.

          o Again, how do I edit this? I want it to show an example page
for the proper resource type from the template.

modules/links/samples/*.xml


    * As mentioned in [WWW]
http://lenya.apache.org/1_4/reference/publication-templating/index.html,
templates are defined in <newpub>/config/publication.xconf.

          o I want to be able to add new resource types to the
*template* that will automatically be available in all derived
publications. possible?

Resource types are always available to all publications. You just have
to add them to publication.xconf.

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"?

Not yet.

> This would be a lot saner IMHO.

Patches are greatly appreciated.


    * 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?

I guess the latter, but I'm 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.

    * Such a fallback would be nice for images and javascript as well
(think corporate design). Possible?

Actually that should already work (see global-sitemap.xmap):

        <!-- Ancestors resources, css, js, etc... -->
        <!-- {publication-id}/{area}/{filename}.inherited.{extention} -->
        <map:match pattern="*/*/**.inherited.*">
          <map:act type="resource-exists-enhanced">
<map:parameter name="url" value="template-fallback://resources/shared/{3}.{4}"/>
            <map:parameter name="type" value="file"/>
<map:mount uri-prefix="" src="{fallback://lenya/resources-shared.xmap}" check-reload="true" reload-method="synchron"/>
          </map:act>
        </map:match>


    * 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?

Not yet. That would require a custom accreditable manager.


    * 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).

No idea ...


</quote>


one more thing: is it ok to post such basic 1.4 issues to dev, or should
i go to user instead?

IMO the dev list is fine.


and is the use of the wiki for work-in-progress
ok?

Sure, it's fine for protocols etc. But discussions don't seem to work
well in the wiki, so re-posting here was a very good idea.


i'm asking since the dev list receives a mail for every change in
the wiki and i wonder whether people might feel spammed... then again, i
feel that there needs to be some kind of life sign for the documentation
of 1.4 to attract beta testers, which is why i decided to use the wiki
in the first place.

Thanks for your comments!

-- Andreas


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

Reply via email to