You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@commons.apache.org by da...@highmark.com on 2005/01/05 17:52:18 UTC

Proposal for a new Commons personalization package




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

Re: Proposal for a new Commons personalization package

Posted by Karan Malhi <ka...@gmail.com>.

Hi Daniel,

I would like to be involved with this project. 
Also portals would require a container to be involved, so  i agree
with you,  personalization should not be restricted to portals or web
applications.

My question is, is there something already available where i can use
personalization in my application and not use portals container. This
is because, not all projects need portals, but most of them need
personalization.  If something like this is not available already,
then i would definitely like this personalization project to happen.

Regards

Karan Singh


On Thu, 6 Jan 2005 10:20:02 -0500, daniel.vlad@highmark.com
<da...@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.
> 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.
> 
> Thanks,
> Daniel H. Vlad
> 
>              "Stephen
>              Colebourne"
>              <scolebourne@btop                                          To
>              enworld.com>              "Jakarta Commons Developers List"
>                                        <co...@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" <cr...@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
> > <da...@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
> 
> 


-- 
Karan Malhi

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

Re: Proposal for a new Commons personalization package

Posted by da...@highmark.com.




Stephen,

I realized from the beginning that not being a committer lowers the
chances for acceptance. However, I was hoping that the proposal will be
judged for its value, without prejudice. If you or another existing
committer is willing to support this project I can enter his name in the
committers section. If required, I can remove mine. I can contribute as a
simple developer without committing rights.

Thanks,
Daniel Vlad





"Stephen Colebourne" <sc...@btopenworld.com> on 01/10/2005 06:44:47
PM

Please respond to "Jakarta Commons Developers List"
       <co...@jakarta.apache.org>



To:    "Jakarta Commons Developers List" <co...@jakarta.apache.org>,
       fzlists@omnytex.com
cc:
Subject:    Re: Proposal for a new Commons personalization package

Commons is a weird place in that it is a bit like a club sometimes. You
generally need to already be an Apache/Jakarta committer somewhere (not
necessarily commons) to get a new project started.

SF is often the solution to this, although it has the disadvantage of less
publicity and immediate feedback. Even if its just to work out the initial
codebase, and then to try to get some key people from jakarta interested
(eg
portals people).

Stephen

----- Original Message ----- >
>  Hey, even if they don't accept it as a Commons project, just open it up
> on SF.  Might almost be better there to be honest.  If nothing else you'd

> be in complete control of it yourself, no politics to worry about, aside
> from those you create yourself of course :)
>
> Have you spent any time putting together some diagrams to try and explain

> what you envision?  That certainly couldn't hurt get the "big picture"
> across.  A picture is worth a thousand words, and all that jazz :)
>
> --
> Frank W. Zammetti
> Founder and Chief Software Architect
> Omnytex Technologies
> http://www.omnytex.com
>
> daniel.vlad@highmark.com wrote:
>>
>>
>>
>> I have updated the proposal (see below) to include the suggestions
>> received
>> and to detail out some of the ambiguous parts of the original proposal.
>> It might be a good idea to rename the package to Personalization Rules.
>> It
>> better spells out what we are trying to accomplish, and at the same time

