Jörn Nettingsmeier wrote:
Andreas Hartmann wrote:
Jörn Nettingsmeier wrote:
out of curiosity, can you explain what problems you are anticipating
when doing it as a usecase, and what those special confs and
conventions are?
At the moment, usecases are designed to occupy the whole page.
All elements outside the "main" usecase GUI (usually a form) are
included (like the site tree in the site area etc.). I don't think
that this will be easy to change, because usecases are invoked
by the core sitemaps before entering any publication-specific
sitemaps.
hmmm. that seems to be true for the "traditional" usecases. however,
there is an alternate usage pattern as described on solprovider's page:
http://solprovider.com/lenya/multiple
i'm not sure if this sort of thing should be encouraged in 1.4, but it
does work (i've been using it for a while), although it bypasses almost
all of the usecase framework...
I took a quick look at it, but it really seems to be quite different
to the current usecase framework.
I see the following options:
a) provide a hook for publications to make their layout available
for usecase view post-processing, e.g. using a dynamically
generated XSLT
not nice. an "embedded" usecase view (as opposed to the current
full-screen ones) should retain the control over flow and continuations,
but use the normal publication pipelines and only inject its own div#body.
which is exactly what a resource type does... so maybe that's the
cleanest approach after all.
I think so too, which would lead to option (c).
b) allow to handle usecases by publications
in a way, that is done if you use solprovider's approach.
c) tie usecases to documents, i.e. a document calls a usecase
and displays its output (that would be a kind of
"usecase resource type")
would work for simple stuff, but where does the flow control go?
Everything would be like it is now. The flow control is still
handled by the usecase framework. The only difference is that
the usecase flow is not called before the publication is handled,
but when the document is accessed.
IMO option c) sounds best, because it doesn't require any
additional concepts but leverages the existing concepts in a
nice way.
sure, but sounds like a can of worms, and definitely post 1.4 stuff.
Hmm, I don't think so - IMO it is quite straightforward.
Basically I wouldn't object to defer it, but if it solves
the search screen issue I'd be glad to introduce it asap.
The second problem is about the fact how usecases are invoked.
When usecases were introduced, they only had the purpose to
implement CMS functionality, i.e. functionality which wouldn't
be available to site visitors. That's why we agreed on a calling
convention to keep things simple, without providing the option
to configure or override it:
?lenya.usecase=...
In my personal opinion, we shouldn't require that "end-user"
functionality like search pages uses this calling convention.
isn't that covered in part by your recent patch
(http://svn.apache.org/viewvc?rev=412982&view=rev) ?
Yes, this is actually one step in this direction (I took a quick
look at the core code to see what would have to be changed).
-- Andreas
--
Andreas Hartmann
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
[EMAIL PROTECTED] [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
