commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Cooper <mfncoo...@gmail.com>
Subject Re: Proposal for a new Commons personalization package
Date Thu, 06 Jan 2005 18:26:00 GMT
On Thu, 6 Jan 2005 10:09:54 -0800 (PST), fzlists@omnytex.com
<fzlists@omnytex.com> wrote:
> I've been lurkingly (a new word?!?) following this thread with some interest because
an application I built last year required a fairly robust customization component that had
to work much like security does in Windows (i.e., users assigned to groups get certain rights,
but then those rights can be overwritten at the user levl, etc).
> 
> Martin, my perception of the Preferences API is that it is meant to be a more robust
replacement for Property files.  Assuming that perception is correct, I could see kind of
shoehorning something like Daniel's customization approach in using that API, but I'm not
sure it would be a good fit.
> 

In response to Craig's mention of the Preferences API earlier in this
thread, Daniel said:

"The rules presented in the proposal make personalization decisions using
both user data and external rule configuration parameters. Both types of
data can be stored and accessed using the Preferences API, so I think this
is a great idea."

So, since he said already that it's a great idea, I was simply
pointing out that I believe it works in all of the environments he
cares about, at which point it seems to me that we're done, and don't
need a new API / component for this.

--
Martin Cooper


> I too caught that reliance on the servlet API in Daniel's article, but I guess I made
an assumption, even though it wasn't stated in the proposal, that that requirement would be
removed.  I assumed it was done like that just for the article and he had refined his thinking
now to the point where it wasn't required (would have been nice if it was stated in the proposal,
I agree, but it seemed clear that was the intent from his subsequent posts).
> 
> I tend to agree I think that such a project doesn't really fit in what Commons are. 
I think of Commons as being relatively small components, more or less just collections of
individual functions grouped into broad categories.  I'm not quite sure this fits that mold.
 That being said, I do believe Daniel's stated goals have a lot of merit.  I wouldn't mind
being involved with it, but I think I would disagree with some of the initial direction.
> 
> One of my primary concerns is that any customization engine have the ability for multiple
levels a user can be placed in to determine it's effective "rights" at the end, with each
lower level able to override the higher level.  This again is like Windows security (and I
guess Unix security too, I'm frankly not as familiar as I'd like to be with that)... If I'm
in an Admin group, I may have write access to the C:\ drive, but that access can be changed
to read-only on a per-user basis for instance.
> 
> I'd also be weary of any approach that wasn't abstract enough to not require taglibs,
for two reasons... one, just like needing an HttpServletRequest, it shouldn't be tied to the
concept of a webapp, and two, I tend to shy away from taglibs wherever possible.  I shouldn't
be FORCED to have to use them is my point.
> 
> I also wouldn't be in favor of the "rule engine" being anything other than declarative.
 I admit I just quickly skimmed the article, but it seemed like some code was required at
