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 2005/04/21 08:52:07 UTC
Re: making search a real usecase
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 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.
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 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