A couple of comments: * You might want to add to the proposal an answer to the likely most frequently asked question -- how does your approach compare/contrast/deal with the preferences APIs in JDK 1.4 (the java.util.prefs package)?
* Is there anyone other than yourself who has expressed interest in working on this? Packages with a single developer tend to have more problems attracting a community. (And yes, this is definitely a "chicken and egg" sort of problem :-). Craig On Wed, 5 Jan 2005 11:52:18 -0500, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > Hi, > > I recently authored an article for Java Developer's Journal where I > describe a set of reusable components for web application personalization. > I found these components to be very useful, and I thought it will be > beneficial to create a new Jakarta Commons package for personalization > components. The design and the code presented in the article can be > enhanced to add functionality and make these components more powerful. > Please take a look at the enclosed proposal and let me know what you think. > I added a link to the JDJ article (Section (2) of the proposal) for your > reference. > > Regards, > Daniel Vlad > > Proposal for a new Commons Personalization package > > (0) rationale > > Personalization is a major requirement for many web applications, yet most > developers still implement these requirements by intermixing > personalization logic with application code and even hard-coding > personalization requirements directly in JSP. > Most of the personalization solutions in the industry target Portlet > development, and they are not appropriate for standalone web applications. > A set of lightweight, framework-independent, reusable personalization > components can provide significant benefits to application development: > - decouple personalization-related code from the rest of the application, > thus simplifying the application maintenance. > - centralize the management of the personalization rules, ensuring > application consistency. > - simplify web application development by shifting the complex task of web > application personalization from Java developers to Web page authors. > - improve the performance of the application by caching the outcomes of > the personalization decisions. > > (1) scope of the package > > The package will create a set of reusable components to decouple > personalization rules from the rest of the application logic and to > centralize the management of these rules. > Personalization rules will be defined and configured in an XML > configuration file. An application will invoke these components either > programmatically or through JSP tags. > Web pages will be personalized by using custom JSP tags that evaluate > personalization rules and decide what personalized content to be displayed > to various users. > > (1.5) interaction with other packages > > The package will use the following external packages: > Commons Digester - to parse the personalization XML file > Commons Logging - for logging > > (2) identify the initial source for the package > > The initial codebase will be contributed by Daniel H. Vlad, and it is based > on the article "Personalize Your Web Applications", authored by Daniel and > published as a Cover Story in Java Developer's Journal, December 2004, > pages 34-40. > > Article URL: http://www.sys-con.com/story/?storyid=47357&DE=1 > Pdf download: http://pdf.sys-con.com/Java/JDJDecember2004.pdf > > The code base from the JDJ article will be re-designed and enhanced to: > - add content rules, rules that dynamically decide the content that should > be displayed to users. This can be accomplished, for example, by > categorizing users in groups using grouping criteria and mapping these user > groups on content items using an XML mapping file. > - add caching to improve performance. > > (2.1) identify the base name for the package > org.apache.commons.personalization > (2.2) identify the coding conventions for this package > Sun coding conventions > > (3) identify any Jakarta-Commons resources to be created > (3.1) mailing list > Until traffic justifies, the package will use the Jakarta-Commons list for > communications. > (3.2) CVS repositories > For the time being, the package will use a root branch of the > Jakarta-Commons CVS. > (3.3) Bugzilla > The package should be listed as a component of under the Jakarta-Commons > Bugzilla entry. > > (4) identify the initial set of committers to be listed in the Status > File. > Daniel H. Vlad > other committers --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
