-->
These old forums are deprecated now and set to read-only. We are waiting for you on our new forums!
More modern, Discourse-based and with GitHub/Google/Twitter authentication built-in.

All times are UTC - 5 hours [ DST ]



Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 5 posts ] 
Author Message
 Post subject: Naming changes in Bootstrap API
PostPosted: Wed Jan 14, 2009 11:36 pm 
Hibernate Team
Hibernate Team

Joined: Sun Sep 14, 2003 3:54 am
Posts: 7256
Location: Paris, France
The naming in the bootstrap API was lacking some consistency and was a bit obscure at time

I went back to the drawing board and came with something that is I think more natural and thus easier to use:
- to build ValidatorFactory
- to build Validator

Each set of proposal change is followed by the old and new syntax. Feedback welcome.

To Build a ValidatorFactory

Here are the proposed changes
Code:
ValidatorFactoryBuilder => Configuration (should it be ValidatorFactoryConfiguration)
Validation.builderType(Class<T>) to Validation.byProvider(Class<T>)
Validation.defineBootstrapState() to Validation.byDefaultProvider()
GenericBuilderFactory.getBuilder() to GenericConfigurationFactory.configure()
SpecializedBuilderFactory.getBuilder() to SpecializedConfigurationFactory.configure()
ValidatorFactoryBuilder.build() to Configuration.getValidatorFactory()  (should it be buildValidatorFactory()?)
ValidatorFactoryBuilder.configure() to Configuration.customConfiguration()


Also I am considering:
- removing Validation.getBuilder() (which would have been Validation.configure() )
- adding Validation.getDefaultValidatorFactory() (which correspond to the default bootstrap strategy used by JPA and JSF unless overridden)

Here are various bootstraps with the old naming followed by the new naming. You will see that we gain in consistency and expressivity:
- byProvider(Class<?>) vs byDefaultProvider()
- the object type retrieved and its purpose is more obvious (configure(), getValidatorFactory())
- the builder is a configuration object retrieving state to build ValidatorFactory

Code:
//simple bootstrap
ValidatorFactoryBuilder<?> builder = Validation.getBuilder();
=> no equivalent but replaced by
Configuration<?> configuration = Validation.byDefaultProvider().configure();

Validation.getBuilder().build();
=>
ValidatorFactory factory = Validation.getDefaultValidatorFactory();

//use generic provider with specific resolver strategy
ValidatorFactoryBuilder<?> factoryBuilder =
    Validation.defineBootstrapState()
        .providerResolver(...)   //optional step
        .getBuilder();
=>
Configuration<?> configuration =
    Validation.byDefaultProvider()
        .providerResolver(...)   //optional step
        .configure();

//use a specific provider with specific resolver strategy
ValidatorFactoryBuilder<?> factoryBuilder =
    Validation.builderType(ACMEValidatorFactoryBuilder.class)
        .providerResolver(...)   //optional step
        .getBuilder();
=>
Configuration<?> configuration =
    Validation.byProvider(ACMEValidatorConfiguration.class)
        .providerResolver(...)    //optional step
        .configure();


I am also wondering if we should rename the methods on the Configuration object (former ValidatorFactoryBuilder):
- messageResolver => useMessageResolver
- providerResolver => useProviderResolver
- traversableResolver => useTraversableResolver
- customConfiguration => useCustomConfiguration
- constraintFactory => useConstraintFactory

This makes them a bit more "fluent" but also more verbose.

To Build a Validator

rename ValidatorFactory.defineValidatorState() to ValidatorFactory.usingContext()
rename ValidatorBuilder to ValidatorContext

Here are various bootstraps with the old naming followed by the new naming. We gain consistency with the VF creation as well

Code:
//simple validator creation
Validator validator = validatorFactory.getValidator();
=>
Validator validator = validatorFactory.getValidator();   //unchanged

//with overriding context
Validator validator =
    validatorFactory.defineValidatorState()
        .traversableResolver(...)
        .messageResolver(...)
        .getValidator();
=>
Validator validator =
    validatorFactory.usingContext()
        .traversableResolver(...)
        .messageResolver(...)
        .getValidator();


What do you think?

There are three layers of changes:
- having a consistent naming between VF and V creations and using more meaningful name for the build method (ie getValidator / getValidatorFactory
- having a consistent path and naming wether you use the default provider or a specific one
- rename the builder classes with meaningful definitions

_________________
Emmanuel


Top
 Profile  
 
 Post subject: set* or use*
PostPosted: Mon Feb 02, 2009 4:31 am 
Newbie

Joined: Thu Apr 03, 2008 4:27 am
Posts: 10
Why did you not use setter names here?
- messageResolver => setMessageResolver
- providerResolver => setProviderResolver
- traversableResolver => setTraversableResolver
- customConfiguration => setCustomConfiguration
- constraintFactory => setConstraintFactory


Top
 Profile  
 
 Post subject:
PostPosted: Mon Feb 02, 2009 5:18 am 
Hibernate Team
Hibernate Team

Joined: Sun Sep 14, 2003 3:54 am
Posts: 7256
Location: Paris, France
because these are not JavaBean setters, these methods have a return value.

_________________
Emmanuel


Top
 Profile  
 
 Post subject:
PostPosted: Mon Feb 09, 2009 2:41 pm 
Newbie

Joined: Fri May 26, 2006 6:07 am
Posts: 5
fluent api is nice when we do configuration/construction programmatically, but nowadays, people utilize IoC framework and construct objects by configuration.

e.g. if the ValidatorFactoryConfiguration is a JavaBean, we could define it in spring as:
<bean id="validatorFactoryConfiguration" class="xxx">
<property name="messageResolver " ref="MyMessageResolver"/>
</bean>

<bean id="MyMessageResolver" class="xxx">

</bean>

would it be possible to allow using JavaBean style configuration?


Top
 Profile  
 
 Post subject:
PostPosted: Tue Feb 10, 2009 4:24 am 
Newbie

Joined: Thu Jan 15, 2009 6:52 am
Posts: 1
Location: Austria
mingfai wrote:
fluent api is nice when we do configuration/construction programmatically, but nowadays, people utilize IoC framework and construct objects by configuration.

e.g. if the ValidatorFactoryConfiguration is a JavaBean, we could define it in spring as:
<bean id="validatorFactoryConfiguration" class="xxx">
<property name="messageResolver " ref="MyMessageResolver"/>
</bean>

<bean id="MyMessageResolver" class="xxx">

</bean>

would it be possible to allow using JavaBean style configuration?


You can create your own "Spring" FactoryBean


Top
 Profile  
 
Display posts from previous:  Sort by  
Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 5 posts ] 

All times are UTC - 5 hours [ DST ]


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
© Copyright 2014, Red Hat Inc. All rights reserved. JBoss and Hibernate are registered trademarks and servicemarks of Red Hat, Inc.