>> it
>> will probably fit better under the Commons Project.
>> I believe that the Commons Project will be a good fit, at least
>> initially.
>> Later, we can always decide to move it somewhere else if necessary, but
I
>> am open to suggestions.
>>
>> Let me know if you have any additional questions or comments in regard
to
>> this proposal. I wanted to thank you for your very valuable feedback and
>> ideas, and I hope you will decide to support it.
>>
>> Regards,
>> Daniel Vlad
>>
>>
>> Proposal for a new Commons Personalization Rules package
>>
>> (0)  rationale
>>
>> Personalization is a major requirement for all types of Java
applications
>> (web, portal, Swing, applets, stand-alone clients, wireless
applications,
>> etc.)
>> There is no industry standard solution for personalizing Java
>> applications
>> in general. It is common for developers to implement personalization
>> requirements by intermixing personalization logic with application code
>> or
>> even hard-coding personalization requirements directly in JSP.
>>
>> Vendor personalization solutions target only portal development and they
>> are restricted to applications running inside a portlet container. As a
>> result, portal personalization solutions are not appropriate for
>> stand-alone web applications or plain Java applications.
>>
>> A set of lightweight, technology-independent, reusable personalization
>> components can provide significant benefits to application development:
>> -  encapsulate personalization logic code and decouple this code from
the
>> rest of the application, thus simplifying application development and
>> maintenance.
>> -  centralize the management of the personalization rules, ensuring
>> application consistency.
>> -  improve the performance of the application by caching the outcomes of
>> the personalization decisions.
>>
>> JSR 168 (Portlet) specification does not define a common approach for
>> encapsulating personalization logic and making personalization
decisions.
>> The specification provides per-user portlet preferences and allows
>> vendors
>> to plug-in their own personalization engines to make decisions based on
>> these preferences. Thus, a set of components to manage personalization
>> decisions will even be beneficial to portlet developers.
>>
>> (1)  scope of the package
>>
>> The package will create a set of reusable components to encapsulate the
>> personalization logic in the application and to decouple these rules
from
>> the rest of the application.
>>
>> (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
>>
>> Initial Design:
>>
>> The main abstraction in this package is a PersonalizationRule. A rule
>> encapsulates logic needed to make a personalization decision. In order
to
>> make a decision, a rule needs user data and preferences, as well as rule
>> configuration parameters.
>>
>> User data and preferences:
>> - user preferences will be accessed using the Preferences API.
>> - user data will be fed to a Rule through an interface that can be
>> implemented to hold data coming from any external user repository, such
>> as
>> LDAP. In particular this design pattern should allow a rule to be
>> configured using the Portlet Preferences, to make personalization
>> components compatible with JSR 168 API.
>> - the design from the JDJ article should be updated to remove the
>> dependency on the Servlet API and to make the personalization components
>> technology-independent.
>>
>> Rule configuration:
>> - rules will be declared and configured in an XML file. For flexibility,
>> the configuration file should allow each rule to specify the
>> implementation
>> class declaratively.
>>
>> Additional features:
>> - composite rules, or rules created by aggregating other rules using
>> Boolean operators (AND, OR, etc.). Composite rules should be declared in
>> XML format. Example: If user is a Manager AND belongs to Department X.
>> - a set of commonly used rules should be provided with the code
>> distribution. For example, rules based on security roles (see JDJ
article
>> example), rules that check if a user attribute/preference matches some
>> data, etc.
>> - 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.
>>
>> The initial design will be updated/enhanced/improved as necessary.
>>
>> (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 TBD
>>
>> Initial group of developers:
>> Daniel H. Vlad
>> Karan Malhi
>> Frank W. Zammetti
>>
>>
>>
>> ---------------------------------------------------------------------
>> 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

Re: Proposal for a new Commons personalization package

Posted by Stephen Colebourne <sc...@btopenworld.com>.

Commons is a weird place in that it is a bit like a club sometimes. You 
generally need to already be an Apache/Jakarta committer somewhere (not 
necessarily commons) to get a new project started.

SF is often the solution to this, although it has the disadvantage of less 
publicity and immediate feedback. Even if its just to work out the initial 
codebase, and then to try to get some key people from jakarta interested (eg 
portals people).

Stephen

----- Original Message ----- >
>  Hey, even if they don't accept it as a Commons project, just open it up 
> on SF.  Might almost be better there to be honest.  If nothing else you'd 
> be in complete control of it yourself, no politics to worry about, aside 
> from those you create yourself of course :)
>
> Have you spent any time putting together some diagrams to try and explain 
> what you envision?  That certainly couldn't hurt get the "big picture" 
> across.  A picture is worth a thousand words, and all that jazz :)
>
> -- 
> Frank W. Zammetti
> Founder and Chief Software Architect
> Omnytex Technologies
> http://www.omnytex.com
>
> daniel.vlad@highmark.com wrote:
>>
>>
>>
>> I have updated the proposal (see below) to include the suggestions 
>> received
>> and to detail out some of the ambiguous parts of the original proposal.
>> It might be a good idea to rename the package to Personalization Rules. 
>> It
>> better spells out what we are trying to accomplish, and at the same time 
>> it
>> will probably fit better under the Commons Project.
>> I believe that the Commons Project will be a good fit, at least 
>> initially.
>> Later, we can always decide to move it somewhere else if necessary, but I
>> am open to suggestions.
>>
>> Let me know if you have any additional questions or comments in regard to
>> this proposal. I wanted to thank you for your very valuable feedback and
>> ideas, and I hope you will decide to support it.
>>
>> Regards,
>> Daniel Vlad
>>
>>
>> Proposal for a new Commons Personalization Rules package
>>
>> (0)  rationale
>>
>> Personalization is a major requirement for all types of Java applications
>> (web, portal, Swing, applets, stand-alone clients, wireless applications,
>> etc.)
>> There is no industry standard solution for personalizing Java 
>> applications
>> in general. It is common for developers to implement personalization
>> requirements by intermixing personalization logic with application code 
>> or
>> even hard-coding personalization requirements directly in JSP.
>>
>> Vendor personalization solutions target only portal development and they
>> are restricted to applications running inside a portlet container. As a
>> result, portal personalization solutions are not appropriate for
>> stand-alone web applications or plain Java applications.
>>
>> A set of lightweight, technology-independent, reusable personalization
>> components can provide significant benefits to application development:
>> -  encapsulate personalization logic code and decouple this code from the
>> rest of the application, thus simplifying application development and
>> maintenance.
>> -  centralize the management of the personalization rules, ensuring
>> application consistency.
>> -  improve the performance of the application by caching the outcomes of
>> the personalization decisions.
>>
>> JSR 168 (Portlet) specification does not define a common approach for
>> encapsulating personalization logic and making personalization decisions.
>> The specification provides per-user portlet preferences and allows 
>> vendors
>> to plug-in their own personalization engines to make decisions based on
>> these preferences. Thus, a set of components to manage personalization
>> decisions will even be beneficial to portlet developers.
>>
>> (1)  scope of the package
>>
>> The package will create a set of reusable components to encapsulate the
>> personalization logic in the application and to decouple these rules from
>> the rest of the application.
>>
>> (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
>>
>> Initial Design:
>>
>> The main abstraction in this package is a PersonalizationRule. A rule
>> encapsulates logic needed to make a personalization decision. In order to
>> make a decision, a rule needs user data and preferences, as well as rule
>> configuration parameters.
>>
>> User data and preferences:
>> - user preferences will be accessed using the Preferences API.
>> - user data will be fed to a Rule through an interface that can be
>> implemented to hold data coming from any external user repository, such 
>> as
>> LDAP. In particular this design pattern should allow a rule to be
>> configured using the Portlet Preferences, to make personalization
>> components compatible with JSR 168 API.
>> - the design from the JDJ article should be updated to remove the
>> dependency on the Servlet API and to make the personalization components
>> technology-independent.
>>
>> Rule configuration:
>> - rules will be declared and configured in an XML file. For flexibility,
>> the configuration file should allow each rule to specify the 
>> implementation
>> class declaratively.
>>
>> Additional features:
>> - composite rules, or rules created by aggregating other rules using
>> Boolean operators (AND, OR, etc.). Composite rules should be declared in
>> XML format. Example: If user is a Manager AND belongs to Department X.
>> - a set of commonly used rules should be provided with the code
>> distribution. For example, rules based on security roles (see JDJ article
>> example), rules that check if a user attribute/preference matches some
>> data, etc.
>> - 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.
>>
>> The initial design will be updated/enhanced/improved as necessary.
>>
>> (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 TBD
>>
>> Initial group of developers:
>> Daniel H. Vlad
>> Karan Malhi
>> Frank W. Zammetti
>>
>>
>>
>> ---------------------------------------------------------------------
>> 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

Re: Proposal for a new Commons personalization package

Posted by Karan Malhi <ka...@gmail.com>.

Even i feel that this proposal should be judged on value its going to
bring in to the Java community. I am pretty sure, if the committers
look at this proposal, then we will definitely get something started.
I think the committers should come forward and add some more thoughts
to it. Looking at the kind of experience the committers have and the
wonderful projects they have given to the java community, their
experience in shaping this proposal is also very important. Is there
something else which the committers need for this project to be part
of commons?, if there is , then please give your valuable thoughts to
this proposal.

Regards

Karan Malhi


On Mon, 10 Jan 2005 20:11:10 -0500, Frank W. Zammetti
<fz...@omnytex.com> wrote:
> Daniel,
> 
> Uhh... umm... what?!?
> 
> I am sincerely confused why you would have found any of that offensive.
>   The only thing I even *remotely* think could be is the politics
> comment, and that was followed by a smiley.  Even if it wasn't, I
> sincerely doubt that would be offensive to anyone, certainly I don't
> think it should be.
> 
> I really don't see where anything I wrote would be considered
> inappropriate by anyone, and I'd certainly like the opportunity to
> defend myself if anyone disagrees with that statement.
> 
> About my name on the list, I just want to clarify that comment... I was
> only surprised because while I said I'd be willing to help as much as
> time allows, I didn't see a reply from you (I could have missed it,
> sorry if that's the case), so I didn't anticipate being listed.  That's
> all, nothing sinister there.
> 
> --
> Frank W. Zammetti
> Founder and Chief Software Architect
> Omnytex Technologies
> http://www.omnytex.com
> 
> daniel.vlad@highmark.com wrote:
> >
> >
> >
> > Frank,
> >
> > I do not agree with your comments, and I don't think they are appropriate.
> > I can even see why this list will find them offensive. I added your name to
> > the initial list of developers (not committers) because you asked to, but
> > your comments can jeopardize the entire proposal.
> >
> > Daniel Vlad
> >
> >
> >
> >
> >
> > "Frank W. Zammetti" <fz...@omnytex.com> on 01/10/2005 06:27:33 PM
> >
> > Please respond to "Jakarta Commons Developers List"
> >        <co...@jakarta.apache.org>; Please respond to
> >        fzlists@omnytex.com
> >
> >
> >
> > To:    "Jakarta Commons Developers List" <co...@jakarta.apache.org>
> > cc:
> > Subject:    Re: Proposal for a new Commons personalization package
> >
> > Wow, my name's on it!  Didn't actually expect that :)
> >
> > Hey, even if they don't accept it as a Commons project, just open it up
> > on SF.  Might almost be better there to be honest.  If nothing else
> > you'd be in complete control of it yourself, no politics to worry about,
> > aside from those you create yourself of course :)
> >
> > Have you spent any time putting together some diagrams to try and
> > explain what you envision?  That certainly couldn't hurt get the "big
> > picture" across.  A picture is worth a thousand words, and all that jazz :)
> >
> > --
> > Frank W. Zammetti
> > Founder and Chief Software Architect
> > Omnytex Technologies
> > http://www.omnytex.com
> >
> > daniel.vlad@highmark.com wrote:
> >
> >>
> >>
> >>I have updated the proposal (see below) to include the suggestions
> >
> > received
> >
> >>and to detail out some of the ambiguous parts of the original proposal.
> >>It might be a good idea to rename the package to Personalization Rules.
> >
> > It
> >
> >>better spells out what we are trying to accomplish, and at the same time
> >
> > it
> >
> >>will probably fit better under the Commons Project.
> >>I believe that the Commons Project will be a good fit, at least
> >
> > initially.
> >
> >>Later, we can always decide to move it somewhere else if necessary, but I
> >>am open to suggestions.
> >>
> >>Let me know if you have any additional questions or comments in regard to
> >>this proposal. I wanted to thank you for your very valuable feedback and
> >>ideas, and I hope you will decide to support it.
> >>
> >>Regards,
> >>Daniel Vlad
> >>
> >>
> >>Proposal for a new Commons Personalization Rules package
> >>
> >>(0)  rationale
> >>
> >>Personalization is a major requirement for all types of Java applications
> >>(web, portal, Swing, applets, stand-alone clients, wireless applications,
> >>etc.)
> >>There is no industry standard solution for personalizing Java
> >
> > applications
> >
> >>in general. It is common for developers to implement personalization
> >>requirements by intermixing personalization logic with application code
> >
> > or
> >
> >>even hard-coding personalization requirements directly in JSP.
> >>
> >>Vendor personalization solutions target only portal development and they
> >>are restricted to applications running inside a portlet container. As a
> >>result, portal personalization solutions are not appropriate for
> >>stand-alone web applications or plain Java applications.
> >>
> >>A set of lightweight, technology-independent, reusable personalization
> >>components can provide significant benefits to application development:
> >>-  encapsulate personalization logic code and decouple this code from the
> >>rest of the application, thus simplifying application development and
> >>maintenance.
> >>-  centralize the management of the personalization rules, ensuring
> >>application consistency.
> >>-  improve the performance of the application by caching the outcomes of
> >>the personalization decisions.
> >>
> >>JSR 168 (Portlet) specification does not define a common approach for
> >>encapsulating personalization logic and making personalization decisions.
> >>The specification provides per-user portlet preferences and allows
> >
> > vendors
> >
> >>to plug-in their own personalization engines to make decisions based on
> >>these preferences. Thus, a set of components to manage personalization
> >>decisions will even be beneficial to portlet developers.
> >>
> >>(1)  scope of the package
> >>
> >>The package will create a set of reusable components to encapsulate the
> >>personalization logic in the application and to decouple these rules from
> >>the rest of the application.
> >>
> >>(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
> >>
> >>Initial Design:
> >>
> >>The main abstraction in this package is a PersonalizationRule. A rule
> >>encapsulates logic needed to make a personalization decision. In order to
> >>make a decision, a rule needs user data and preferences, as well as rule
> >>configuration parameters.
> >>
> >>User data and preferences:
> >>- user preferences will be accessed using the Preferences API.
> >>- user data will be fed to a Rule through an interface that can be
> >>implemented to hold data coming from any external user repository, such
> >
> > as
> >
> >>LDAP. In particular this design pattern should allow a rule to be
> >>configured using the Portlet Preferences, to make personalization
> >>components compatible with JSR 168 API.
> >>- the design from the JDJ article should be updated to remove the
> >>dependency on the Servlet API and to make the personalization components
> >>technology-independent.
> >>
> >>Rule configuration:
> >>- rules will be declared and configured in an XML file. For flexibility,
> >>the configuration file should allow each rule to specify the
> >
> > implementation
> >
> >>class declaratively.
> >>
> >>Additional features:
> >>- composite rules, or rules created by aggregating other rules using
> >>Boolean operators (AND, OR, etc.). Composite rules should be declared in
> >>XML format. Example: If user is a Manager AND belongs to Department X.
> >>- a set of commonly used rules should be provided with the code
> >>distribution. For example, rules based on security roles (see JDJ article
> >>example), rules that check if a user attribute/preference matches some
> >>data, etc.
> >>- 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.
> >>
> >>The initial design will be updated/enhanced/improved as necessary.
> >>
> >>(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 TBD
> >>
> >>Initial group of developers:
> >>Daniel H. Vlad
> >>Karan Malhi
> >>Frank W. Zammetti
> >>
> >>
> >>
> >>---------------------------------------------------------------------
> >>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
> 
> 


-- 
Karan Malhi

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

Re: Proposal for a new Commons personalization package

Posted by "Frank W. Zammetti" <fz...@omnytex.com>.

Daniel,

Uhh... umm... what?!?

I am sincerely confused why you would have found any of that offensive. 
  The only thing I even *remotely* think could be is the politics 
comment, and that was followed by a smiley.  Even if it wasn't, I 
sincerely doubt that would be offensive to anyone, certainly I don't 
think it should be.

I really don't see where anything I wrote would be considered 
inappropriate by anyone, and I'd certainly like the opportunity to 
defend myself if anyone disagrees with that statement.

About my name on the list, I just want to clarify that comment... I was 
only surprised because while I said I'd be willing to help as much as 
time allows, I didn't see a reply from you (I could have missed it, 
sorry if that's the case), so I didn't anticipate being listed.  That's 
all, nothing sinister there.

-- 
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com


daniel.vlad@highmark.com wrote:
> 
> 
> 
> Frank,
> 
> I do not agree with your comments, and I don't think they are appropriate.
> I can even see why this list will find them offensive. I added your name to
> the initial list of developers (not committers) because you asked to, but
> your comments can jeopardize the entire proposal.
> 
> Daniel Vlad
> 
> 
> 
> 
> 
> "Frank W. Zammetti" <fz...@omnytex.com> on 01/10/2005 06:27:33 PM
> 
> Please respond to "Jakarta Commons Developers List"
>        <co...@jakarta.apache.org>; Please respond to
>        fzlists@omnytex.com
> 
> 
> 
> To:    "Jakarta Commons Developers List" <co...@jakarta.apache.org>
> cc:
> Subject:    Re: Proposal for a new Commons personalization package
> 
> Wow, my name's on it!  Didn't actually expect that :)
> 
> Hey, even if they don't accept it as a Commons project, just open it up
> on SF.  Might almost be better there to be honest.  If nothing else
> you'd be in complete control of it yourself, no politics to worry about,
> aside from those you create yourself of course :)
> 
> Have you spent any time putting together some diagrams to try and
> explain what you envision?  That certainly couldn't hurt get the "big
> picture" across.  A picture is worth a thousand words, and all that jazz :)
> 
> --
> Frank W. Zammetti
> Founder and Chief Software Architect
> Omnytex Technologies
> http://www.omnytex.com
> 
> daniel.vlad@highmark.com wrote:
> 
>>
>>
>>I have updated the proposal (see below) to include the suggestions
> 
> received
> 
>>and to detail out some of the ambiguous parts of the original proposal.
>>It might be a good idea to rename the package to Personalization Rules.
> 
> It
> 
>>better spells out what we are trying to accomplish, and at the same time
> 
> it
> 
>>will probably fit better under the Commons Project.
>>I believe that the Commons Project will be a good fit, at least
> 
> initially.
> 
>>Later, we can always decide to move it somewhere else if necessary, but I
>>am open to suggestions.
>>
>>Let me know if you have any additional questions or comments in regard to
>>this proposal. I wanted to thank you for your very valuable feedback and
>>ideas, and I hope you will decide to support it.
>>
>>Regards,
>>Daniel Vlad
>>
>>
>>Proposal for a new Commons Personalization Rules package
>>
>>(0)  rationale
>>
>>Personalization is a major requirement for all types of Java applications
>>(web, portal, Swing, applets, stand-alone clients, wireless applications,
>>etc.)
>>There is no industry standard solution for personalizing Java
> 
> applications
> 
>>in general. It is common for developers to implement personalization
>>requirements by intermixing personalization logic with application code
> 
> or
> 
>>even hard-coding personalization requirements directly in JSP.
>>
>>Vendor personalization solutions target only portal development and they
>>are restricted to applications running inside a portlet container. As a
>>result, portal personalization solutions are not appropriate for
>>stand-alone web applications or plain Java applications.
>>
>>A set of lightweight, technology-independent, reusable personalization
>>components can provide significant benefits to application development:
>>-  encapsulate personalization logic code and decouple this code from the
>>rest of the application, thus simplifying application development and
>>maintenance.
>>-  centralize the management of the personalization rules, ensuring
>>application consistency.
>>-  improve the performance of the application by caching the outcomes of
>>the personalization decisions.
>>
>>JSR 168 (Portlet) specification does not define a common approach for
>>encapsulating personalization logic and making personalization decisions.
>>The specification provides per-user portlet preferences and allows
> 
> vendors
> 
>>to plug-in their own personalization engines to make decisions based on
>>these preferences. Thus, a set of components to manage personalization
>>decisions will even be beneficial to portlet developers.
>>
>>(1)  scope of the package
>>
>>The package will create a set of reusable components to encapsulate the
>>personalization logic in the application and to decouple these rules from
>>the rest of the application.
>>
>>(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
>>
>>Initial Design:
>>
>>The main abstraction in this package is a PersonalizationRule. A rule
>>encapsulates logic needed to make a personalization decision. In order to
>>make a decision, a rule needs user data and preferences, as well as rule
>>configuration parameters.
>>
>>User data and preferences:
>>- user preferences will be accessed using the Preferences API.
>>- user data will be fed to a Rule through an interface that can be
>>implemented to hold data coming from any external user repository, such
> 
> as
> 
>>LDAP. In particular this design pattern should allow a rule to be
>>configured using the Portlet Preferences, to make personalization
>>components compatible with JSR 168 API.
>>- the design from the JDJ article should be updated to remove the
>>dependency on the Servlet API and to make the personalization components
>>technology-independent.
>>
>>Rule configuration:
>>- rules will be declared and configured in an XML file. For flexibility,
>>the configuration file should allow each rule to specify the
> 
> implementation
> 
>>class declaratively.
>>
>>Additional features:
>>- composite rules, or rules created by aggregating other rules using
>>Boolean operators (AND, OR, etc.). Composite rules should be declared in
>>XML format. Example: If user is a Manager AND belongs to Department X.
>>- a set of commonly used rules should be provided with the code
>>distribution. For example, rules based on security roles (see JDJ article
>>example), rules that check if a user attribute/preference matches some
>>data, etc.
>>- 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.
>>
>>The initial design will be updated/enhanced/improved as necessary.
>>
>>(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 TBD
>>
>>Initial group of developers:
>>Daniel H. Vlad
>>Karan Malhi
>>Frank W. Zammetti
>>
>>
>>
>>---------------------------------------------------------------------
>>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

Re: Proposal for a new Commons personalization package

Posted by da...@highmark.com.




Frank,

I do not agree with your comments, and I don't think they are appropriate.
I can even see why this list will find them offensive. I added your name to
the initial list of developers (not committers) because you asked to, but
your comments can jeopardize the entire proposal.

Daniel Vlad





"Frank W. Zammetti" <fz...@omnytex.com> on 01/10/2005 06:27:33 PM

Please respond to "Jakarta Commons Developers List"
       <co...@jakarta.apache.org>; Please respond to
       fzlists@omnytex.com



To:    "Jakarta Commons Developers List" <co...@jakarta.apache.org>
cc:
Subject:    Re: Proposal for a new Commons personalization package

Wow, my name's on it!  Didn't actually expect that :)

Hey, even if they don't accept it as a Commons project, just open it up
on SF.  Might almost be better there to be honest.  If nothing else
you'd be in complete control of it yourself, no politics to worry about,
aside from those you create yourself of course :)

