Andreas Hartmann wrote:
Jörn Nettingsmeier wrote:
[...]
would it be possible for the default and blog publications to
fallback-override a usecase view?
You can just put the JX template in
<pub>/lenya/modules/ac-impl/usecases
But I didn't do this because this would be inherited to all
instances.
doh. no points for me this time.
but still, having it in default would be cleaner than hard-coding it
into the core.
and it might serve as an extra incentive to move all interesting
functionality out of default, so that people will not want to inherit
from it. an "empty" publication would be nice as an example some day...
that way, we could show off more features in default without cluttering
everybody's descendant publications with unneeded stuff.
iiuc this ends up in cocoon.xconf, which would mean that the avalon
component resolver would have to a) understand fallback://, which
it might be able to do
Hmmm, what do you mean by "component resolver understands fallback"?
You don't resolve components by URIs ...
the usecases defined in cocoon.xconf are avalon components, right? and i
thought there might be some caching going on, or are the usecase
handlers looked up and created every time one you call one?
i had assumed they are clad in some avalon lifecycle and caching magic,
that's why i feared that using fallback:// in the view uri of a usecase
definition in cocoon.xconf might give strange results.
at what point are the views looked up? since the <view template="">
setting uses a file uri, i had assumed that they get hardwired into the
usecase handler somehow. at least it's not obvious that they are
fallback-capable.
<view uri="fallback://"> i could understand, but it's never used anywhere.
can you explain?
b) not cache the stuff, to be able to do the correct thing for
multiple publications. this is most likely impossible.
doesn't look too promising.
what about publication-specific usecases? how does the
<pubname>/<usecase> scheme work? the blog publication uses that,
maybe we could redefine the ac.login usecase in default and blog?
That would be possible. I guess it is not even inherited ATM, but IMO
it should, and this would again lead to the undesired effect :)
:)
still, can you explain how those <publication>/<usecaseName> thingies
are handled? is that an entirely new usecase, or does it have anything
in common with plain old <usecaseName>?
how are policies affected?
i'm asking because i might have broken the blog in a subtle way with my
usecase renaming...
--
"Open source takes the bullshit out of software."
- Charles Ferguson on TechnologyReview.com
--
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]
