You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lenya.apache.org by Andreas Hartmann <an...@apache.org> on 2006/06/08 11:30:58 UTC
[1.4] Search results page is specific to default publication
Hi Lenya devs,
the search results page used by the lucene module is specific to the default
publication:
- the navigation elements are hard-coded
- the reference page2xhtml.xsl stylesheet is hard-coded
- stylesheet parameters are hard-coded
IMO this is not acceptable, it should be possible to include the
results page in any publication. In fact, all modules should be
orthogonal to publications, unless they are specifically designed
to extend a certain publication.
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.
WDYT?
-- Andreas
--
Andreas Hartmann
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
andreas.hartmann@wyona.com andreas@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [1.4] Search results page is specific to default publication
Posted by Jörn Nettingsmeier <po...@uni-duisburg.de>.
Andreas Hartmann wrote:
> Jörn Nettingsmeier wrote:
>> Andreas Hartmann wrote:
>>> 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.
yeah, as i said, it is bypassing most of it, except for the usecase
sitemap. no flowscript, and it's not registered in cocoon.xconf, since
it does not involve java classes and jxtemplates.
<...>
> I think so too, which would lead to option (c).
>
>>> 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.
i see.
>> 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.
well, i don't really understand how intrusive it will be. if you can do
it and it does not break anything other than the already-broken search
results, i'm all for it.
--
"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: pol-admin@uni-due.de, Telefon: 0203/379-2736
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [1.4] Search results page is specific to default publication
Posted by Andreas Hartmann <an...@apache.org>.
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
andreas.hartmann@wyona.com andreas@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [1.4] Search results page is specific to default publication
Posted by Jörn Nettingsmeier <po...@uni-duisburg.de>.
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 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.
> 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?
> 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.
> 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) ?
--
"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: pol-admin@uni-due.de, Telefon: 0203/379-2736
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [1.4]
Posted by Andreas Hartmann <an...@apache.org>.
Andreas Hartmann wrote:
> Jörn Nettingsmeier wrote:
>> Andreas Hartmann wrote:
>>> Andreas Hartmann wrote:
>>>> 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?
>>>
>>> [...]
>>>
>>>> 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")
>>>
>>> I implemented this over the weekend and it works fine.
>>>
>>> But the change would require that a dedicated search page is
>>> added to the publication. IMO that's not a bad thing, though.
>>>
>>> WDYT?
>>
>> can you post a patch somewhere?
>
> I'll check in the usecase module (which is IMO quite useful anyway)
> and attach the changes to the lucene module as a patch to bugzilla.
http://issues.apache.org/bugzilla/show_bug.cgi?id=39801
-- Andreas
--
Andreas Hartmann
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
andreas.hartmann@wyona.com andreas@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [1.4]
Posted by Andreas Hartmann <an...@apache.org>.
Jörn Nettingsmeier wrote:
> Andreas Hartmann wrote:
>> Andreas Hartmann wrote:
>>> 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?
>>
>> [...]
>>
>>> 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")
>>
>> I implemented this over the weekend and it works fine.
>>
>> But the change would require that a dedicated search page is
>> added to the publication. IMO that's not a bad thing, though.
>>
>> WDYT?
>
> can you post a patch somewhere?
I'll check in the usecase module (which is IMO quite useful anyway)
and attach the changes to the lucene module as a patch to bugzilla.
-- Andreas
--
Andreas Hartmann
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
andreas.hartmann@wyona.com andreas@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [1.4]
Posted by Jörn Nettingsmeier <po...@uni-duisburg.de>.
Andreas Hartmann wrote:
> Andreas Hartmann wrote:
>> 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?
>
> [...]
>
>> 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")
>
> I implemented this over the weekend and it works fine.
>
> But the change would require that a dedicated search page is
> added to the publication. IMO that's not a bad thing, though.
>
> WDYT?
can you post a patch somewhere?
--
"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: pol-admin@uni-due.de, Telefon: 0203/379-2736
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
[1.4] (was: Search results page is specific to default publication
Posted by Andreas Hartmann <an...@apache.org>.
Andreas Hartmann wrote:
> 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?
[...]
> 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")
I implemented this over the weekend and it works fine.
But the change would require that a dedicated search page is
added to the publication. IMO that's not a bad thing, though.
WDYT?
-- Andreas
--
Andreas Hartmann
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
andreas.hartmann@wyona.com andreas@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [1.4] Search results page is specific to default publication
Posted by Andreas Hartmann <an...@apache.org>.
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
andreas.hartmann@wyona.com andreas@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [1.4] Search results page is specific to default publication
Posted by Jörn Nettingsmeier <po...@uni-duisburg.de>.
Andreas Hartmann wrote:
> In fact, all modules should be
> orthogonal to publications, unless they are specifically designed
> to extend a certain publication.
that sounds good.
> 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...
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?
--
"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: pol-admin@uni-due.de, Telefon: 0203/379-2736
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org