You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@lenya.apache.org by so...@gmail.com on 2005/04/15 01:28:14 UTC
Lenya and i18n
On 4/13/05, es wrote:
> Hi Paul!
> I saw in the lenya ml you managed to choose the homepage based on the
> visitor's browser's language and also to make all site navigation
> follow the visitor-chosen language. I'm a bit lost following the
> discussion can you please sum up how did you achieve it?
> thanks in advance
> Eli
=== Change Lenya to always use the visitor's language choice:
[See the discussion titled "Helpful Notes about Installation (and
Suggestions for Developers)" for a very long thread about whether this
is a good thing.]
Change every sitemap from:
<map:parameter name="locale" value="{request:locale}"/>
To:
<map:parameter name="locale" value="{page-envelope:document-language}"/>
Files to change:
build\lenya\webapp\sitemap.xmap
build\lenya\webapp\global-sitemap.xmap
build\lenya\webapp\lenya\info.xmap
build\lenya\webapp\lenya\lenya.xmap
build\lenya\webapp\lenya\navigation.xmap
build\lenya\webapp\lenya\usecase.xmap
build\lenya\webapp\lenya\pubs\{pub}\doctypes.xmap
build\lenya\webapp\lenya\pubs\{pub}\publication-sitemap.xmap
build\lenya\webapp\lenya\pubs\{pub}\sitemap.xmap
build\lenya\webapp\lenya\pubs\{pub}\usecase-bxeng.xmap
You may want to skip:
- build\lenya\webapp\admin.xmap
to keep the CMS GUI in the browser's language. Most of the discussion
is about this. I believe it should be changed in production so
editors can edit their own language with controls in the same
langauge, but read the other thread for the objections.
There is no point in fixing:
- build\lenya\webapp\lucene.xmap
because the standard URL for Search does not contain the language
information, so {page-envelope:document-language} is always empty. All
Search pages must be in the browser language. (I am almost finished
with a rewrite of Publication Search fixing this and many other
issues. Stay tuned.)
=== Homepage defaults to browser's language:
This is a hack because the website I am building has only 2 languages:
publication-sitemap.xmap
After:
<map:match pattern="**/">
<map:redirect-to uri="index.html"/>
</map:match>
Add:
<map:match pattern="**/index.html">
<map:select type="parameter">
<map:parameter name="parameter-selector-test"
value="{request:locale}"/>
<map:when test="xx">
<map:redirect-to uri="index_xx.html"/>
</map:when>
<map:when test="xx_XX">
<map:redirect-to uri="index_xx.html"/>
</map:when>
<map:otherwise>
<map:redirect-to uri="index_en.html"/>
</map:otherwise>
</map:select>
</map:match>
Repeat the map:when clauses for each locale. If some locales include
the country, you would need to specify each separately using the
second example. Replace the final "index_en.html" with your default
language.
A (better) universal solution would extract the language code from
request:locale, then resource-exists check the correct index_xx.xml,
and either redirect to it (if it exists), or use the default language
(if not).
The code would look like this: [THIS DOES NOT WORK!]
<map:match pattern="**/index.html">
<map:select type="resource-exists">
<map:when test="{1}/index/index_" +
substring({request:locale}, 1, 2) + ".xml">
<map:redirect-to uri="index_" +
substring({request:locale}, 1, 2) + ".html"/>
</map:when>
</map:select>
<map:redirect-to uri="index_en.html"/>
</map:match>
I could not discover how to call substring() within an XMAP. A
workaround would be to send it to a JavaScript function, but that is
too complex for such simple functionality. Anybody else know?
solprovider (Paul)
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
For additional commands, e-mail: user-help@lenya.apache.org
Re: making search a real usecase
Posted by so...@gmail.com.
On 4/21/05, Gregor J. Rothfuss <gr...@apache.org> wrote:
> my worries were not so much directed at you, they were directed at the
> existing lenya developers. good to hear you have some time.
Not good. I've been hearing I'll have a job next week since late
January. I finally won a tiny contract, and then the customer says
the budget will not exist for several months. Know anybody who can
use a buiness analyst/UI designer/programmer who can write error-free
code faster than most people can read a book?
> i started to make search a use case on 1.4, but could not stomach to
> untangle the mess that is search-and_results.xsp
Making search into a usecase is just creating usecase-search.xmap and
changing the link in navigation/search.xsl. I modified
search-and-results.xsp to add new functionality. The additions are
commented, so they may help you make sense of the rest.
solprovider
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: making search a real usecase
Posted by "Gregor J. Rothfuss" <gr...@apache.org>.
solprovider@gmail.com wrote:
> Sorry. I agree totally with your thoughts from the project management
> perspective. I had not planned to get involved with development. The
> plan was to install the latest stable version, then make it do what we
> need. I like XML, XSL, JS, and Java, and my C/C++ skills are very
> rusty, so when looking at Apache for a CMS, Lenya was the obvious
> choice. In the spirit of OSS, I wanted to share my additions. I was
> not expecting to change the architecture of 1.2, and am still trying
> to add all functionality as publication-specific. As I said in my
> last post, if 1.4 will be ready soon and solves my issues, I will work
> on it. (We planned to go live by mid-May, but the customer delayed
> the deadline several months, so I have some time.)
my worries were not so much directed at you, they were directed at the
existing lenya developers. good to hear you have some time.
i started to make search a use case on 1.4, but could not stomach to
untangle the mess that is search-and_results.xsp
http://svn.apache.org/viewcvs.cgi/lenya/trunk/src/java/org/apache/lenya/cms/search/usecases/Search.java?rev=157298&view=markup
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: making search a real usecase
Posted by Michael Wechner <mi...@wyona.com>.
Thorsten Scherler wrote:
>IMO our main focus is to finish up 1.4 and provide bugfixes (but no new
>features, if they are based on 1.4) for 1.2. Our future lies in 1.4 and
>not in 1.2.
>
>
agreed, but do not forget productive environments which are based on
1.2.X, which means if people provide improvements and enhancements, then
we should
appreciate and implement them.
Michi
>my 2 cents
>
>salu2
>
>
--
Michael Wechner
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
michael.wechner@wyona.com michi@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
For additional commands, e-mail: user-help@lenya.apache.org
Re: making search a real usecase
Posted by Thorsten Scherler <th...@apache.org>.
On Thu, 2005-04-21 at 13:47 -0400, solprovider@gmail.com wrote:
> solprovider wrote:
> > >> The instructions will be for extending a Lenya 1.2.2 publication.
> > >> Could/should these functions be added to the Default publication?
>
> Andreas Hartmann wrote:
> > > This will be decided by a vote.
> > > My personal roadmap would be:
> > > - focus on 1.4 for these developments
> > > - put more efforts in the design of the plug-in support
> > > - implement the functionality as plug-ins
> > > (especially contact form and newsletter would be perfect examples)
>
> On 4/21/05, Gregor J. Rothfuss <gr...@apache.org> wrote:
> > I am a bit worried by this trend of tacking on new functionality on 1.2.
> > while I understand the stability concerns with 1.4 for customer
> > projects, 1.2 just does not have the sound architecture that 1.4 has.
> >
> > also, saying "1.4 is not stable enough for customer projects" forever,
> > while bolting on new features on 1.2, is not the way to go, as these
> > additions do not increase stability of 1.2 (which is supposed to be in
> > maintainance mode). This effectively makes both branches instable.
> > -gregor
>
> Sorry. I agree totally with your thoughts from the project management
> perspective. I had not planned to get involved with development. The
> plan was to install the latest stable version, then make it do what we
> need. I like XML, XSL, JS, and Java, and my C/C++ skills are very
> rusty, so when looking at Apache for a CMS, Lenya was the obvious
> choice. In the spirit of OSS, I wanted to share my additions. I was
> not expecting to change the architecture of 1.2, and am still trying
> to add all functionality as publication-specific. As I said in my
> last post, if 1.4 will be ready soon and solves my issues, I will work
> on it. (We planned to go live by mid-May, but the customer delayed
> the deadline several months, so I have some time.)
>
I actually share the views from gregor and solprovider. We should *not*
try to backport all new features coming in 1.4 for 1.2. If somebody
wants to do it (s)he can be our guest and send patches. ...but to *hack*
features into 1.2 that can be smoothly integrated into 1.4 just does not
makes sense.
A maintainment branch should not be open for new feature on all price.
If you install woody you will need backports for it, but nobody from
debian will provide them.
IMO our main focus is to finish up 1.4 and provide bugfixes (but no new
features, if they are based on 1.4) for 1.2. Our future lies in 1.4 and
not in 1.2.
my 2 cents
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
For additional commands, e-mail: user-help@lenya.apache.org
Re: making search a real usecase
Posted by so...@gmail.com.
solprovider wrote:
> >> The instructions will be for extending a Lenya 1.2.2 publication.
> >> Could/should these functions be added to the Default publication?
Andreas Hartmann wrote:
> > This will be decided by a vote.
> > My personal roadmap would be:
> > - focus on 1.4 for these developments
> > - put more efforts in the design of the plug-in support
> > - implement the functionality as plug-ins
> > (especially contact form and newsletter would be perfect examples)
On 4/21/05, Gregor J. Rothfuss <gr...@apache.org> wrote:
> I am a bit worried by this trend of tacking on new functionality on 1.2.
> while I understand the stability concerns with 1.4 for customer
> projects, 1.2 just does not have the sound architecture that 1.4 has.
>
> also, saying "1.4 is not stable enough for customer projects" forever,
> while bolting on new features on 1.2, is not the way to go, as these
> additions do not increase stability of 1.2 (which is supposed to be in
> maintainance mode). This effectively makes both branches instable.
> -gregor
Sorry. I agree totally with your thoughts from the project management
perspective. I had not planned to get involved with development. The
plan was to install the latest stable version, then make it do what we
need. I like XML, XSL, JS, and Java, and my C/C++ skills are very
rusty, so when looking at Apache for a CMS, Lenya was the obvious
choice. In the spirit of OSS, I wanted to share my additions. I was
not expecting to change the architecture of 1.2, and am still trying
to add all functionality as publication-specific. As I said in my
last post, if 1.4 will be ready soon and solves my issues, I will work
on it. (We planned to go live by mid-May, but the customer delayed
the deadline several months, so I have some time.)
solprovider
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: making search a real usecase
Posted by so...@gmail.com.
Design thoughts on new functionality, and impact of 1.4 upgrade
> > > - Login/New Registration/Visitor Information page
I am storing the dynamic data (newsletter frequency and list of
favorite pages) in the Description field of User because the
fieldnames for User are hardcoded. This could be much improved if
User added:
User.getField(fieldname, [default])
User.setField(fieldname, value)
[I need to finish maintaining dynamic data. Then it is code complete,
and I will post it.]
> > > - Deny access to unauthorized areas
Three functions required:
1. Disallow access.
2. Optionally remove from navigation.
3. Remove from Search.
In reverse order:
Search is handled by the code on my website. The configuration is
hardcoded, but could easily be loaded from a file.
[I will not work on this until all other required functionality is complete.]
Navigation: The removal is handled by the XSL in "common.xsl" which is
imported into various page2xhtml.xsl. The code depends on aggregation
including login.xsp modified to add visitor's Groups, as well as
changes to menu.xsl and map.xsl (creates a sitemap for display).
Again, the configuration is hardcoded. For a generic solution:
- navigation.xmap <map:match pattern="*/*/sitetree/**.xml"> should
aggregate the modified login.xsp and the config.
- sitetree2nav.xsl should remove the unauthorized entries.
[I will not work on this until all other required functionality is complete.]
True security: The above remove links to the documents, but do not
prevent crafting a URL or using an link to a document. I was excited
when I thought the "auth-protect" Action existed in Lenya. This
function should be handled by a map:act. (I am still attempting to
handle all functionality within a publication for easy portability.
Adding a class file violates that. OTOH, I have not designed a
solution without it yet.)
> > > - Contact Us form
The front-end worked until I broke it while finishing the login
(actually session usecase) page. I have not written the backend yet.
[Second highest priority after finishing the login/session.]
> > > - Newsletter builder
Design: Add to newsletter if the document has a Description, and the
creation date is in the range for a specific visitor. Needs to
maintain who received what. Want to use User, but no dynamic fields
and already overloaded Description. Will probably use a log file.
[This is waiting until I finish Contact Us, because I will reuse the
mail function.]
> On Thu, 2005-04-21 at 08:52 +0200, Andreas Hartmann wrote:
> > My personal roadmap would be:
> > - focus on 1.4 for these developments
> > - put more efforts in the design of the plug-in support
> > - implement the functionality as plug-ins
> > (especially contact form and newsletter would be perfect examples)
My customer needs this functionality now. Will 1.4 be ready for
production soon? Will 1.4 add dynamic fields to User? Will 1,4 add
an auth-protect Action? Will the ac policies be modified to handle
"Deny Access"? Will all the bugs I mentioned in various posts be
fixed? Tell me the developers will accept all of this and I will
switch my efforts to 1.4. Then I will ask what you mean by plug-ins.
On 4/21/05, Thorsten Scherler <th...@apache.org> wrote:
> As soon as we will use the view/viewHelper for presentation this
> functionality can be stored in a contract which can be easily added to
> lenya *without* touching the xsl's. Point 2 on andreas list.
>
> The other thing is that views are page specific and/global usable. One
> would define the contracts that you want to use in a forrest:view and by
> this control as well the content that should be added.
> thorsten
Views sound useful for the newsletter. My current design requires
selecting documents with a non-blank Description by creation date.
Check each against a non-existant security system, and possibly
whether the visitor was already sent it. Then build the newletter and
send. How much of this is solved by Views?
solprovider
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: making search a real usecase
Posted by Thorsten Scherler <th...@apache.org>.
On Thu, 2005-04-21 at 08:52 +0200, Andreas Hartmann wrote:
> >
> > Document as you develop. I get calls to maintain code I wrote a
> > decade ago; a million lines of code later, I forget what the code is
> > doing. It is even more important in a collaborative environment. In
> > this case, I was writing the instructions so a newbie user could
> > follow them; I thought the functions are useful, did not know if the
> > developers would accept any of my thoughts, the Wiki page
> > "ClosedUserGroups" is extremely incomplete, and the architecture for
> > search could not support ClosedUserGroups.
> >
> > I will post more instructions when the functions are complete,
> > probably next week:
> > - Login/New Registration/Visitor Information page
> > (Need to finish maintaining dynamic data.)
> > - Deny access to unauthorized areas
> > (Lenya does not make this easy. I will change the search instructions
> > to use the config for this when it is complete.)
> > - Contact Us form
> > (I broke it when making Login into a usecase. Fix that and add code
> > to handle mailing.)
> > - Newsletter builder
> > (Much later. Need to design how the CMS GUI decides if a document
> > should be included.)
>
> This sounds very interesting.
> I'm looking forward to seeing this functionality.
>
>
> > The instructions will be for extending a Lenya 1.2.2 publication.
> > Could/should these functions be added to the Default publication?
>
> This will be decided by a vote.
> My personal roadmap would be:
>
> - focus on 1.4 for these developments
> - put more efforts in the design of the plug-in support
> - implement the functionality as plug-ins
> (especially contact form and newsletter would be perfect examples)
>
As soon as we will use the view/viewHelper for presentation this
functionality can be stored in a contract which can be easily added to
lenya *without* touching the xsl's. Point 2 on andreas list.
The other thing is that views are page specific and/global usable. One
would define the contracts that you want to use in a forrest:view and by
this control as well the content that should be added.
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: making search a real usecase
Posted by "Gregor J. Rothfuss" <gr...@apache.org>.
Andreas Hartmann wrote:
>> The instructions will be for extending a Lenya 1.2.2 publication.
>> Could/should these functions be added to the Default publication?
>
>
> This will be decided by a vote.
> My personal roadmap would be:
>
> - focus on 1.4 for these developments
> - put more efforts in the design of the plug-in support
> - implement the functionality as plug-ins
> (especially contact form and newsletter would be perfect examples)
strong +1
i am a bit worried by this trend of tacking on new functionality on 1.2.
while i understand the stability concerns with 1.4 for customer
projects, 1.2 just does not have the sound architecture that 1.4 has.
also, saying "1.4 is not stable enough for customer projects" forever,
while bolting on new features on 1.2, is not the way to go, as these
additions do not increase stability of 1.2 (which is supposed to be in
maintainance mode). this effectively makes both branches instable.
-gregor
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: making search a real usecase
Posted by Andreas Hartmann <an...@apache.org>.
solprovider@gmail.com wrote:
> On 4/20/05, Andreas Hartmann <an...@apache.org> wrote:
[...]
>>Design changes should generally be discussed on the dev list
>>before they are applied. Many things have a purpose, which might
>>be not quite obvious sometimes.
>
> Can this discussion be moved to the dev list?
Sure
>>>- Indexes the XML files, rather than spidering the website.
>>
>>How is this managed? For instance, imagine the following case:
>>- a page is marked as "disabled", e.g., using meta data
>>- the XSLT removes the content and adds a "This page is removed" message
>>- the page doesn't appear in the navigation
>>In this case, would the content of page be indexed?
>>(I have no idea how it works ATM if your changes are not considered)
>
> I could not find a "Disable" action.
It's not implemented in the default & blog publications, but
we used this approach in a customer project.
> The "Deactivate" function
> removes the language version of the document from "live", so issue
> solved. ("Deactivate" should ask if all language versions should be
> deactivated.
Yes, this is on the wishlist for 1.4.
> Remember our discussion about creating all language
> version.) The document is not removed from the index until the
> indexer is run again. (The indexer needs to be scheduled. Windows
> has difficulty recreating the index while Lenya is running due to
> file-locking issues. My instructions recreate the index as "new", so
> maybe using "incremental update" solves this.)
>
> If there was <dc:status>disabled</dc:status>, adding a check to this
> process would be easy;it already checks by URL and language.
> (Although I would rewrite the code so the IFs are easier to control.
> The END IFs are currently very far away.)
OK
>>>- Creates the excerpt from the HTML BODY, rather than using Lucene's
>>>excerpt (although that is configurable. More work would allow
>>>fallback to make certain the excerpt includes the search terms.)
>>
>>What's the difference between these approaches?
[...]
OK, thanks for the explaination
>>>Lenya 1.2.2's security system is useless.
>>
>>Of course you're free to tell your opinion, but these are quite harsh
>>and demotivating words considering that people spend their leisure time
>>on this project. Maybe it matches the requirements of the people who
>>developed it?
>
> I apologize. I should have phrased it:
> "Lenya 1.2.2's access control policies cannot be used as a security system."
>
> Access Control has 3 goals:
> 1. Deny access if not authorized (and hide existence of unauthorized data.)
> 2. Grant access if authorized.
> 3. Allow functions if authorized.
>
> Lenya's current access policies are only concerned with #3. It is
> designed to add "roles" so additional functionality can be granted to
> specific Groups. With the Inheriting Policy Manager, and the default
> <ac:world><ac:role id="visit"/></ac:world>, it is not possible to deny
> access based on the access policies. It is confusing to call it an
> "Access Control" system without performing the basic functions of
> Access Control; it is like finding a "Publishing" system that can only
> delete documents.
OK, I see your points. This has been discussed frequently, and it looks
like the community is waiting for patches. There are some ideas and
instructions how it should work, but as long as no developer has personal
interest in this functionality, it won't be developed ...
There was a proposal about replacing the current Lenya access control
system with an existing component, maybe this is the preferrable way
to go.
>>>Worst of all, this was done in Lenya 1.2.2. I have not looked at 1.4,
>>>and have no idea how many of these changes are obsolete.
>>
>>AFAIK the search hasn't undergone major refactorings in 1.4, so your
>>contributions won't be obsolete there.
>
> Search was not the biggest concern. The code checks Identity's
> Groups, and the Identity API could use some work to add functions
> like:
> - Identity.getGroups()
> - Identity.getRoles(context)
> If the current getIdentifiables() and getAccreditables() are changed,
> my code needs updating.
>
>
>
>>Your contributions are very appreciated, especially as they are well
>>documented.
>>-- Andreas
>
> Document as you develop. I get calls to maintain code I wrote a
> decade ago; a million lines of code later, I forget what the code is
> doing. It is even more important in a collaborative environment. In
> this case, I was writing the instructions so a newbie user could
> follow them; I thought the functions are useful, did not know if the
> developers would accept any of my thoughts, the Wiki page
> "ClosedUserGroups" is extremely incomplete, and the architecture for
> search could not support ClosedUserGroups.
>
> I will post more instructions when the functions are complete,
> probably next week:
> - Login/New Registration/Visitor Information page
> (Need to finish maintaining dynamic data.)
> - Deny access to unauthorized areas
> (Lenya does not make this easy. I will change the search instructions
> to use the config for this when it is complete.)
> - Contact Us form
> (I broke it when making Login into a usecase. Fix that and add code
> to handle mailing.)
> - Newsletter builder
> (Much later. Need to design how the CMS GUI decides if a document
> should be included.)
This sounds very interesting.
I'm looking forward to seeing this functionality.
> The instructions will be for extending a Lenya 1.2.2 publication.
> Could/should these functions be added to the Default publication?
This will be decided by a vote.
My personal roadmap would be:
- focus on 1.4 for these developments
- put more efforts in the design of the plug-in support
- implement the functionality as plug-ins
(especially contact form and newsletter would be perfect examples)
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: making search a real usecase
Posted by so...@gmail.com.
On 4/20/05, Andreas Hartmann <an...@apache.org> wrote:
> solprovider@gmail.com wrote:
> [Bugzilla is] actually quite easy to use. Feel free to give it a try.
I should have time on Saturday. I need to review all my posts for
mentions of various bugs.
> > How should this be handled? The instructions include many design
> > changes,
> Design changes should generally be discussed on the dev list
> before they are applied. Many things have a purpose, which might
> be not quite obvious sometimes.
Can this discussion be moved to the dev list?
> > - Indexes the XML files, rather than spidering the website.
> How is this managed? For instance, imagine the following case:
> - a page is marked as "disabled", e.g., using meta data
> - the XSLT removes the content and adds a "This page is removed" message
> - the page doesn't appear in the navigation
> In this case, would the content of page be indexed?
> (I have no idea how it works ATM if your changes are not considered)
I could not find a "Disable" action. The "Deactivate" function
removes the language version of the document from "live", so issue
solved. ("Deactivate" should ask if all language versions should be
deactivated. Remember our discussion about creating all language
version.) The document is not removed from the index until the
indexer is run again. (The indexer needs to be scheduled. Windows
has difficulty recreating the index while Lenya is running due to
file-locking issues. My instructions recreate the index as "new", so
maybe using "incremental update" solves this.)
If there was <dc:status>disabled</dc:status>, adding a check to this
process would be easy;it already checks by URL and language.
(Although I would rewrite the code so the IFs are easier to control.
The END IFs are currently very far away.)
> > - Creates the excerpt from the HTML BODY, rather than using Lucene's
> > excerpt (although that is configurable. More work would allow
> > fallback to make certain the excerpt includes the search terms.)
> What's the difference between these approaches?
Lucene starts with the entire document with all tags removed. When
indexing HTML, this is mostly fine since the META tags are removed by
the XML2HTML process, although the navigation elements are included,
including the breadcrumbs, so all documents under a document with a
matching title will be included (hopefully with a low score). When
indexing XML, all the META data is added to the excerpt, making a
confusing excerpt:
Lenya default publicationThe welcome page for the Lenya default
publicationmyreviewer|My
Reviewer|myreviewer@solprovider.com2005-01-31...
My code builds the excerpt from the HTML BODY. It looks much cleaner.
BUG: There is a bug in the Lucene remove tags process. All tags are
removed, but a single space should be added when the tag is a <BR> or
<TD>, or if there is whitespace between tags. Example:
<H1>Hello</H1><TABLE><TR><TD>This page we<B>lcom</B>es you
here.<BR>Now go away.</TD></TR></TABLE>
- becomes:
HelloThis page welcomes you here.Now go away.
- A search for "this" fails because it is not a word in the index.
> > Lenya 1.2.2's security system is useless.
> Of course you're free to tell your opinion, but these are quite harsh
> and demotivating words considering that people spend their leisure time
> on this project. Maybe it matches the requirements of the people who
> developed it?
I apologize. I should have phrased it:
"Lenya 1.2.2's access control policies cannot be used as a security system."
Access Control has 3 goals:
1. Deny access if not authorized (and hide existence of unauthorized data.)
2. Grant access if authorized.
3. Allow functions if authorized.
Lenya's current access policies are only concerned with #3. It is
designed to add "roles" so additional functionality can be granted to
specific Groups. With the Inheriting Policy Manager, and the default
<ac:world><ac:role id="visit"/></ac:world>, it is not possible to deny
access based on the access policies. It is confusing to call it an
"Access Control" system without performing the basic functions of
Access Control; it is like finding a "Publishing" system that can only
delete documents.
> > Worst of all, this was done in Lenya 1.2.2. I have not looked at 1.4,
> > and have no idea how many of these changes are obsolete.
> AFAIK the search hasn't undergone major refactorings in 1.4, so your
> contributions won't be obsolete there.
Search was not the biggest concern. The code checks Identity's
Groups, and the Identity API could use some work to add functions
like:
- Identity.getGroups()
- Identity.getRoles(context)
If the current getIdentifiables() and getAccreditables() are changed,
my code needs updating.
> Your contributions are very appreciated, especially as they are well
> documented.
> -- Andreas
Document as you develop. I get calls to maintain code I wrote a
decade ago; a million lines of code later, I forget what the code is
doing. It is even more important in a collaborative environment. In
this case, I was writing the instructions so a newbie user could
follow them; I thought the functions are useful, did not know if the
developers would accept any of my thoughts, the Wiki page
"ClosedUserGroups" is extremely incomplete, and the architecture for
search could not support ClosedUserGroups.
I will post more instructions when the functions are complete,
probably next week:
- Login/New Registration/Visitor Information page
(Need to finish maintaining dynamic data.)
- Deny access to unauthorized areas
(Lenya does not make this easy. I will change the search instructions
to use the config for this when it is complete.)
- Contact Us form
(I broke it when making Login into a usecase. Fix that and add code
to handle mailing.)
- Newsletter builder
(Much later. Need to design how the CMS GUI decides if a document
should be included.)
The instructions will be for extending a Lenya 1.2.2 publication.
Could/should these functions be added to the Default publication?
solprovider
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
For additional commands, e-mail: user-help@lenya.apache.org
Re: making search a real usecase
Posted by Andreas Hartmann <an...@apache.org>.
solprovider@gmail.com wrote:
> On 4/19/05, Gregor J. Rothfuss <gr...@apache.org> wrote:
>
>>or even better, create an issue in bugzilla and post it there, so it
>>does not get lost
>
>
> I posted the instructions to my website. I am new to OSS
> collaboration, and have no familiarity with Bugzilla.
It's actually quite easy to use. Feel free to give it a try.
Here are some hints on contributing code:
http://lenya.apache.org/community/index.html#Contribute+code
> How should this be handled? The instructions include many design
> changes,
Design changes should generally be discussed on the dev list
before they are applied. Many things have a purpose, which might
be not quite obvious sometimes.
> and many bug fixes:
> - Requires fixing the "namespaces in data" bug.
> - Indexes the XML files, rather than spidering the website.
How is this managed? For instance, imagine the following case:
- a page is marked as "disabled", e.g., using meta data
- the XSLT removes the content and adds a "This page is removed" message
- the page doesn't appear in the navigation
In this case, would the content of page be indexed?
(I have no idea how it works ATM if your changes are not considered)
> - Creates the excerpt from the HTML BODY, rather than using Lucene's
> excerpt (although that is configurable. More work would allow
> fallback to make certain the excerpt includes the search terms.)
What's the difference between these approaches?
> - Search is a usecase.
> - Search is language aware. (Although I did not verify everything uses i18n.)
These points sound very useful.
> - Changed to equalsIgnoreCase() so not assuming search parameters use
> uppercase AND and OR.
> [I fix bugs and poor design as I notice them. I doubt I documented
> all the changes, which is why "search-and-results.xsp" is a download
> instead of a list of changes. Someone needs to create a diff, but
> many changes were superficial, such as moving the <xsp:logic> tags to
> the beginning of each line.
> I also changed the "querystring" variable
> to "query", because "querystring" should be considered a reserved word
> when dealing with HTTP, and "query" is shorter in the URL's
> querystring.]
>
> The security is hardcoded into search-and-results.xsp. A generic
> solution should pull the data from a config file. Best would be
> building the config file from the security policies, but Lenya 1.2.2's
> security system is useless.
Of course you're free to tell your opinion, but these are quire harsh
and demotivating words considering that people spend their leisure time
on this project. Maybe it matches the requirements of the people who
developed it?
> Worst of all, this was done in Lenya 1.2.2. I have not looked at 1.4,
> and have no idea how many of these changes are obsolete.
AFAIK the search hasn't undergone major refactorings in 1.4, so your
contributions won't be obsolete there.
> Hopefully
> some of the workarounds for bugs in 1.2.2 are not needed.
>
> Let me know if/how this can/should be integrated into the main tree.
Your contributions are very appreciated, especially as they are well
documented. I don't think that I find the time to review them soon,
but probably someone else will.
Thanks,
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
For additional commands, e-mail: user-help@lenya.apache.org
Re: making search a real usecase
Posted by so...@gmail.com.
On 4/19/05, Gregor J. Rothfuss <gr...@apache.org> wrote:
> or even better, create an issue in bugzilla and post it there, so it
> does not get lost
I posted the instructions to my website. I am new to OSS
collaboration, and have no familiarity with Bugzilla.
How should this be handled? The instructions include many design
changes, and many bug fixes:
- Requires fixing the "namespaces in data" bug.
- Indexes the XML files, rather than spidering the website.
- Creates the excerpt from the HTML BODY, rather than using Lucene's
excerpt (although that is configurable. More work would allow
fallback to make certain the excerpt includes the search terms.)
- Search is a usecase.
- Search is language aware. (Although I did not verify everything uses i18n.)
- Changed to equalsIgnoreCase() so not assuming search parameters use
uppercase AND and OR.
[I fix bugs and poor design as I notice them. I doubt I documented
all the changes, which is why "search-and-results.xsp" is a download
instead of a list of changes. Someone needs to create a diff, but
many changes were superficial, such as moving the <xsp:logic> tags to
the beginning of each line. I also changed the "querystring" variable
to "query", because "querystring" should be considered a reserved word
when dealing with HTTP, and "query" is shorter in the URL's
querystring.]
The security is hardcoded into search-and-results.xsp. A generic
solution should pull the data from a config file. Best would be
building the config file from the security policies, but Lenya 1.2.2's
security system is useless.
Worst of all, this was done in Lenya 1.2.2. I have not looked at 1.4,
and have no idea how many of these changes are obsolete. Hopefully
some of the workarounds for bugs in 1.2.2 are not needed.
Let me know if/how this can/should be integrated into the main tree.
solprovider
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
For additional commands, e-mail: user-help@lenya.apache.org
Re: making search a real usecase
Posted by "Gregor J. Rothfuss" <gr...@apache.org>.
solprovider@gmail.com wrote:
> I will post the instructions to my website and send a top-level post
> to the Lenya User List. The instructions are over 4 screens (at
> 1024x768), not including a new version of "search-and-results.xsp"
> (16 screens) and new files "searchfixer.xsl" (2 screens) and
> "usecase-search.xmap" (3 screens), so they will not be welcome as an
> email. I should have it posted tomorrow.
or even better, create an issue in bugzilla and post it there, so it
does not get lost
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
For additional commands, e-mail: user-help@lenya.apache.org
Re: making search a real usecase
Posted by so...@gmail.com.
solprovider@gmail.com <so...@gmail.com> wrote:
> > > > > I am almost finished with a rewrite of Publication Search fixing many issues.
Gregor J. Rothfuss <gr...@apache.org> wrote:
> > > > Are you going to make the lucene search a real usecase?
solprovider@gmail.com <so...@gmail.com> wrote:
> > I finished the backend search filters
> > and started the frontend. Graphics
> > and many links are destroyed, and it is difficult to get language
> > information. The new code allows multiple languages for search
> > results without remembering which to use for the GUI. Implementing a
> > usecase would solve these issues.
solprovider@gmail.com <so...@gmail.com> wrote:
> I coded the search usecase yesterday. It works well and solves the
> issues from above. Items left:
> 1. Need to rewrite "{pub}/lenya/lucene.xmap" so it fails.
> 2. Fix multiple language selection.
Search Publication as a usecase with language support and protected
(limited access, "Members' only") sections is complete and functional
in my development publication.
I will post the instructions to my website and send a top-level post
to the Lenya User List. The instructions are over 4 screens (at
1024x768), not including a new version of "search-and-results.xsp"
(16 screens) and new files "searchfixer.xsl" (2 screens) and
"usecase-search.xmap" (3 screens), so they will not be welcome as an
email. I should have it posted tomorrow.
solprovider
---
Here are the bugs I found:
*** BUG ***
String language = <xsp-request:get-parameter-values as="xml"
name="language" default="en"/>;
OR
String language = <xsp-request:get-parameter-values as="node"
name="language" default="en"/>;
ERRORS:
"Type mismatch: cannot convert from void to String"
XSPRequestHelper.getParameterValues(objectModel, this.contentHandler,
"language", null, null);
*** BUG ***
String urlQuerystring = <xsp-request:get-query-string />;
BUG: The query string is repeated.
GIVEN: http://myserver/something?cms=lenya&dev=solprovider
RETURNS: cms=lenya&dev=solprovider&cms=lenya&dev=solprovider
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
For additional commands, e-mail: user-help@lenya.apache.org
Re: making search a real usecase (Another BUG!)
Posted by so...@gmail.com.
> I coded the search usecase yesterday. It works well and solves the
> issues from above. There are two items left:
> 1. Need to rewrite "{pub}/lenya/lucene.xmap" so it fails.
> 2. It uses checkboxes to allow searching multiple languages. Browsers
> send multiple entries in the form's GET, but my code assumes
> concatenated data ("en,de"). In "search-and-results.xsp":
>
> I tried:
> String language = <xsp-request:get-parameter name="language" default="en"/>;
> This code does not return all values when the data is in multiple parameters.
>
> I switched to:
> String language = <xsp-request:get-parameter-values as="xml"
> name="language" default="en"/>;
> but that errors with:
> "Type mismatch: cannot convert from void to String"
> XSPRequestHelper.getParameterValues(objectModel, this.contentHandler,
> "language", null, null);
>
> I am assuming this is a BUG. Let me know if I missed something. I
> will override with client-side JavaScript for now.
Changed my mind again; I did not like the client-side JavaScript. Now
"search-and-results.xsp" parses the query_string to get a multi-value
string for "language". It works well.
FOUND ANOTHER BUG!
String urlQuerystring = <xsp-request:get-query-string />;
BUG: The query string is repeated.
GIVEN: http://myserver/something?cms=lenya&dev=solprovider
RETURNS: cms=lenya&dev=solprovider&cms=lenya&dev=solprovider
This bug does not affect my code, since it only cares if a language is
listed at all and ignores repeats. And it is possible to unique() the
values if necessary. But it is still a bug.
solprovider
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
For additional commands, e-mail: user-help@lenya.apache.org
Re: making search a real usecase
Posted by so...@gmail.com.
solprovider@gmail.com <so...@gmail.com> wrote:
> > > > I am almost finished with a rewrite of Publication Search fixing many issues.
On 4/15/05, Gregor J. Rothfuss <gr...@apache.org> wrote:
> > > Are you going to make the lucene search a real usecase? I started with
> > > this on trunk using the usecase framework
On 4/16/05, solprovider@gmail.com <so...@gmail.com> wrote:
> > My entry point for this functionality is adding (a revised version of)
> > lucene.xmap to the {pub}/lenya directory.
On 4/18/05, solprovider@gmail.com <so...@gmail.com> wrote:
> I changed my mind. I finished the backend search filters
> and started the frontend and remembered how awful it is to call xsl
> from {pub}/xslt from a non-standard URL. Graphics
> and many links are destroyed, and it is difficult to get language
> information. The new code allows multiple languages for search
> results without remembering which to use for the GUI. Implementing a
> usecase would solve these issues.
I coded the search usecase yesterday. It works well and solves the
issues from above. There are two items left:
1. Need to rewrite "{pub}/lenya/lucene.xmap" so it fails to an "That
is not allowed." message. Otherwise a visitor could bypass the
filtering by typing a URL.
[The "login" usecase should be treated similarly, but I think the
worst case of bypassing my "session" usecase is losing the formatting
and extra features, such as translating the email address into a valid
username.]
2. It uses checkboxes to allow searching multiple languages. Browsers
send multiple entries in the form's GET, but my code assumes
concatenated data ("en,de"). In "search-and-results.xsp":
I tried:
String language = <xsp-request:get-parameter name="language" default="en"/>;
This code does not return all values when the data is in multiple parameters:
http://127.0.0.1:8888/pub/live/index_en.html?lenya.usecase=search&language=en&language=de
I switched to:
String language = <xsp-request:get-parameter-values as="xml"
name="language" default="en"/>;
but that errors with:
"Type mismatch: cannot convert from void to String"
XSPRequestHelper.getParameterValues(objectModel, this.contentHandler,
"language", null, null);
I am assuming this is a BUG. Let me know if I missed something. I
will override with client-side JavaScript for now.
solprovider
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
For additional commands, e-mail: user-help@lenya.apache.org
Re: making search a real usecase
Posted by so...@gmail.com.
On 4/16/05, solprovider@gmail.com <so...@gmail.com> wrote:
> On 4/15/05, Gregor J. Rothfuss <gr...@apache.org> wrote:
> > solprovider@gmail.com wrote:
> > > There is no point in fixing:
> > > - build\lenya\webapp\lucene.xmap
> > > because the standard URL for Search does not contain the language
> > > information, so {page-envelope:document-language} is always empty. All
> > > Search pages must be in the browser language. (I am almost finished
> > > with a rewrite of Publication Search fixing this and many other
> > > issues. Stay tuned.)
> > are you going to make the lucene search a real usecase? i started with
> > this on trunk using the usecase framework
>
> My entry point for this functionality is adding (a revised version of)
> lucene.xmap to the {pub}/lenya directory. The fallback from
> global-sitemap.xmap works fine.
> solprovider
I think I just changed my mind. I finished the backend search filters
and started the frontend and remembered how awful it is to call xsl
from {pub}/xslt from a non-standard URL, such as
/pub/search-live/lucene rather than /pub/live/zzzz_en.html. Graphics
and many links are destroyed, and it is difficult to get language
information. The new code allows multiple languages for search
results without remembering which to use for the GUI. Implementing a
usecase would solve these issues.
---
I hardcoded the configuration of protected sections into
search-and-results.xsp. We can pull it from a cached list later (see
below).
I used groups rather than roles. "groups" are easy to get from
Identity. "roles" cannot be used for protected sections as long as
"world" inherits the "visit" role for everything.. (See my post at
Apr 11, 2005 4:56 PM for more info.)
The configuration for my implementation requires:
UrlStart, group, group, group
such as:
/employee, employee
/stuff/membersonly, member, admin
It should be easy to create this list for all sections from the
{pub}/config/ac/policies (and cache it) once role policies are
improved.
solprovider
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
For additional commands, e-mail: user-help@lenya.apache.org
Re: making search a real usecase
Posted by so...@gmail.com.
On 4/15/05, Gregor J. Rothfuss <gr...@apache.org> wrote:
> solprovider@gmail.com wrote:
> > There is no point in fixing:
> > - build\lenya\webapp\lucene.xmap
> > because the standard URL for Search does not contain the language
> > information, so {page-envelope:document-language} is always empty. All
> > Search pages must be in the browser language. (I am almost finished
> > with a rewrite of Publication Search fixing this and many other
> > issues. Stay tuned.)
> are you going to make the lucene search a real usecase? i started with
> this on trunk using the usecase framework
My entry point for this functionality is adding (a revised version of)
lucene.xmap to the {pub}/lenya directory. The fallback from
global-sitemap.xmap works fine.
Off-topic: I created {pub}\usecase-session.xmap. I was new to Lenya,
and could not figure out how to override the "login" usecase. It
seemed to be hardcoded into the webapp\sitemap.xmap with no fallback.
Is there a good method for overriding the login usecase?
solprovider
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
For additional commands, e-mail: user-help@lenya.apache.org
making search a real usecase
Posted by "Gregor J. Rothfuss" <gr...@apache.org>.
solprovider@gmail.com wrote:
> There is no point in fixing:
> - build\lenya\webapp\lucene.xmap
> because the standard URL for Search does not contain the language
> information, so {page-envelope:document-language} is always empty. All
> Search pages must be in the browser language. (I am almost finished
> with a rewrite of Publication Search fixing this and many other
> issues. Stay tuned.)
are you going to make the lucene search a real usecase? i started with
this on trunk using the usecase framework
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
For additional commands, e-mail: user-help@lenya.apache.org