On Thu, 6 Jan 2005 10:09:54 -0800 (PST), [EMAIL PROTECTED]
<[EMAIL PROTECTED]> 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, [EMAIL PROTECTED]
> > <[EMAIL PROTECTED]> 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"
> >> <[EMAIL PROTECTED]
> >> To
> >> enworld.com> "Jakarta Commons Developers List"
> >> <[email protected]>,
> >> 01/05/2005 04:43 [EMAIL PROTECTED]
> >> PM
> >> cc
> >>
> >> Subject
> >> Please respond to Re: Proposal for a new Commons
> >> "Jakarta Commons personalization package
> >> Developers List"
> >> <[EMAIL PROTECTED]
> >> 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" <[EMAIL PROTECTED]>
> >> >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, [EMAIL PROTECTED]
> >> > <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
> >> > For additional commands, e-mail: [EMAIL PROTECTED]
> >> >
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> For additional commands, e-mail: [EMAIL PROTECTED]
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> For additional commands, e-mail: [EMAIL PROTECTED]
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
