looking in webui there is already a configuration for validation in the package org.exoplatform.webui.config.

The class org.exoplatform.webui.config.Component class has a list of validators associated with it, each validator has an InitParams objects.

This can be loaded from XML, a sample is visible there http://anonsvn.jboss.org/repos/gatein/portal/trunk/webui/core/src/test/resources/webui-configuration.xml it contains among other:

<validators>
      <validator>
        <type>class.name</type>
        <init-params>
          <param><name>name</name><value>value</value></param>
        </init-params>
      </validator>
    </validators>
The class we want to make configured externally is the class UIGroupMembershipForm.

I foresee two steps to investigate

1/ we should try to see if we can first remove the validation hardcoded in UIGroupMembershipForm and instead use XML.
2/ we should find a way to make this configuration overridden externally with additional configuration in conf directory.

On Jan 27, 2012, at 1:23 PM, Christophe Laprun wrote:


On Jan 27, 2012, at 12:50 PM, Julien Viet wrote:

I was thinking about Bean Validation but there are several issues with this:
1. It would mean changing completely the validation architecture of WebUI, which would be a significant undertaking.
2. While we're still stuck with EE 5, this means an added dependency
3. I'm not familiar with it yet ;)

you are already talking about serious changes (introducing a new API, a new service, a new configuration).

our point of view is that we should not take an intermediate path and instead either

1/ we minimize the changes and answer the initial case asked "make UI validation regular expressions configurable by users" .

Answering the initial case minimally requires a new configuration and a new service to read it in and pass it to the validation architecture, unless there's a magic way to pass the regular expression to the current implementation without having to introduce these new elements that I'm not aware of… :)
Note that the service doesn't need to be exposed to users but I currently don't know any other way to read the configuration file and pass the data to the validators.
Note also that the username is not currently validated by a regular expression but rather by hardcoded rules in UsernameValidator in the spot that matters (i.e. where users can input data), though it is validated by regexp in some spots but validation seems unneeded (read-only elements).

So there are really 3 elements to address here:
1. which is the proper validation for usernames (I'm currently thinking the proper way is the UsernameValidator implementation)?
2. can we change these validation rules without breaking anything?
3. how do we make it so that users can change these rules without breaking anything?

2/ we make it the proper way avoiding to develop a feature that will be not thrown away in 6 months.

Matter of priorities I guess… Not my place to decide on this.

2/ what is your target with respect to GateIn 3.2 forthcoming release ?

Target is customer need for EPP 5.2.1 so probably GateIn 3.2 (depending on timing of the 3.2 release).

GateIn 3.2 has been postponed for months now, we wanted to have a release early Janueary. How many weeks are we considering to postpone it ?

I'm not in charge of the schedule and I have no idea when GateIn 3.2 is supposed to be released. Also, this is a feature targeted at EPP 5.2.1, a solution has to be decided on and implemented quickly, unless a fix is deemed too risky for a dot-dot release.

3/ you can write a specification to formulate the needs and define a solution

The ideal solution would probably be using Bean Validation, though, again, I need to look at it some more. The needs are fairly simple, our customers don't like to be arbitrarily restricted by what *we* think a username should be, so they want to be able to change the username validation. This actually extends to other parts of the portal as Marko as already shown with portal names. Basically, we currently put restrictions on theses things but:
1. theses restrictions are not documented anywhere
2. they don't necessarily fit with our users' needs and should therefore be configurable

In any case I want this to be specified in a document called "specification" in which we define the functional and technical part.

It goes both ways: I'd like the specifications for the current implementation and I'm sure Marko would like the specification for the portal name restrictions as well. I'm pretty sure our users would like to know this information as well.

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