the core of it all, even if a trivial amount.  I would personally want to take this in a direction
of being able to do everything from a single config file, even if that meant inventing a whole
rule language (and that doesn't seem like it would be necassery anyway).
> 
> My solution for instance, while certainly not as grandiose as what Daniel proposes, boiled
down in essence to a method that calculated effective rights based on a user's group and individual
rights, and then a single method that you called to determine whether they had a given right
or not.  So, for instance, maybe one of the rights is named "CanSeeAccountAdminScreen".  In
a JSP, you would just do:
> 
> <%if(userRights.hasRight("CanSeeAccountAdminScreen")){%>
> <!--Whatever HTML applies to that right-->
> <%}%>
> 
> Again, I prefer not using taglibs, but clearly you could make a custom tag for that for
those who like that approach better.  More importantly though, this isn't tied to a web application
at all.
> 
> Now, in Daniel's proposal, he's talking about more dynamic rules really than this.  But,
I could see a version of my hasRights() method that, using Daniel's shopping cart example,
would instead look up the parameter as a key in a config file, which would be the rule in
some rule language, be it something custom, maybe regular expressions, whatever (maybe some
scripting language?  I'd love to be able to write my rules in Javascript for example!), evaluate
it and return true or false.
> 
> Just some thoughts anyway.  As I said, I do have some interest in this, so Daniel if
you'd like some help, feel free to contact me.  Even if was just debating approaches in the
beginning, that might be of value to you.
> 
> --
> Frank W. Zammetti
> Founder and Chief Software Architect
> Omnytex Technologies
> http://www.omnytex.com
> 
> On Thu, January 6, 2005 12:40 pm, Martin Cooper said:
> > On Thu, 6 Jan 2005 10:20:02 -0500, daniel.vlad@highmark.com
> > <daniel.vlad@highmark.com> wrote:
> >>
> >>
> >> I just wanted to point out that these personalization components can be
> >> used for non web applications as well. There is no technology out there
> >> to
> >> personalize Swing clients, applets, non-visual Java clients, wireless
> >> applications, in addition to Web applications.
> >
> > Um, in which of these environments does the JDK Preferences API not work?
> >
> >> Not all applications are portals, in fact the opposite is probably true:
> >> only a minority of the applications being built today are portals. So,
> >> why
> >> restricting the use of personalization to portals only?
> >> That is why I believe that these components would be a good fit for
> >> Jakarta
> >> Commons.
> >
> > The code in your JDJ article is tied to the Servlet API. (The
> > isRuleSatisfied() method requires an HttpServletRequest parameter.) In
> > section 2 of your proposal, you did not mention removing such a
> > dependency as part of the planned enhancements.
> >
> > Aside from the fact that I don't personally believe we need such a
> > component in Commons, such a dependency would have to be removed for
> > this to be useful.
> >
> > --
> > Martin Cooper
> >
> >
> >> Thanks,
> >> Daniel H. Vlad
> >>
> >>             "Stephen
> >>             Colebourne"
> >>             <scolebourne@btop
> >> To
> >>             enworld.com>              "Jakarta Commons Developers List"
> >>                                       <commons-dev@jakarta.apache.org>,
> >>             01/05/2005 04:43          craigmcc@apache.org
> >>             PM
> >> cc
> >>
> >>                                                                   Subject
> >>             Please respond to         Re: Proposal for a new Commons
> >>             "Jakarta Commons          personalization package
> >>             Developers List"
> >>             <commons-dev@jaka
> >>              rta.apache.org>
> >>
> >> I would say that on balance this doesn't strike me as a commons
> >> component.
> >> Commons components should be small and isolated in scope. This proposal
> >> covers a specific file format and forces a use of tag libraries.
> >>
> >> I can see various possibilities for it:
> >> - Host at sourceforge
> >> - Try Jakarta Taglibs project - by focussing on the taglibs aspect, and
> >> potentially reusing other tags there, you may have more success
> >> - Try to build a community focussed on small interoperating parts
> >> commonly
> >> used in web applications, eg. by adding a logon component, a user
> >> management
> >> component
> >>
> >> Stephen
> >>
> >> ----- Original Message -----
> >> From: "Craig McClanahan" <craigmcc@gmail.com>
> >> >A couple of comments:
> >> >
> >> > * You might want to add to the proposal an answer to the
> >> >  likely most frequently asked question -- how does your
> >> >  approach compare/contrast/deal with the preferences
> >> >  APIs in JDK 1.4 (the java.util.prefs package)?
> >> >
> >> > * Is there anyone other than yourself who has expressed
> >> >  interest in working on this?  Packages with a single
> >> >  developer tend to have more problems attracting a
> >> >  community.  (And yes, this is definitely a "chicken
> >> >  and egg" sort of problem :-).
> >> >
> >> > Craig
> >> >
> >> > On Wed, 5 Jan 2005 11:52:18 -0500, daniel.vlad@highmark.com
> >> > <daniel.vlad@highmark.com> wrote:
> >> >>
> >> >>
> >> >> Hi,
> >> >>
> >> >> I recently authored an article for Java Developer's Journal where I
> >> >> describe a set of reusable components for web application
> >> >> personalization.
> >> >> I found these components to be very useful, and I thought it will be
> >> >> beneficial to create a new Jakarta Commons package for
> >> personalization
> >> >> components. The design and the code presented in the article can be
> >> >> enhanced to add functionality and make these components more
> >> powerful.
> >> >> Please take a look at the enclosed proposal and let me know what you
> >> >> think.
> >> >> I added a link to the JDJ article (Section (2) of the proposal) for
> >> your
> >> >> reference.
> >> >>
> >> >> Regards,
> >> >> Daniel Vlad
> >> >>
> >> >> Proposal for a new Commons Personalization package
> >> >>
> >> >> (0)  rationale
> >> >>
> >> >> Personalization is a major requirement for many web applications, yet
> >> >> most
> >> >> developers still implement these requirements by intermixing
> >> >> personalization logic with application code and even hard-coding
> >> >> personalization requirements directly in JSP.
> >> >> Most of the personalization solutions in the industry target Portlet
> >> >> development, and they are not appropriate for standalone web
> >> >> applications.
> >> >> A set of lightweight, framework-independent, reusable personalization
> >> >> components can provide significant benefits to application
> >> development:
> >> >> -  decouple personalization-related code from the rest of the
> >> >> application,
> >> >> thus simplifying the application maintenance.
> >> >> -  centralize the management of the personalization rules, ensuring
> >> >> application consistency.
> >> >> -  simplify web application development by shifting the complex task
> >> of
> >> >> web
> >> >> application personalization from Java developers to Web page authors.
> >> >> -  improve the performance of the application by caching the outcomes
> >> of
> >> >> the personalization decisions.
> >> >>
> >> >> (1)  scope of the package
> >> >>
> >> >> The package will create a set of reusable components to decouple
> >> >> personalization rules from the rest of the application logic and to
> >> >> centralize the management of these rules.
> >> >> Personalization rules will be defined and configured in an XML
> >> >> configuration file. An application will invoke these components
> >> either
> >> >> programmatically or through JSP tags.
> >> >> Web pages will be personalized by using custom JSP tags that evaluate
> >> >> personalization rules and decide what personalized content to be
> >> >> displayed
> >> >> to various users.
> >> >>
> >> >> (1.5)  interaction with other packages
> >> >>
> >> >> The package will use the following external packages:
> >> >> Commons Digester - to parse the personalization XML file
> >> >> Commons Logging - for logging
> >> >>
> >> >> (2)  identify the initial source for the package
> >> >>
> >> >> The initial codebase will be contributed by Daniel H. Vlad, and it
is
> >> >> based
> >> >> on the article "Personalize Your Web Applications", authored by
> >> Daniel
> >> >> and
> >> >> published as a Cover Story in Java Developer's Journal, December
> >> 2004,
> >> >> pages 34-40.
> >> >>
> >> >> Article URL: http://www.sys-con.com/story/?storyid=47357&DE=1
> >> >> Pdf download: http://pdf.sys-con.com/Java/JDJDecember2004.pdf
> >> >>
> >> >> The code base from the JDJ article will be re-designed and enhanced
> >> to:
> >> >> -  add content rules, rules that dynamically decide the content that
> >> >> should
> >> >> be displayed to users. This can be accomplished, for example, by
> >> >> categorizing users in groups using grouping criteria and mapping
> >> these
> >> >> user
> >> >> groups on content items using an XML mapping file.
> >> >> -  add caching to improve performance.
> >> >>
> >> >> (2.1)  identify the base name for the package
> >> >> org.apache.commons.personalization
> >> >> (2.2)  identify the coding conventions for this package
> >> >> Sun coding conventions
> >> >>
> >> >> (3)  identify any Jakarta-Commons resources to be created
> >> >> (3.1)  mailing list
> >> >> Until traffic justifies, the package will use the Jakarta-Commons
> >> list
> >> >> for
> >> >> communications.
> >> >> (3.2)  CVS repositories
> >> >> For the time being, the package will use a root branch of the
> >> >> Jakarta-Commons CVS.
> >> >> (3.3)  Bugzilla
> >> >> The package should be listed as a component of under the
> >> Jakarta-Commons
> >> >> Bugzilla entry.
> >> >>
> >> >> (4)  identify the initial set of committers to be listed in the
> >> Status
> >> >> File.
> >> >> Daniel H. Vlad
> >> >> other committers
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> >> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >> >
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> >> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> >> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >>
> >>
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
> >
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 
>

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message