Re: [Stripes-users] Validation too specific

Subject:   Re: [Stripes-users] Validation too specific (find more)
From:  
Date:   Oct 18, 2005 03:35


Return-Path: <hidden>
Received: by 10.70.45.2 with HTTP; Tue, 18 Oct 2005 00:35:24 -0700 (PDT)
Message-ID: <hidden>
Date: Tue, 18 Oct 2005 09:35:24 +0200
From: Andre Matheus <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
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=NzwzWFEBL1LDzZQx0NpFrYDnOtKl4/TFLs52USRQLLbOZvN/EHHJNe3ngE0hlpXzD1EZOWv3SUe+GZLIF7AAoz5KN3CZAJKt1TKvbJ/nMDiQ2SAYX1expX0aafSys1EAZbiyyvR6R7OssfgI5LLFrjc3xeFdQ/4Izqa5eRAAS3k=
Content-Disposition: inline
References: <hidden>
  <hidden>
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
 0.0 RCVD_BY_IP             Received by mail server with no name
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,

May be we can address something similar with the throw exception approach.

I mean, if we create a bean and use it to store the value of the field
in all places that the field is needed, would be enough to make the
bean setter throws an exception (SetterException) if, for instance,
the value has more then 5 characters, this would guarantee that
everyplace this bean is used, even independently of Stripes or
Hibernate, it will not allow more then 5 characters at all.

In principle I think it would be a mistake to develop functions in
Stripes that works only with this or that product, what would be nice
is to allow features of other tools to interact with stripes in some
well defined communication interface. In this case, the "communication
interface" would be the SetterException.

Regards,

__
Andre Matheus



On 10/17/05, Tim Fennell <hidden> wrote:
> Hi Jim,
>
> That sounds great.  I've been thinking about similar things lately.
> While I wouldn't want anything in Stripes that forced someone to have
> hibernate around if they weren't using it, I'm all for having
> optional integrations with major tools form part of the core
> codebase.  The way I think about this is usually by extending/
> swapping out one or more of the configurable components like the
> ActionResolver or the ActionBeanPropertyBinder.
>
> With tools like hibernate (and probably EJB 3.0) it would be nice to
> 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
> application.
>
> I'd definitely like to hear more of what you have in mind, and am
> 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
> > hear other's thoughts.
> >
> > One of the things I dislike is having validation logic split or
> > duplicated between the gui layer
> > and the business layer.  For example, assume a field has a max
> > length of 5 characters and the
> > database column enforces this.  Most of the validation focuses on
> > the gui layer to ensure that the
> > user hasn't entered a value of more than 5 characters.  But if
> > there are multiple ways for the
> > field to be entered into the system (such as multiple gui screens,
> > a conversion program, a batch
> > processing program, etc), there's no way to reuse this validation
> > logic.  It either isn't
> > performed relying on the database to throw an exception or it has
> > to be duplicated and kept in
> > sync with the gui logic.
> >
> > The idea I've been toying with would be a mechanism to allow
> > Stripes to use the Hibernate
> > validation extension annotations that can be used on the data
> > objects.  Yes, I know that this
> > would be Hibernate specific and subject to change and may not be
> > the best route to go.  But it
> > seems like it would be a useful way to specify validations that the
> > persistance layer and gui
> > layer could share.  The Hibernate validation annotations allow for
> > new validation annotations to
> > be created which would provide for expandability.  Ultimately it
> > would be nice to be able to use
> > the JSTL regular expression syntax in a new Hibernate validation
> > annotation to provide a ton of
> > flexibility.
> >
> > I've started prototyping a little code to see if this could be
> > accomplished without being
> > intrusive, ideally as some sort of plugin so that people who aren't
> > using Hibernate wouldn't be
> > affected at all, but I wanted to see what others thought before I
> > 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,
> >> 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,
> > 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
>


--
__
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