On 05/14/2010 09:51 AM, Nikolaos Giannopoulos wrote:
> Aaron,
>
> That sounds like positive news.  If you have a moment I have 2 questions:
>
> 1) In the interim what option would you pick... using a constant or
> manual sync....
>
>    

I probably wouldn't go so far as to create a constant for it unless I 
was expecting to change the constant sometime in the future but that's 
just me. Not sure I'd recommend listening to me. :-D

I just remembered something that might help you. Patrick Lightbody wrote 
a class called HibernateValidationMetadataProvider that's available in 
StripesStuff. It extends DefaultValidationMetadataProvider to make use 
of Hibernate annotations in Stripes validation so you wouldn't need to 
include maxlength in @Validate.

> 2) I'm sure I can read up on JSR-303 and everything but can you tell me
> in a nutshell how it will solve this particular problem... nothing
> detailed...
>
>    

JSR-303 is for validation annotations. IIRC the @Column(length=25) in 
your example below will be picked up by Hibernate's JSR-303 
implementation without you having to change anything.

> Thanks Again for authoring (IIRC) Stripersist!  We plan on leveraging it
> and pushing it to its limits!!!
>
> Regards,
>
> --Nikolaos
>
>    

I'm happy to see people finding Stripersist useful! Let me know if you 
have any questions/concerns about it.

Aaron

>
> Aaron Porter wrote:
>    
>> Hi Nikolaos,
>> No, you're not missing anything. JSR-303 (validation) is on the list for
>> the next major version of Stripes. That will really simplify things as
>> Hibernate already supports JSR-303. When I get some time I plan on
>> working on that but it may be a little while because I haven't really
>> had any extra time lately. :-(
>>
>> Aaron
>>
>>
>> On 05/13/2010 11:43 PM, Nikolaos Giannopoulos wrote:
>>
>>      
>>> Hi,
>>>
>>> I'm integrating Stripersist w/ JPA, Hibernate and MySQL and have been
>>> working with some code from Frederic's great book.
>>>
>>> Assuming the following shortened class excerpts:
>>>
>>> @Entity
>>> public class Contact extends BaseModel {
>>>       private String firstName;
>>>       ...
>>>
>>> public class ContactFormActionBean {
>>>       @ValidateNestedProperties( {
>>>           @Validate(field = "firstName", maxlength = 25),
>>>           ...
>>>       @Override
>>>       public void setContact(Contact contact) {
>>>           super.setContact(contact);
>>>       }
>>>
>>> The above logically results in a Contact table "firstName" column that
>>> is varchar(255) which is obviously not ideal and moreover will not be
>>> required as the field is never>   than 25.
>>>
>>> Now to make the Contact table "firstName" column varchar(25) vs. the
>>> default varchar(255) I add the following @Column annotation and all is well:
>>>
>>> @Entity
>>> public class Contact extends BaseModel {
>>>       @Column(length=25)
>>>       private String firstName;
>>>       ...
>>>
>>> Except now I have 2 values that I need to keep in sync PER field that is
>>> constrained (and typically a high percentage of String fields do not
>>> need to be 255 chars).
>>>
>>> So what to do about this to simplify the duplication issue i.e. the
>>> constraints at the Model and Controller?  Well the obvious traditional
>>> coding choice is something like:
>>>
>>> @Entity
>>> public class Contact extends BaseModel {
>>>       public static final int FIRST_NAME_LENGTH = 25;
>>>
>>>       @Column(length=Contact.FIRST_NAME_LENGTH)
>>>       ...
>>>       private String firstName;
>>>       ...
>>>
>>> public class ContactFormActionBean {
>>>       @ValidateNestedProperties( {
>>>           @Validate(field = "firstName", maxlength =
>>> Contact.FIRST_NAME_LENGTH),
>>>           ...
>>>       @Override
>>>       public void setContact(Contact contact) {
>>>           super.setContact(contact);
>>>       }
>>>
>>> Now this keeps the values in sync but PER each 2 properties I want to
>>> keep in sync I am introducing 1 additional variable (constant) to
>>> configure.  In some ways better but still feels lacking....
>>>
>>> Is there an easier way to solve this issue such that it better leverages
>>> Stripes forte of convention over configuration?
>>>
>>> Perhaps I am missing something obvious?
>>>
>>> --Nikolaos
>>>
>>>
>>>
>>>        
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Stripes-users mailing list
> Stripes-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/stripes-users
>
>    


------------------------------------------------------------------------------

_______________________________________________
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users

Reply via email to