I would like to avoid the creation of a service only for this purpose / scope.
can you avoid this part and make it more straightforward ?
I would also like to avoid the admin part because it implies to have persistence of
configuration somehow and we cannot afford it. But you said it's optional.
On Jan 31, 2012, at 2:28 PM, Christophe Laprun wrote:
Simplest way to do it, to me, is as follows:
- Identify where user names are validated in the current code. Remove unneeded validation
(in particular where it processes read-only data).
- Replace all instances of validators in all places we want users to configure username
validation by a single UserConfigurableUsernameValidator.
- Implement a simple service that will look for a configuration file in gatein.conf.dir
to allow users to define which regular expression should be used (as well as other
parameters as we see fit, e.g. min and max length). If no such configuration is found, use
the default logic as it currently exists in UsernameValidator.
- Have instances of UserConfigurableUsernameValidator gets their configuration from that
service.
- Optionally, add a user interface in the admin part of the portal to do this
configuration from within portal.
I think this solution will require the minimal amount of risk/work and still achieve our
goals of user configurable validation of user names without added complexity.
On Jan 31, 2012, at 1:22 PM, Julien Viet wrote:
> I want this to be done with the existing webui metadata objects, i.e the
org.exoplatform.webui.application.ConfigurationManager objects takes care of getting the
override and override the Validator configuration and then let webui construct the
validator from the metadata defined by the org.exoplatform.webui.config.Component class.
>
> it implies also that the ui component that we want to have pluggable validation
should not hardcode the definition and instead define default validation using the
annotation and not the programmatic manner.
>
> On Jan 31, 2012, at 12:21 PM, Trong Tran wrote:
>
>> I'm available here to discuss and still listening your voice :)
>>
>> we can see that the most restriction is about how to allow our users to be able
to customize rules of a valid username ( the others are not hard to achieve indeed ). To
get this done, I think the approach of using a kernel service for injecting validator
seems to be acceptable. it helps users easier to change the rules without modifying
anything in war. It should not be risky as we are just trying to fix problems and make it
more flexible.
>>
>> I'm also going to document the current rules of username for reference (
tomorrow i think )
>>
>>
>> On 31 January 2012 17:26, Boleslaw Dawidowicz
<boleslaw.dawidowicz(a)gmail.com> wrote:
>>
>> On Jan 30, 2012, at 12:53 PM, Trong Tran wrote:
>>
>>>
>>> On 27 January 2012 00:58, Christophe Laprun <claprun(a)redhat.com>
wrote:
>>> Hi all,
>>>
>>> I'm currently working on
https://issues.jboss.org/browse/GTNPORTAL-1673
and I'm quite puzzled by the different rules that are in place to validate usernames.
Not only are these rules not consistent across fields which display usernames (some are
validated using UsernameValidator, some are validated using ExpressionValidator) but
I'm also confused about the need to validate read-only fields (which presumably will
only display valid information since it doesn't come from the user, right?). What are
the rules for a valid username and where are they documented? What are the restrictions
and why are they in place?
>>>
>>> Defining the rules for a valid username is a long story, they have been
changed/updated many times according to users need. They are also not fixed and documented
so far. Until now, we still have requests related to this like : to support
case-sensitive, or possible to add username under an email address.
>>>
>>> Anyway the rules should be consistent every places and no need to validate
read-only fields, they are considered as issues
>>
>> I understand that due to the long story of changes it is rather hard to come up
with consistent list. However we need to decide on some plan to fix the situation and
agree if it is possible and safe to do it now.
>>
>> Trong, who do you think should be involved to get more clear picture about
reasons for current restrictions? If we decide that it is too risky to loosen them now
thats also quite valid outcome.
>>
>> Bolek
>>
>>
>>
>>
>> --
>> Tran The Trong
>> eXo Platform SEA
>> _______________________________________________
>> gatein-dev mailing list
>> gatein-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/gatein-dev
>
> _______________________________________________
> gatein-dev mailing list
> gatein-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/gatein-dev
Cordialement / Best,
Chris
==
Principal Software Engineer / JBoss Enterprise Middleware Red Hat, Inc.
Follow GateIn:
http://blog.gatein.org /
http://twitter.com/gatein
Follow me:
http://metacosm.info/metacosm /
http://twitter.com/metacosm