On Thu, 6 Jan 2005 10:20:02 -0500, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > I just wanted to point out that these personalization components can be > used for non web applications as well. There is no technology out there to > personalize Swing clients, applets, non-visual Java clients, wireless > applications, in addition to Web applications.
Um, in which of these environments does the JDK Preferences API not work? > Not all applications are portals, in fact the opposite is probably true: > only a minority of the applications being built today are portals. So, why > restricting the use of personalization to portals only? > That is why I believe that these components would be a good fit for Jakarta > Commons. The code in your JDJ article is tied to the Servlet API. (The isRuleSatisfied() method requires an HttpServletRequest parameter.) In section 2 of your proposal, you did not mention removing such a dependency as part of the planned enhancements. Aside from the fact that I don't personally believe we need such a component in Commons, such a dependency would have to be removed for this to be useful. -- Martin Cooper > Thanks, > Daniel H. Vlad > > "Stephen > Colebourne" > <[EMAIL PROTECTED] To > enworld.com> "Jakarta Commons Developers List" > <[email protected]>, > 01/05/2005 04:43 [EMAIL PROTECTED] > PM cc > > Subject > Please respond to Re: Proposal for a new Commons > "Jakarta Commons personalization package > Developers List" > <[EMAIL PROTECTED] > rta.apache.org> > > I would say that on balance this doesn't strike me as a commons component. > Commons components should be small and isolated in scope. This proposal > covers a specific file format and forces a use of tag libraries. > > I can see various possibilities for it: > - Host at sourceforge > - Try Jakarta Taglibs project - by focussing on the taglibs aspect, and > potentially reusing other tags there, you may have more success > - Try to build a community focussed on small interoperating parts commonly > used in web applications, eg. by adding a logon component, a user > management > component > > Stephen > > ----- Original Message ----- > From: "Craig McClanahan" <[EMAIL PROTECTED]> > >A couple of comments: > > > > * You might want to add to the proposal an answer to the > > likely most frequently asked question -- how does your > > approach compare/contrast/deal with the preferences > > APIs in JDK 1.4 (the java.util.prefs package)? > > > > * Is there anyone other than yourself who has expressed > > interest in working on this? Packages with a single > > developer tend to have more problems attracting a > > community. (And yes, this is definitely a "chicken > > and egg" sort of problem :-). > > > > Craig > > > > On Wed, 5 Jan 2005 11:52:18 -0500, [EMAIL PROTECTED] > > <[EMAIL PROTECTED]> wrote: > >> > >> > >> Hi, > >> > >> I recently authored an article for Java Developer's Journal where I > >> describe a set of reusable components for web application > >> personalization. > >> I found these components to be very useful, and I thought it will be > >> beneficial to create a new Jakarta Commons package for personalization > >> components. The design and the code presented in the article can be > >> enhanced to add functionality and make these components more powerful. > >> Please take a look at the enclosed proposal and let me know what you > >> think. > >> I added a link to the JDJ article (Section (2) of the proposal) for your > >> reference. > >> > >> Regards, > >> Daniel Vlad > >> > >> Proposal for a new Commons Personalization package > >> > >> (0) rationale > >> > >> Personalization is a major requirement for many web applications, yet > >> most > >> developers still implement these requirements by intermixing > >> personalization logic with application code and even hard-coding > >> personalization requirements directly in JSP. > >> Most of the personalization solutions in the industry target Portlet > >> development, and they are not appropriate for standalone web > >> applications. > >> A set of lightweight, framework-independent, reusable personalization > >> components can provide significant benefits to application development: > >> - decouple personalization-related code from the rest of the > >> application, > >> thus simplifying the application maintenance. > >> - centralize the management of the personalization rules, ensuring > >> application consistency. > >> - simplify web application development by shifting the complex task of > >> web > >> application personalization from Java developers to Web page authors. > >> - improve the performance of the application by caching the outcomes of > >> the personalization decisions. > >> > >> (1) scope of the package > >> > >> The package will create a set of reusable components to decouple > >> personalization rules from the rest of the application logic and to > >> centralize the management of these rules. > >> Personalization rules will be defined and configured in an XML > >> configuration file. An application will invoke these components either > >> programmatically or through JSP tags. > >> Web pages will be personalized by using custom JSP tags that evaluate > >> personalization rules and decide what personalized content to be > >> displayed > >> to various users. > >> > >> (1.5) interaction with other packages > >> > >> The package will use the following external packages: > >> Commons Digester - to parse the personalization XML file > >> Commons Logging - for logging > >> > >> (2) identify the initial source for the package > >> > >> The initial codebase will be contributed by Daniel H. Vlad, and it is > >> based > >> on the article "Personalize Your Web Applications", authored by Daniel > >> and > >> published as a Cover Story in Java Developer's Journal, December 2004, > >> pages 34-40. > >> > >> Article URL: http://www.sys-con.com/story/?storyid=47357&DE=1 > >> Pdf download: http://pdf.sys-con.com/Java/JDJDecember2004.pdf > >> > >> The code base from the JDJ article will be re-designed and enhanced to: > >> - add content rules, rules that dynamically decide the content that > >> should > >> be displayed to users. This can be accomplished, for example, by > >> categorizing users in groups using grouping criteria and mapping these > >> user > >> groups on content items using an XML mapping file. > >> - add caching to improve performance. > >> > >> (2.1) identify the base name for the package > >> org.apache.commons.personalization > >> (2.2) identify the coding conventions for this package > >> Sun coding conventions > >> > >> (3) identify any Jakarta-Commons resources to be created > >> (3.1) mailing list > >> Until traffic justifies, the package will use the Jakarta-Commons list > >> for > >> communications. > >> (3.2) CVS repositories > >> For the time being, the package will use a root branch of the > >> Jakarta-Commons CVS. > >> (3.3) Bugzilla > >> The package should be listed as a component of under the Jakarta-Commons > >> Bugzilla entry. > >> > >> (4) identify the initial set of committers to be listed in the Status > >> File. > >> Daniel H. Vlad > >> other committers > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