Have you spent any time putting together some diagrams to try and
explain what you envision?  That certainly couldn't hurt get the "big
picture" across.  A picture is worth a thousand words, and all that jazz :)

--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com

daniel.vlad@highmark.com wrote:
>
>
>
> I have updated the proposal (see below) to include the suggestions
received
> and to detail out some of the ambiguous parts of the original proposal.
> It might be a good idea to rename the package to Personalization Rules.
It
> better spells out what we are trying to accomplish, and at the same time
it
> will probably fit better under the Commons Project.
> I believe that the Commons Project will be a good fit, at least
initially.
> Later, we can always decide to move it somewhere else if necessary, but I
> am open to suggestions.
>
> Let me know if you have any additional questions or comments in regard to
> this proposal. I wanted to thank you for your very valuable feedback and
> ideas, and I hope you will decide to support it.
>
> Regards,
> Daniel Vlad
>
>
> Proposal for a new Commons Personalization Rules package
>
> (0)  rationale
>
> Personalization is a major requirement for all types of Java applications
> (web, portal, Swing, applets, stand-alone clients, wireless applications,
> etc.)
> There is no industry standard solution for personalizing Java
applications
> in general. It is common for developers to implement personalization
> requirements by intermixing personalization logic with application code
or
> even hard-coding personalization requirements directly in JSP.
>
> Vendor personalization solutions target only portal development and they
> are restricted to applications running inside a portlet container. As a
> result, portal personalization solutions are not appropriate for
> stand-alone web applications or plain Java applications.
>
> A set of lightweight, technology-independent, reusable personalization
> components can provide significant benefits to application development:
> -  encapsulate personalization logic code and decouple this code from the
> rest of the application, thus simplifying application development and
> maintenance.
> -  centralize the management of the personalization rules, ensuring
> application consistency.
> -  improve the performance of the application by caching the outcomes of
> the personalization decisions.
>
> JSR 168 (Portlet) specification does not define a common approach for
> encapsulating personalization logic and making personalization decisions.
> The specification provides per-user portlet preferences and allows
vendors
> to plug-in their own personalization engines to make decisions based on
> these preferences. Thus, a set of components to manage personalization
> decisions will even be beneficial to portlet developers.
>
> (1)  scope of the package
>
> The package will create a set of reusable components to encapsulate the
> personalization logic in the application and to decouple these rules from
> the rest of the application.
>
> (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
>
> Initial Design:
>
> The main abstraction in this package is a PersonalizationRule. A rule
> encapsulates logic needed to make a personalization decision. In order to
> make a decision, a rule needs user data and preferences, as well as rule
> configuration parameters.
>
> User data and preferences:
> - user preferences will be accessed using the Preferences API.
> - user data will be fed to a Rule through an interface that can be
> implemented to hold data coming from any external user repository, such
as
> LDAP. In particular this design pattern should allow a rule to be
> configured using the Portlet Preferences, to make personalization
> components compatible with JSR 168 API.
> - the design from the JDJ article should be updated to remove the
> dependency on the Servlet API and to make the personalization components
> technology-independent.
>
> Rule configuration:
> - rules will be declared and configured in an XML file. For flexibility,
> the configuration file should allow each rule to specify the
implementation
> class declaratively.
>
> Additional features:
> - composite rules, or rules created by aggregating other rules using
> Boolean operators (AND, OR, etc.). Composite rules should be declared in
> XML format. Example: If user is a Manager AND belongs to Department X.
> - a set of commonly used rules should be provided with the code
> distribution. For example, rules based on security roles (see JDJ article
> example), rules that check if a user attribute/preference matches some
> data, etc.
> - 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.
>
> The initial design will be updated/enhanced/improved as necessary.
>
> (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 TBD
>
> Initial group of developers:
> Daniel H. Vlad
> Karan Malhi
> Frank W. Zammetti
>
>
>
> ---------------------------------------------------------------------
> 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

Re: Proposal for a new Commons personalization package

Posted by "Frank W. Zammetti" <fz...@omnytex.com>.

Wow, my name's on it!  Didn't actually expect that :)

Hey, even if they don't accept it as a Commons project, just open it up 
on SF.  Might almost be better there to be honest.  If nothing else 
you'd be in complete control of it yourself, no politics to worry about, 
aside from those you create yourself of course :)

