hi rudy,

in case of SkipValidationStrategy you are right - it has to be moved as
well.
JoinValidationStrategy will be removed after some final tests.
(it was replaced by JoinValidationMetaDataStorageFilter which is based on
the new storage concept and offers a better performance.)

regards,
gerhard

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces


2010/2/3 Rudy De Busscher <[email protected]>

> Hi Gerhard,
>
>
>
> +1
>
> but maybe a few remarks
>
> - When the refactorings are only cosmetic (like here, there is a better
> grouping of functional alike classes), the user of the library hasn't much
> benefit from it. And thus doesn't like it very much.
>
>  - By moving the annotation (JoinValidation, SkipValidation), the strategy
> must be moved along, no ?
>
>  - JoinValidationStrategy is marked deprecated, (commit related to
> EXTVAL-59 and EXTVAL-60, don't see the immediate link between the deprecated
> and the issue, but anyway)
>
>  - So skipValidation is the only x.x.2 moved file, together with the
> CrossValidationStorageEntry indicated on the upgrade guide.
>
>  - Moving classes between packages is seen during compile time of the
> project.  So, although not pleasant for the user, it is more visible then
> the functional changes of the @Length and the @Pattern.
>
>
>
> So only one 'feature' skipValidation impacted and already done other
> similar things, so +1
>
> regards,
>
> Rudy
>
>
> On 3 February 2010 14:49, Gerhard Petracek <[email protected]>wrote:
>
>> hi @ all,
>>
>> the review phase for the next extval release (r3) has been started
>> already. one important topic is backward compatibility.
>> the 3rd release will be a major version. besides a lot of new features r3
>> will be the first version which offers bean-validation integration for all
>> jsf versions.
>>
>> i created an upgrade guide [1] for collecting changes which aren't
>> backward compatible.
>> currently there are just very few changes in the property-validation
>> module which are easy to fix.
>>
>> since r3 will be a major release and i know many people who started with
>> the current milestone and not the previous version, i think we can take the
>> chance for further restructurings in the validation modules.
>>
>> what's about the following suggestion?
>> i would like to introduce a new package which is suggested for every
>> validation module for shared/common stuff.
>> the name is e.g. "module" and in case of the property-validation module it
>> would be interesting to move some classes to this package.
>>
>> property-validation module:
>> org.apache.myfaces.extensions.validator.module.property [new]
>>  |_ PropertyValidationModuleKey [new]
>>  |_ PropertyValidationSkipValidationEvaluator [new]
>>  |_ annotation
>>  |    |_ JoinValidation [moved]
>>  |    |_ SkipValidation [moved]
>>  |    |_ SkipValidationSupport [moved]
>>  |__ initializer.component [new]
>>  |    |_ HtmlCoreComponentsComponentInitializer [moved]
>>  |__ interceptor [new]
>>  |     |_ PropertyValidationInterceptor [moved]
>>  |__ startup [new]
>>  |     |_ PropertyValidationModuleStartupListener [moved]
>>  |__ storage [new]
>>        |__ mapper [new]
>>        |    |__ PropertyValidationGroupStorageNameMapper [new]
>>        |__ JoinValidationMetaDataStorageFilter [new]
>>
>> most of the stuff is new or internal - so we don't really have an issue
>> here.
>> however, esp. JoinValidation, SkipValidation and SkipValidationSupport are
>> not new and part of the api.
>> if we move these annotations (because they are used in base- as well as in
>> cross-validation), users have to fix some import statements. since these
>> annotations aren't used extremely often it does >not< lead to a huge effort.
>> to be consistent we would have the same package concept in the
>> bean-validation module as well
>> (org.apache.myfaces.extensions.validator.module.bean). in this case we don't
>> have an issue because the module is completely new.
>>
>> since it is a major release (imo) the impact is minimal and should be ok.
>> if there is no veto, i'll do the mentioned refactoring.
>> (for sure - i'll also create a jira issue.)
>>
>> regards,
>> gerhard
>>
>> [1]
>> http://wiki.apache.org/myfaces/Extensions/Validator/Versions/Versions/UpgradeGuide
>>
>> http://www.irian.at
>>
>> Your JSF powerhouse -
>> JSF Consulting, Development and
>> Courses in English and German
>>
>> Professional Support for Apache MyFaces
>>
>
>

Reply via email to