Re: [Stripes-users] Validation too specific

Subject:   Re: [Stripes-users] Validation too specific (find more)
From:  
Date:   Oct 17, 2005 14:09


Return-Path: <hidden>
Received: from cmcc5-dfe.broad.mit.edu ([18.103.15.238])
 by esc49.midphase.com with esmtpa (Exim 4.44)
 id 1ERZPr-0006XY-3f
 for hidden; Mon, 17 Oct 2005 14:08:55 -0400
Message-Id: <hidden>
Date: Mon, 17 Oct 2005 14:09:00 -0400
From: Tim Fennell <hidden>
Reply-To: hidden
Sender: hidden
To: hidden
Subject: Re: [Stripes-users] Validation too specific
In-Reply-To: <hidden>
Errors-To: hidden
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Original-To: hidden
Delivered-To: hidden
References: <hidden>
X-Mailer: Apple Mail (2.734)
Received-SPF: unknown (socket error)
X-AntiAbuse: Sender Address Domain - tfenne.com
X-Source:
X-Source-Args:
X-Source-Dir:
X-Spam-Score: 0.0 (/)
X-Spam-Report: Spam Filtering performed by sourceforge.net.
 See http://spamassassin.org/tag/ for more details.
 Report problems to http://sf.net/tracker/?func=add&group_id=1&atid=200001
X-BeenThere: hidden
X-Mailman-Version: 2.0.9-sf.net
Precedence: bulk
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/stripes-users&gt;,
 <mailto:hidden?subject=unsubscribe>
List-Id: A list for dicussing building applications with Stripes. <stripes-users.lists.sourceforge.net>
List-Post: <mailto:hidden>
List-Help: <mailto:hidden?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/stripes-users&gt;,
 <mailto:hidden?subject=subscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum=stripes-users>
Status:

Hi Jim,

That sounds great.  I've been thinking about similar things lately.  =20
While I wouldn't want anything in Stripes that forced someone to have =20
hibernate around if they weren't using it, I'm all for having =20
optional integrations with major tools form part of the core =20
codebase.  The way I think about this is usually by extending/=20
swapping out one or more of the configurable components like the =20
ActionResolver or the ActionBeanPropertyBinder.

With tools like hibernate (and probably EJB 3.0) it would be nice to =20
go one further and support things like:
     - unified validation as you suggest
     - automatic loading of persistent objects prior to binding
     - automatic rolling back of transactions on validation errors
     - and anything else that would be useful in a Stripes+Hibernate =20
application.

I'd definitely like to hear more of what you have in mind, and am =20
always open to contributions :)

-t


On Oct 17, 2005, at 2:00 PM, James Stangler wrote:

> Here's an idea I've been thinking about for a while and I'd like to =20
> hear other's thoughts.
>
> One of the things I dislike is having validation logic split or =20
> duplicated between the gui layer
> and the business layer.  For example, assume a field has a max =20
> length of 5 characters and the
> database column enforces this.  Most of the validation focuses on =20
> the gui layer to ensure that the
> user hasn't entered a value of more than 5 characters.  But if =20
> there are multiple ways for the
> field to be entered into the system (such as multiple gui screens, =20
> a conversion program, a batch
> processing program, etc), there's no way to reuse this validation =20
> logic.  It either isn't
> performed relying on the database to throw an exception or it has =20
> to be duplicated and kept in
> sync with the gui logic.
>
> The idea I've been toying with would be a mechanism to allow =20
> Stripes to use the Hibernate
> validation extension annotations that can be used on the data =20
> objects.  Yes, I know that this
> would be Hibernate specific and subject to change and may not be =20
> the best route to go.  But it
> seems like it would be a useful way to specify validations that the =20
> persistance layer and gui
> layer could share.  The Hibernate validation annotations allow for =20
> new validation annotations to
> be created which would provide for expandability.  Ultimately it =20
> would be nice to be able to use
> the JSTL regular expression syntax in a new Hibernate validation =20
> annotation to provide a ton of
> flexibility.
>
> I've started prototyping a little code to see if this could be =20
> accomplished without being
> intrusive, ideally as some sort of plugin so that people who aren't =20
> using Hibernate wouldn't be
> affected at all, but I wanted to see what others thought before I =20
> spent a lot of time on it.
>
> Thoughts?
>
> jim
>
> --- Tim Fennell <hidden> wrote:
>
>
>> That's an interesting idea.  Someone else has requested ways to add
>> field specific validations to the ActionBean, and there is a feature
>> request open for this here: http://mc4j.org/jira/browse/STS-76
>>
>> While the solutions you suggested don't really work for nested
>> objects on the bean, I do like the idea for properties directly on
>> the bean of either being able to throw an exception or perhaps access
>> the validation errors.  I like the second approach best because it
>> would give you more explicit control over how errors get attached and
>> displayed.
>>
>> Having looked at the code, I can see why adding a validation error in
>> the setter doesn't work, and it will be trivial to fix.  If that
>> sounds like a good solution to you then I would suggest doing this in
>> the mean time:
>>      - generate your validation errors in the setters, and add them
>> to a map stored on the ActionBean
>>      - in the validate() method check to see if the map has contents,
>> and if so dump them into the validation errors
>>
>> That way, when the next maintenance release comes out in a week or
>> two, the changes should be minimal.  How does that sound?
>>
>> -t
>>
>> On Oct 17, 2005, at 10:54 AM, Andre Matheus wrote:
>>
>>
>>> Hi all,
>>>
>>> Let we suppose I have a validation a little bit too specific to be
>>> done in annotation style.
>>>
>>> For instance, a validation that should check something in another
>>> class in order to check if the value is valid or not.
>>>
>>> My first idea was to just throw an exception on the setter method of
>>> my action bean, but it did not work.
>>>
>>> My second idea was to create an VallidationError and store it in the
>>> ValidationErrors list of the ActionBeanContext, but it did not work
>>> also.
>>>
>>> The only way it seams to work is the one defined in
>>> MultiBugActionBean.java of the sample application
>>> (http://stripes.mc4j.org/confluence/display/stripes/Sample
>>> +Application),
>>> where I need to wait until the event be called and write there the
>>> validation needed.
>>>
>>> Are there any way of test the validity of some field in code inside
>>> the setter method, other then by the annotations?
>>>
>>> Best Regards...
>>>
>>> --
>>> __
>>> Andr=C3=A9 Matheus
>>>
>>>
>>> -------------------------------------------------------
>>> This SF.Net email is sponsored by:
>>> Power Architecture Resource Center: Free content, downloads,
>>> discussions,
>>> and more. http://solutions.newsforge.com/ibmarch.tmpl
>>> _______________________________________________
>>> Stripes-users mailing list
>>> hidden
>>> https://lists.sourceforge.net/lists/listinfo/stripes-users
>>>
>>>
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by:
>> Power Architecture Resource Center: Free content, downloads, =20
>> discussions,
>> and more. http://solutions.newsforge.com/ibmarch.tmpl
>> _______________________________________________
>> Stripes-users mailing list
>> hidden
>> https://lists.sourceforge.net/lists/listinfo/stripes-users
>>
>>
>
>
>
>
>
> __________________________________
> Yahoo! Mail - PC Magazine Editors' Choice 2005
> http://mail.yahoo.com
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads, =20
> discussions,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> Stripes-users mailing list
> hidden
> https://lists.sourceforge.net/lists/listinfo/stripes-users
>



-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Stripes-users mailing list
hidden
https://lists.sourceforge.net/lists/listinfo/stripes-users