Have you spent any time putting together some diagrams to try and 
explain what you envision?  That certainly couldn't hurt get the "big 
picture" across.  A picture is worth a thousand words, and all that jazz :)

-- 
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com

daniel.vlad@highmark.com wrote:
> 
> 
> 
> I have updated the proposal (see below) to include the suggestions received
> and to detail out some of the ambiguous parts of the original proposal.
> It might be a good idea to rename the package to Personalization Rules. It
> better spells out what we are trying to accomplish, and at the same time it
> will probably fit better under the Commons Project.
> I believe that the Commons Project will be a good fit, at least initially.
> Later, we can always decide to move it somewhere else if necessary, but I
> am open to suggestions.
> 
> Let me know if you have any additional questions or comments in regard to
> this proposal. I wanted to thank you for your very valuable feedback and
> ideas, and I hope you will decide to support it.
> 
> Regards,
> Daniel Vlad
> 
> 
> Proposal for a new Commons Personalization Rules package
> 
> (0)  rationale
> 
> Personalization is a major requirement for all types of Java applications
> (web, portal, Swing, applets, stand-alone clients, wireless applications,
> etc.)
> There is no industry standard solution for personalizing Java applications
> in general. It is common for developers to implement personalization
> requirements by intermixing personalization logic with application code or
> even hard-coding personalization requirements directly in JSP.
> 
> Vendor personalization solutions target only portal development and they
> are restricted to applications running inside a portlet container. As a
> result, portal personalization solutions are not appropriate for
> stand-alone web applications or plain Java applications.
> 
> A set of lightweight, technology-independent, reusable personalization
> components can provide significant benefits to application development:
> -  encapsulate personalization logic code and decouple this code from the
> rest of the application, thus simplifying application development and
> maintenance.
> -  centralize the management of the personalization rules, ensuring
> application consistency.
> -  improve the performance of the application by caching the outcomes of
> the personalization decisions.
> 
> JSR 168 (Portlet) specification does not define a common approach for
> encapsulating personalization logic and making personalization decisions.
> The specification provides per-user portlet preferences and allows vendors
> to plug-in their own personalization engines to make decisions based on
> these preferences. Thus, a set of components to manage personalization
> decisions will even be beneficial to portlet developers.
> 
> (1)  scope of the package
> 
> The package will create a set of reusable components to encapsulate the
> personalization logic in the application and to decouple these rules from
> the rest of the application.
> 
> (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
> 
> Initial Design:
> 
> The main abstraction in this package is a PersonalizationRule. A rule
> encapsulates logic needed to make a personalization decision. In order to
> make a decision, a rule needs user data and preferences, as well as rule
> configuration parameters.
> 
> User data and preferences:
> - user preferences will be accessed using the Preferences API.
> - user data will be fed to a Rule through an interface that can be
> implemented to hold data coming from any external user repository, such as
> LDAP. In particular this design pattern should allow a rule to be
> configured using the Portlet Preferences, to make personalization
> components compatible with JSR 168 API.
> - the design from the JDJ article should be updated to remove the
> dependency on the Servlet API and to make the personalization components
> technology-independent.
> 
> Rule configuration:
> - rules will be declared and configured in an XML file. For flexibility,
> the configuration file should allow each rule to specify the implementation
> class declaratively.
> 
> Additional features:
> - composite rules, or rules created by aggregating other rules using
> Boolean operators (AND, OR, etc.). Composite rules should be declared in
> XML format. Example: If user is a Manager AND belongs to Department X.
> - a set of commonly used rules should be provided with the code
> distribution. For example, rules based on security roles (see JDJ article
> example), rules that check if a user attribute/preference matches some
> data, etc.
> - 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.
> 
> The initial design will be updated/enhanced/improved as necessary.
> 
> (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 TBD
> 
> Initial group of developers:
> Daniel H. Vlad
> Karan Malhi
> Frank W. Zammetti
> 
> 
> 
> ---------------------------------------------------------------------
> 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

Re: Proposal for a new Commons personalization package

Posted by da...@highmark.com.




I have updated the proposal (see below) to include the suggestions received
and to detail out some of the ambiguous parts of the original proposal.
It might be a good idea to rename the package to Personalization Rules. It
better spells out what we are trying to accomplish, and at the same time it
will probably fit better under the Commons Project.
I believe that the Commons Project will be a good fit, at least initially.
Later, we can always decide to move it somewhere else if necessary, but I
am open to suggestions.

Let me know if you have any additional questions or comments in regard to
this proposal. I wanted to thank you for your very valuable feedback and
ideas, and I hope you will decide to support it.

Regards,
Daniel Vlad


Proposal for a new Commons Personalization Rules package

(0)  rationale

Personalization is a major requirement for all types of Java applications
(web, portal, Swing, applets, stand-alone clients, wireless applications,
etc.)
There is no industry standard solution for personalizing Java applications
in general. It is common for developers to implement personalization
requirements by intermixing personalization logic with application code or
even hard-coding personalization requirements directly in JSP.

Vendor personalization solutions target only portal development and they
are restricted to applications running inside a portlet container. As a
result, portal personalization solutions are not appropriate for
stand-alone web applications or plain Java applications.

A set of lightweight, technology-independent, reusable personalization
components can provide significant benefits to application development:
-  encapsulate personalization logic code and decouple this code from the
rest of the application, thus simplifying application development and
maintenance.
-  centralize the management of the personalization rules, ensuring
application consistency.
-  improve the performance of the application by caching the outcomes of
the personalization decisions.

JSR 168 (Portlet) specification does not define a common approach for
encapsulating personalization logic and making personalization decisions.
The specification provides per-user portlet preferences and allows vendors
to plug-in their own personalization engines to make decisions based on
these preferences. Thus, a set of components to manage personalization
decisions will even be beneficial to portlet developers.

(1)  scope of the package

The package will create a set of reusable components to encapsulate the
personalization logic in the application and to decouple these rules from
the rest of the application.

(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

Initial Design:

The main abstraction in this package is a PersonalizationRule. A rule
encapsulates logic needed to make a personalization decision. In order to
make a decision, a rule needs user data and preferences, as well as rule
configuration parameters.

User data and preferences:
- user preferences will be accessed using the Preferences API.
- user data will be fed to a Rule through an interface that can be
implemented to hold data coming from any external user repository, such as
LDAP. In particular this design pattern should allow a rule to be
configured using the Portlet Preferences, to make personalization
components compatible with JSR 168 API.
- the design from the JDJ article should be updated to remove the
dependency on the Servlet API and to make the personalization components
technology-independent.

Rule configuration:
- rules will be declared and configured in an XML file. For flexibility,
the configuration file should allow each rule to specify the implementation
class declaratively.

Additional features:
- composite rules, or rules created by aggregating other rules using
Boolean operators (AND, OR, etc.). Composite rules should be declared in
XML format. Example: If user is a Manager AND belongs to Department X.
- a set of commonly used rules should be provided with the code
distribution. For example, rules based on security roles (see JDJ article
example), rules that check if a user attribute/preference matches some
data, etc.
- 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.

The initial design will be updated/enhanced/improved as necessary.

(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 TBD

Initial group of developers:
Daniel H. Vlad
Karan Malhi
Frank W. Zammetti



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

Re: Proposal for a new Commons personalization package

Posted by da...@highmark.com.




I think we are generating some good discussions here, and I wanted to thank
everybody for their input, in particular to those who have volunteered to
help with development :).  I wanted to re-emphasize a couple points:

- The personalization components will rely on the Preferences API for user
and configuration data. But to make personalization decisions in an
application you also need Business Logic. The core of this proposal is to
create these personalization rules as an encapsulation of the
personalization logic, and to make them configurable and reusable
throughout the application. The article takes this configuration idea even
further, by allowing you to configure the implementation class for a given
rule declaratively.

- In regard to the HttpServletRequest dependency. In the article I mention
that in order to make personalization decisions you need to know who the
user is, and that the HttpServletRequest is a way of obtaining that
knowledge. The HttpServletRequest example was a simplification since the
article was targeted to web applications (my mistake for not pointing this
out in the proposal) but the API doesn't need to be dependent on the
Servlet API.

- I believe that the development community needs a lightweight approach to
personalization, that should not rely on portal containers. I don't see a
reason for portals being a requirement for personalization.
Personalization/customization is needed in any type of Java application.

Thanks,
Daniel H. Vlad





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

Re: Proposal for a new Commons personalization package

Posted by Martin Cooper <mf...@gmail.com>.

On Thu, 6 Jan 2005 10:20:02 -0500, daniel.vlad@highmark.com
<da...@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"
>                                       <co...@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" <cr...@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
> > <da...@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

RE: Proposal for a new Commons personalization package

Posted by "Noel J. Bergman" <no...@devtech.com>.

daniel.vlad wrote:

> I just wanted to point out that these personalization components can be
> used for non web applications as well.

Your current propose seems webapp specific.

> Not all applications are portals, in fact the opposite is probably true

> So, why restricting the use of personalization to portals only?

Agreed.  However, since personalization is part of the Portal Specification,
should we not be trying to drive a common concept and technology?  The
Portal doesn't specify HOW it works, just the interface contract.  And what
I said wasn't that all personalization should be done by portals, but that a
personalization project should be compatible with the existing
specifications for personalization.

We need a concept of a user and a user's Preferences for a particular
component.  We want independence of storage.  We probably want to look at
the WMM which also supports mapping different pieces of data into different
storage components, e.g., LDAP for enterprise-wide data, and a local DB for
locally added personalization.

Done properly, I could see this leading to a JSR.

	--- Noel

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

Re: Proposal for a new Commons personalization package

Posted by da...@highmark.com.




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.
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.

Thanks,
Daniel H. Vlad




                                                                           
             "Stephen                                                      
             Colebourne"                                                   
             <scolebourne@btop                                          To 
             enworld.com>              "Jakarta Commons Developers List"   
                                       <co...@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" <cr...@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
> <da...@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

Re: Proposal for a new Commons personalization package

Posted by Stephen Colebourne <sc...@btopenworld.com>.

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" <cr...@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
> <da...@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

Re: Proposal for a new Commons personalization package

Posted by da...@highmark.com.




Craig,

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.
We still need to discuss whether we want to offer an alternative
implementation for JDK 1.3 and before, or require JDK 1.4 to start with. I
would think that requiring JDK 1.4 would not be unacceptable, but any
comments on this will be appreciated.

I have a list of developers that have expressed their interest in working
on this project, but I need to contact them before adding their names to
the proposal.

Thank you for your comments.

Regards,

Daniel H. Vlad
Technology Architecture & Implementation
Highmark
Phone: 412.544.3180



                                                                           
             "Craig                                                        
             McClanahan"                                                   
             <craigmcc@gmail.c                                          To 
             om>                       "Jakarta Commons Developers List"   
                                       <co...@jakarta.apache.org>    
             01/05/2005 01:21                                           cc 
             PM                                                            
                                                                   Subject 
                                       Re: Proposal for a new Commons      
             Please respond to         personalization package             
             "Jakarta Commons                                              
             Developers List"                                              
             <commons-dev@jaka                                             
             rta.apache.org>;                                              
             Please respond to                                             
             craigmcc@apache.o                                             
                    rg                                                     
                                                                           
                                                                           




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
<da...@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

Re: Proposal for a new Commons personalization package

Posted by Craig McClanahan <cr...@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
<da...@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

RE: Proposal for a new Commons personalization package

Posted by "Noel J. Bergman" <no...@devtech.com>.

daniel.vlad wrote:

> JSR 168 focuses on Portlet specifications, and unfortunately,
> personalization rules such as those presented in this proposal
> and not part of the API.

Per-user portlet preferences are part of the Portlet Specificiation
(JSR-168).  If you've not noticed, you might want to revisit the
specification.

> In fact these personalization rules (and rule management components) can
> even be used in a Portlet, for example to dynamically select the content
> that will be displayed to an user.

That is precisely the purpose of portlet preferences, and there is a
standard for portlet preferences in the portlet specification, with room for
vendors to customize in some areas (such as IBM deciding that read-only
preferences can be modified by administrators when in their custom Configure
mode).  That specification is what Portlet developers should be using.

	--- Noel

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

RE: Proposal for a new Commons personalization package

Posted by da...@highmark.com.




JSR 168 focuses on Portlet specifications, and unfortunately,
personalization rules such as those presented in this proposal and not part
of the API.
In fact these personalization rules (and rule management components) can
even be used in a Portlet, for example to dynamically select the content
that will be displayed to an user.
In my view, including these components in the Jakarta Commons project has
the advantage of targeting both Portal and non-Portal application
developers.

Thanks,
Daniel Vlad





                                                                           
             "Noel J. Bergman"                                             
             <noel@devtech.com                                             
             >                                                          To 
                                       "Jakarta Commons Developers List"   
             01/05/2005 01:54          <co...@jakarta.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>                                              
                                                                           
                                                                           
                                                                           




Please see JSR-168, JetSpeed, and other portal projects.  I don't see a use
for a new personalization package for web applications that is not
compatible with Portals, and does not provide suitable implementation for
portals, even if it can be repurposed for standard web applications.

             --- Noel


---------------------------------------------------------------------
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

RE: Proposal for a new Commons personalization package

Posted by "Noel J. Bergman" <no...@devtech.com>.

Please see JSR-168, JetSpeed, and other portal projects.  I don't see a use for a new personalization package for web applications that is not compatible with Portals, and does not provide suitable implementation for portals, even if it can be repurposed for standard web applications.

	--- Noel


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