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"
<[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]
