[just a few tidbits here, i'm moving the major issues to separate threads.]
Andreas Hartmann wrote:
> 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.
duly noted. ;)
>> * content/*/* is copied from the template without changes.
>
> Really? IIRC I removed this behaviour some weeks ago ...
i don't think so:
quoting the source (updated today):
> public class Instantiator extends AbstractLogEnabled implements
> org.apache.lenya.cms.publication.templating.Instantiator, Serviceable
> {
>
> protected static final String[] sourcesToCopy = {
> "publication.xml",
> "config/publication.xconf",
> "config/index_manager_index.xconf",
> "config/index_manager.xconf",
> "config/ac/passwd/",
> "config/ac/ac.xconf",
> "config/ac/policies/",
> "config/ac/usecase-policies.xml",
> "config/workflow/workflow.xml",
> "content/"
^^^^^^^^^
> };
unless copying a directory in this context does not imply copying the
files inside.
>> * 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.
that's exactly what i'd like to avoid. here's why: we're launching two
sites (more to follow later) with a common corporate design and common
xml data structures. we want to start easy, using only xhtml. in the
second stage, we want to introduce abstract xml doctypes one by one for
special pages (personal information, literature lists, classes etc.).
this is where it would be cool to just define them in the template and
be able to use them without any modification to the derived pubs.
of course, this feature is not really critical for us, but it seems
elegant and intuitive to me.
> Not yet.
>
>> This would be a lot saner IMHO.
>
> Patches are greatly appreciated.
another point duly taken. ;)
but i fear i'm out of my depth there...
>> * Is there a fallback mechanism for the "resources" subdir?
> 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>
thanks fo the pointer to the global sitemap, this clears things up.
what is "template-fallback://..."? does it have any special meaning, or
is it just a hack to get fallback in attributes that are not piped into
the uri resolver? if so, can i use it everywhere?
regards,
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]
