Jörn Nettingsmeier wrote:
[...]
I had already implemented a generic search page as a resource type
which could be used in arbitrary publications. It was located in the
search module. What do you think about this approach?
IMO we should change this. I don't see a way to implement the
search results page as a usecase without requiring special
configurations / conventions, and I don't see a problem with
implementing it as a resource type which actually worked very well.
to me, a resource type sounds ok. however, i don't really like to have
loads of those "singleton" resource types that you use on just one page...
OK, I see your point.
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. 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
b) allow to handle usecases by publications
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")
IMO option c) sounds best, because it doesn't require any
additional concepts but leverages the existing concepts in a
nice way.
----
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.
With option (c) from above, this issue would be solved as well
(if you can live with a continuation ID request parameter).
----
WDYT?
-- 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]
