Help for truly reusable JSP tags in Stripes

[Christopher Maier-2]

I want to create some reusable JSP tag files for form fragments in my Stripes
application.  For example, say I have a "Foo" domain object that has a "Bar"
property that can be manipulated via a form.  It's easy to set up a form, using
field names like "foo.bar".  This assumes, of course, that the ActionBean
handling the form has a "Foo" property.

Say I also have a "Baz" domain object that has a "Foo" property, and that in
some situations, I need to manipulate a Foo object in the context of its owning
Baz instance in a form.  Assuming the ActionBean has a "Baz" property, I would
want my field labels to look like "baz.foo.bar" instead.

My problem derives from the fact that I'd like to have a reusable tag file
that encapsulates the details of a Foo object, such that I could include it
on forms where I need to edit a lone Foo object, as well as on forms for the
Baz object.    If my ActionBean already has a Baz property, I don't want to
add a Foo property just to use the tag file, and then have to manually wire up
that Foo with the Baz object.  I've got a rather intricately interconnected
domain model, and this approach will not scale well.

One solution I've hit upon is declaring the tag to take a String attribute that
I use to create the field names.  For example, I have fields in the JSP
declared like:

    <stripes:text name="${fooProperty}.bar"/>

In the case of editing a Foo object, you'd use "foo" as the value of
${fooProperty}.  In the case of a Baz object, you'd use "baz.foo" instead.

If I want to do anything in the tag that manipulates the actual Foo object
(e.g. EL tests), I don't know of a nice way to get a hold of that object from
the property string I passed in.  Ideally, I'd like to be able to do something
like this when I need the actual object:

    ${${fooProperty}}

That is, evaluate "fooProperty" to the string "baz.foo", and then evaluate
*that* to get to the actual Foo object (i.e. bazInstance.getFoo()).  Obviously,
that's not possible, since this is an invalid EL expression.

I thought of writing a custom EL function that uses an EL evaluator internally
so I could evaluate the property string how I want and return the object.  As
near as I can tell, however, I would have to pass the PageContext into the
function as well, which is pretty ugly.

Arguably as ugly, though considerably simpler to implement, is to require
another attribute on my JSP tag file that passes in the actual object as well.
This would end up looking something like this:

    <tags:myFooTag fooProperty="baz.foo" fooObject="${actionBean.baz.foo}"/>

Yes, it's redundant, but for simplicity and expediency, this is the approach
I've settled on.

With all that being said, is there a better way to do what I'm trying to do?


------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Stripes-users mailing list
Stripes-users@...
https://lists.sourceforge.net/lists/listinfo/stripes-users

[Freddy D.]

Hi Christopher,

Sorry that this reply comes over a month later. The reason is that
I've been thinking about this for over a month :-)

A recap of your post for those who'd like to follow along:

- I want to create some reusable JSP tag files for form fragments in
- my Stripes application.  For example, say I have a "Foo" domain
- object that has a "Bar" property that can be manipulated via a form.
- It's easy to set up a form, using field names like "foo.bar".  This
- assumes, of course, that the ActionBean handling the form has a
- "Foo" property.
-
- Say I also have a "Baz" domain object that has a "Foo" property, and
- that in some situations, I need to manipulate a Foo object in the
- context of its owning Baz instance in a form.  Assuming the
- ActionBean has a "Baz" property, I would want my field labels to
- look like "baz.foo.bar" instead.
-
- My problem derives from the fact that I'd like to have a reusable
- tag file that encapsulates the details of a Foo object, such that I
- could include it on forms where I need to edit a lone Foo object, as
- well as on forms for the Baz object. If my ActionBean already has a
- Baz property, I don't want to add a Foo property just to use the tag
- file, and then have to manually wire up that Foo with the Baz
- object. I've got a rather intricately interconnected domain model,
- and this approach will not scale well.
-
- One solution I've hit upon is declaring the tag to take a String
- attribute that I use to create the field names.  For example, I have
- fields in the JSP declared like:
-
-     <stripes:text name="${fooProperty}.bar"/>
-
- In the case of editing a Foo object, you'd use "foo" as the value of
- ${fooProperty}.  In the case of a Baz object, you'd use "baz.foo"
- instead.
-
- If I want to do anything in the tag that manipulates the actual Foo
- object (e.g. EL tests), I don't know of a nice way to get a hold of
- that object from the property string I passed in.  Ideally, I'd like
- to be able to do something like this when I need the actual object:
-
-     ${${fooProperty}}
-
- That is, evaluate "fooProperty" to the string "baz.foo", and then
- evaluate *that* to get to the actual Foo object (i.e.
- bazInstance.getFoo()).  Obviously, that's not possible, since
- this is an invalid EL expression.

At this point I'd like to point out that I *think* it is possible to
do what you describe: get a property from an object, where the name of
the property is dynamic. I've struggled with this a lot, and
unfortunately don't have the code with me anymore, but I think it was
something along the lines of:

    ${fooObject[fooProperty]}

That is, ${fooObject["bar"]} is equivalent to ${fooObject.bar}, but
with the [] notation, you can specify a variable instead of a static
string.

- I thought of writing a custom EL function that uses an EL evaluator
- internally so I could evaluate the property string how I want and
- return the object.  As near as I can tell, however, I would have to
- pass the PageContext into the function as well, which is pretty
- ugly.
-
- Arguably as ugly, though considerably simpler to implement, is to
- require another attribute on my JSP tag file that passes in the
- actual object as well.  This would end up looking something like
- this:
-
- <tags:myFooTag fooProperty="baz.foo"
-   fooObject="${actionBean.baz.foo}"/>
-
- Yes, it's redundant, but for simplicity and expediency, this is the
- approach I've settled on.

- With all that being said, is there a better way to do what I'm
- trying to do?

The problem that you've raised is quite interesting. I'm sure some JSP
gurus would be able to solve this problem, but I'm generally
dissatisfied with the way you can (or can't) solve such problems with
the tools that JSP gives you. Even if you're able to solve the
problem, I find that solutions often involve scattered bits and pieces
involving custom tags, parameters, referencing and dereferencing, and
so on. I think it should be easier to solve these kinds of problems.

The solution I'm thinking about is to use Velocity instead of JSPs,
along with a plugin that I am currently working on. The goal is to
make it a lot easier to "encapsulate" reusable fragments of view
template code such as you described above.

Now, I'm aware that this probably isn't a valid solution in your
current situation (ditch JSPs altogether), but I did want to engage
the discussion concerning alternative solutions to view templating
problems. Please stay tuned if you are interested.

Christopher, hopefully my reply is not completely useless because I
did address the issue of accessing a bean property in a dynamic
fashion. Try it out and let us know if that helps.

Cheers,
Freddy
http://www.stripesbook.com


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Stripes-users mailing list
Stripes-users@...
https://lists.sourceforge.net/lists/listinfo/stripes-users

[Christopher Maier-2]

Thanks for the thought you've given this, Freddy; I really appreciate
it.

> At this point I'd like to point out that I *think* it is possible to
> do what you describe: get a property from an object, where the name of
> the property is dynamic. I've struggled with this a lot, and
> unfortunately don't have the code with me anymore, but I think it was
> something along the lines of:
>
>     ${fooObject[fooProperty]}
>
> That is, ${fooObject["bar"]} is equivalent to ${fooObject.bar}, but
> with the [] notation, you can specify a variable instead of a static
> string.

I tried this approach a little after I sent out my initial post, and as I
recall, it does work, provided that "fooProperty" is a "simple" property,
and not a property path itself.  If fooProperty is the string
"prop.childProp" (the implication being that I want the object at
${fooObject.prop.childProp}), everything promptly blows up, since
there is no "prop.childProp" property of fooObject.

> The solution I'm thinking about is to use Velocity instead of JSPs,
> along with a plugin that I am currently working on. The goal is to
> make it a lot easier to "encapsulate" reusable fragments of view
> template code such as you described above.

It's funny you mention that: I recently stumbled across Velocity after
getting fed up with JSPs and it looks nice.  We've now got a
ticket in our issue tracker for looking further into alternatives like
Velocity or Freemarker so we can ultimately ditch JSPs.  Do you
know if it's possible to have one of these alternatives coexisting
with JSPs (so we could start migrating our pages over a bit at a
time), or would we have to switch all-at-once to the new view
technology?  Not that that'd be a deal breaker for us, but
a gradual path would be nicer since we're a small team.

What suppport for Velocity will your new plugin provide for Stripes?

Thanks again for your reply.  And thanks for the Stripes book; it's
quite the popular reference in our lab :)

Chris


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Stripes-users mailing list
Stripes-users@...
https://lists.sourceforge.net/lists/listinfo/stripes-users

[Mike McNally-3]

It'd not be terribly hard to implement an EL function to do the
traversal, especially with the Stripes utilities available. In fact
it'd be (in some ways) a handy thing, because another issue with
trying to re-use JSP code is that the system treats a missing map
property as simply a null value, while a missing bean property is an
exception. There's no good way that I know of  for reusable JSP code
to probe a bean and see whether a property is present. Of course doing
that in Java in an EL function wouldn't be hard at all.

I think that re-usable JSP code (or similar code in any template
library) leads to an even greater need for reusable validation
metadata.  If I want reusable template code for a Widget that's used
on several different actions, then surely I don't want to copy the
Widget @ValidateNestedProperties around in each action.


On Thu, Nov 5, 2009 at 10:15 AM, Christopher Maier <maier@...> wrote:

> Thanks for the thought you've given this, Freddy; I really appreciate
> it.
>
>> At this point I'd like to point out that I *think* it is possible to
>> do what you describe: get a property from an object, where the name of
>> the property is dynamic. I've struggled with this a lot, and
>> unfortunately don't have the code with me anymore, but I think it was
>> something along the lines of:
>>
>>     ${fooObject[fooProperty]}
>>
>> That is, ${fooObject["bar"]} is equivalent to ${fooObject.bar}, but
>> with the [] notation, you can specify a variable instead of a static
>> string.
>
> I tried this approach a little after I sent out my initial post, and as I
> recall, it does work, provided that "fooProperty" is a "simple" property,
> and not a property path itself.  If fooProperty is the string
> "prop.childProp" (the implication being that I want the object at
> ${fooObject.prop.childProp}), everything promptly blows up, since
> there is no "prop.childProp" property of fooObject.
>
>> The solution I'm thinking about is to use Velocity instead of JSPs,
>> along with a plugin that I am currently working on. The goal is to
>> make it a lot easier to "encapsulate" reusable fragments of view
>> template code such as you described above.
>
> It's funny you mention that: I recently stumbled across Velocity after
> getting fed up with JSPs and it looks nice.  We've now got a
> ticket in our issue tracker for looking further into alternatives like
> Velocity or Freemarker so we can ultimately ditch JSPs.  Do you
> know if it's possible to have one of these alternatives coexisting
> with JSPs (so we could start migrating our pages over a bit at a
> time), or would we have to switch all-at-once to the new view
> technology?  Not that that'd be a deal breaker for us, but
> a gradual path would be nicer since we're a small team.
>
> What suppport for Velocity will your new plugin provide for Stripes?
>
> Thanks again for your reply.  And thanks for the Stripes book; it's
> quite the popular reference in our lab :)
>
> Chris
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Stripes-users mailing list
> Stripes-users@...
> https://lists.sourceforge.net/lists/listinfo/stripes-users
>

--
Turtle, turtle, on the ground,
Pink and shiny, turn around.

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Stripes-users mailing list
Stripes-users@...
https://lists.sourceforge.net/lists/listinfo/stripes-users

[Newman, John W]

Freemarker's .vars['x']['y']['z'] trick can do what you describe.. we don't really use it that much but it has been a life saver here and there.  User defined directives (macros) are analogous to jsp's tag files - easily reusable fragments.

> It's funny you mention that: I recently stumbled across Velocity after
> getting fed up with JSPs and it looks nice.  We've now got a
> ticket in our issue tracker for looking further into alternatives like
> Velocity or Freemarker so we can ultimately ditch JSPs.  Do you
> know if it's possible to have one of these alternatives coexisting
> with JSPs (so we could start migrating our pages over a bit at a
> time), or would we have to switch all-at-once to the new view
> technology?  Not that that'd be a deal breaker for us, but
> a gradual path would be nicer since we're a small team.

I've been there.  I ended up going with FM since the syntax was actually readable.  After using it daily for 3 years, I don't hate it.  I hated jsp after 3 months.  Actually, much to the FM team's credit, the entire time I don't think there's been one instance of a major bug or lack of ability to do what is needed.  It's a quite a solid project really - the biggest drawback over jsp would be performance, which I have never measured.  

It should be possible to have .ftl and .jsp living together in the same app if you set the servlet mappings correctly.


-----Original Message-----
From: Mike McNally [mailto:emmecinque@...]
Sent: Thursday, November 05, 2009 11:40 AM
To: Stripes Users List
Subject: Re: [Stripes-users] Help for truly reusable JSP tags in Stripes

It'd not be terribly hard to implement an EL function to do the
traversal, especially with the Stripes utilities available. In fact
it'd be (in some ways) a handy thing, because another issue with
trying to re-use JSP code is that the system treats a missing map
property as simply a null value, while a missing bean property is an
exception. There's no good way that I know of  for reusable JSP code
to probe a bean and see whether a property is present. Of course doing
that in Java in an EL function wouldn't be hard at all.

I think that re-usable JSP code (or similar code in any template
library) leads to an even greater need for reusable validation
metadata.  If I want reusable template code for a Widget that's used
on several different actions, then surely I don't want to copy the
Widget @ValidateNestedProperties around in each action.


On Thu, Nov 5, 2009 at 10:15 AM, Christopher Maier <maier@...> wrote:

> Thanks for the thought you've given this, Freddy; I really appreciate
> it.
>
>> At this point I'd like to point out that I *think* it is possible to
>> do what you describe: get a property from an object, where the name of
>> the property is dynamic. I've struggled with this a lot, and
>> unfortunately don't have the code with me anymore, but I think it was
>> something along the lines of:
>>
>>     ${fooObject[fooProperty]}
>>
>> That is, ${fooObject["bar"]} is equivalent to ${fooObject.bar}, but
>> with the [] notation, you can specify a variable instead of a static
>> string.
>
> I tried this approach a little after I sent out my initial post, and as I
> recall, it does work, provided that "fooProperty" is a "simple" property,
> and not a property path itself.  If fooProperty is the string
> "prop.childProp" (the implication being that I want the object at
> ${fooObject.prop.childProp}), everything promptly blows up, since
> there is no "prop.childProp" property of fooObject.
>
>> The solution I'm thinking about is to use Velocity instead of JSPs,
>> along with a plugin that I am currently working on. The goal is to
>> make it a lot easier to "encapsulate" reusable fragments of view
>> template code such as you described above.
>
> It's funny you mention that: I recently stumbled across Velocity after
> getting fed up with JSPs and it looks nice.  We've now got a
> ticket in our issue tracker for looking further into alternatives like
> Velocity or Freemarker so we can ultimately ditch JSPs.  Do you
> know if it's possible to have one of these alternatives coexisting
> with JSPs (so we could start migrating our pages over a bit at a
> time), or would we have to switch all-at-once to the new view
> technology?  Not that that'd be a deal breaker for us, but
> a gradual path would be nicer since we're a small team.
>
> What suppport for Velocity will your new plugin provide for Stripes?
>
> Thanks again for your reply.  And thanks for the Stripes book; it's
> quite the popular reference in our lab :)
>
> Chris
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Stripes-users mailing list
> Stripes-users@...
> https://lists.sourceforge.net/lists/listinfo/stripes-users
>

--
Turtle, turtle, on the ground,
Pink and shiny, turn around.

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Stripes-users mailing list
Stripes-users@...
https://lists.sourceforge.net/lists/listinfo/stripes-users


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Stripes-users mailing list
Stripes-users@...
https://lists.sourceforge.net/lists/listinfo/stripes-users

[Freddy D.]

Hi Chris,

> > The solution I'm thinking about is to use Velocity instead of
> > JSPs, along with a plugin that I am currently working on. The goal
> > is to make it a lot easier to "encapsulate" reusable fragments of
> > view template code such as you described above.
>
> It's funny you mention that: I recently stumbled across Velocity
> after getting fed up with JSPs and it looks nice.  We've now got a
> ticket in our issue tracker for looking further into alternatives
> like Velocity or Freemarker so we can ultimately ditch JSPs.  Do you
> know if it's possible to have one of these alternatives coexisting
> with JSPs (so we could start migrating our pages over a bit at a
> time), or would we have to switch all-at-once to the new view
> technology?  Not that that'd be a deal breaker for us, but a gradual
> path would be nicer since we're a small team.

I'm fairly certain that you can have JSPs and Velocity or FreeMarker
coexist. After all, you forward to ".jsp" which is handled by the
servlet container, or you forward to ".ftl" or ".vm" which is handled
by the FreeMarkerServlet or the VelocityServlet that you've set up in
your web.xml file.

Right now the plugin that I'm working on uses Velocity. It probably
wouldn't be difficult to make it work with FreeMarker as well, but I'd
rather concentrate on finishing the plugin first. Also, I purposely
chose Velocity because of its simpler syntax. Yes, FreeMarker is more
powerful, but my goal is less logic in template code, not more! Of
course, you can choose *not* to use too much logic in your templates,
but you know what they say....if the weapons are there, people will
use them.

On the other hand, if you want to start *today* and/or don't want to
wait/depend on the plugin that I am working on, FreeMarker does
support JSP tag libraries, which you'll need if you're using Stripes
tags.

> > That is, ${fooObject["bar"]} is equivalent to ${fooObject.bar},
> > but with the [] notation, you can specify a variable instead of
> > a static string.
>
> I tried this approach a little after I sent out my initial post, and
> as I recall, it does work, provided that "fooProperty" is a "simple"
> property, and not a property path itself.  If fooProperty is the
> string "prop.childProp" (the implication being that I want the
> object at ${fooObject.prop.childProp}), everything promptly
> blows up, since there is no "prop.childProp" property of fooObject.

For what it's worth, in Velocity, you can do this:

  ## say $object is your bean and $propertyName is "prop.childProp"
 
  #set($expr = "\$object." + $propertyName)
  #evaluate($expr)

> What support for Velocity will your new plugin provide for Stripes?

Velocity does not have tag library support. In my plugin, I wrap
Stripes tags in Java objects, which you create in Java code and then
just drop into your Velocity templates.

For example, instead of this:

<s:link beanclass="com.example.action.AnotherActionBean" event="view">  
  <s:param name="personId" value="${actionBean.personId}"/>  
  <fmt:message key="link.label"/>  
</s:link>

You'd write:

public SLink getLink() {  
  return tag(SLink.class).beanclass(AnotherActionBean.class).event("view")  
    .param("personId", getPersonId())  
    .label(bundle.get("link.label"));  
}  

And add the link to your template with $actionBean.link

Velocity Tools has a LayoutServlet which works quite nicely; my plugin
has a Quickstart that sets up a project for you, including the
LayoutServlet. This along with some conveniences that I provide in the
plugin allows you to use layouts even more concisely than with Stripes
tags.

The plugin also has a concept of "View templates", which is inspired
from frameworks such as Apache Click and Apache Wicket. These are Java
objects have have an associated template, and that you can instantiate
and add to a page. I don't want to talk about "components" here
because that is an overloaded term; and besides, these are not
components in the "component framework", stateful sense. Instead, they
are just chunks of view code that you can encapsulate so that you can
build pages in a neater fashion, by assembling these chunks together
into a page. This is the area where I was thinking that perhaps you
can implement a solution for your reusable form sections that edit an
object of your model.

I'm working hard to get a first beta version out with some
documentation so that people can take it out for a test drive. I'll
let you know as soon as I have something decent ready!

> Thanks again for your reply.  And thanks for the Stripes book; it's
> quite the popular reference in our lab :)

Very happy to hear that :) Thanks for your kind comments!

Cheers,
Freddy
http://www.stripesbook.com


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Stripes-users mailing list
Stripes-users@...
https://lists.sourceforge.net/lists/listinfo/stripes-users

[Freddy D.]

Hi Mike,

> ... leads to an even greater need for reusable validation
> metadata.  If I want reusable template code for a Widget that's used
> on several different actions, then surely I don't want to copy the
> Widget @ValidateNestedProperties around in each action.

That's a good point. That's exactly why I'm wondering if a plugin to
integrate something like Hibernate Validator (where you have validation
annotations on your model class) would be useful. In fact, I wrote such
a plugin as a proof of concept, but haven't had the chance to really
pound on it to see if there are problems with this concept.

What do you think?

Cheers,
Freddy
http://www.stripesbook.com



------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Stripes-users mailing list
Stripes-users@...
https://lists.sourceforge.net/lists/listinfo/stripes-users

[Mike McNally-3]

My (not mine alone of course) Stripes application has its own subclass
of ValidationMetadataProvider that does this work (along with another
annotation, "@ValidateFrom").  Our metadata provider dives into member
objects and returns structures that look like what you'd get from
@ValidateNestedProperties.  It's not very sophisticated and it's got
rough spots, but it does to a few interesting things (like pick up
"length" from JPA annotations). The "@ValidateFrom" can also be used
to refer to specific properties of other objects, in case an action
isn't directly messing with a model object.  Thus,
@ValidateFrom(beanclass=UserSeurity.class, property="password") lets
you keep things like password length in a single place.

One of the ugly parts is determining whether the validation
annotations go directly on model objects or on intermediate business
logic classes (which for some people might be Stripes actions of
course) is sometimes a head-scratcher.  Really it's the "required"
property that causes the most problems, but there are other issues as
well.

I haven't looked at the Hibernate thing much (we don't use Hibernate),
but it seems like something that could mine that information and
present the Stripes validation code with the metadata it expects would
be useful.


It's a testimony to the Stripes design that the
ValidationMetadataProvider subclass was one of the very first things I
did with Stripes, and even in the stage of barely understanding what
was going on it was pretty easy to do.


On Thu, Nov 5, 2009 at 11:45 AM, Freddy Daoud <xf2697@...> wrote:

> Hi Mike,
>
>> ... leads to an even greater need for reusable validation
>> metadata.  If I want reusable template code for a Widget that's used
>> on several different actions, then surely I don't want to copy the
>> Widget @ValidateNestedProperties around in each action.
>
> That's a good point. That's exactly why I'm wondering if a plugin to
> integrate something like Hibernate Validator (where you have validation
> annotations on your model class) would be useful. In fact, I wrote such
> a plugin as a proof of concept, but haven't had the chance to really
> pound on it to see if there are problems with this concept.
>
> What do you think?
>
> Cheers,
> Freddy
> http://www.stripesbook.com
>
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Stripes-users mailing list
> Stripes-users@...
> https://lists.sourceforge.net/lists/listinfo/stripes-users
>

--
Turtle, turtle, on the ground,
Pink and shiny, turn around.

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Stripes-users mailing list
Stripes-users@...
https://lists.sourceforge.net/lists/listinfo/stripes-users

[Freddy D.]

Hi Mike,

> One of the ugly parts is determining whether the validation
> annotations go directly on model objects or on intermediate business
> logic classes (which for some people might be Stripes actions of
> course) is sometimes a head-scratcher.  Really it's the "required"
> property that causes the most problems, but there are other issues as
> well.

Indeed, these are the kinds of issues that cause me some head-scratching
when I'm thinking about the integration of bean validation.

> I haven't looked at the Hibernate thing much (we don't use Hibernate),
> but it seems like something that could mine that information and
> present the Stripes validation code with the metadata it expects would
> be useful.

I said Hibernate Validator, but really it is not Hibernate-specific
anymore; it's become the JSR 303[1]: Bean Validation of which it is the
reference implementation. Sorry to cause some confusion there.

A while back I had looked at oVal[2], which remains interesting but
is not as well known as the "standard" JSR and the big name Hibernate.

Then again, Stripes suffers from the same kind of discrimination
vs. say JSF. But, I digress...

[1]: http://jcp.org/en/jsr/detail?id=303
[2]: http://oval.sourceforge.net

Cheers,
Freddy
http://www.stripesbook.com



------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Stripes-users mailing list
Stripes-users@...
https://lists.sourceforge.net/lists/listinfo/stripes-users

[VANKEISBELCK Remi-2]

Interesting...

I currently use a dynamic approach for handling validation with
Hibernate. I simply call the HibernateValidation code directly, and
translate to Stripes error objects.
I think Patrick Lightbody is also doing it by translating the
validation metadata, i.e. create Stripes specific Validation  info by
introspecting the constraints defined in the mapping...
Of course the dynamic version doesn't require any effort, Hibernate
already does it fine so you just delegate to it. But you don't have
the same integration level (e.g. messages are those from Hibernate
etc.). In the end, I think the metadata translation approach pays
off...

That'd be a nice addition to Stripersist... Something I really regret
from the previous "Stripernate" and its validation package. Ok, you
had to write the 'validate(...)' call into your setters, this was not
terribly sexy. But in the end, it worked fine and it was integrated to
Stripes... I've been a big fan :P

The best would be a plugin that allows reuse of standard Bean
Validation annotations on your model, just like the regular Stripes
Validation stuff...

Cheers

Remi

2009/11/5 Mike McNally <emmecinque@...>:

> My (not mine alone of course) Stripes application has its own subclass
> of ValidationMetadataProvider that does this work (along with another
> annotation, "@ValidateFrom").  Our metadata provider dives into member
> objects and returns structures that look like what you'd get from
> @ValidateNestedProperties.  It's not very sophisticated and it's got
> rough spots, but it does to a few interesting things (like pick up
> "length" from JPA annotations). The "@ValidateFrom" can also be used
> to refer to specific properties of other objects, in case an action
> isn't directly messing with a model object.  Thus,
> @ValidateFrom(beanclass=UserSeurity.class, property="password") lets
> you keep things like password length in a single place.
>
> One of the ugly parts is determining whether the validation
> annotations go directly on model objects or on intermediate business
> logic classes (which for some people might be Stripes actions of
> course) is sometimes a head-scratcher.  Really it's the "required"
> property that causes the most problems, but there are other issues as
> well.
>
> I haven't looked at the Hibernate thing much (we don't use Hibernate),
> but it seems like something that could mine that information and
> present the Stripes validation code with the metadata it expects would
> be useful.
>
>
> It's a testimony to the Stripes design that the
> ValidationMetadataProvider subclass was one of the very first things I
> did with Stripes, and even in the stage of barely understanding what
> was going on it was pretty easy to do.
>
>
> On Thu, Nov 5, 2009 at 11:45 AM, Freddy Daoud <xf2697@...> wrote:
>> Hi Mike,
>>
>>> ... leads to an even greater need for reusable validation
>>> metadata.  If I want reusable template code for a Widget that's used
>>> on several different actions, then surely I don't want to copy the
>>> Widget @ValidateNestedProperties around in each action.
>>
>> That's a good point. That's exactly why I'm wondering if a plugin to
>> integrate something like Hibernate Validator (where you have validation
>> annotations on your model class) would be useful. In fact, I wrote such
>> a plugin as a proof of concept, but haven't had the chance to really
>> pound on it to see if there are problems with this concept.
>>
>> What do you think?
>>
>> Cheers,
>> Freddy
>> http://www.stripesbook.com
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
>> trial. Simplify your report design, integration and deployment - and focus on
>> what you do best, core application coding. Discover what's new with
>> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>> _______________________________________________
>> Stripes-users mailing list
>> Stripes-users@...
>> https://lists.sourceforge.net/lists/listinfo/stripes-users
>>
>
>
>
> --
> Turtle, turtle, on the ground,
> Pink and shiny, turn around.
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Stripes-users mailing list
> Stripes-users@...
> https://lists.sourceforge.net/lists/listinfo/stripes-users
>

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Stripes-users mailing list
Stripes-users@...
https://lists.sourceforge.net/lists/listinfo/stripes-users

[Freddy D.]

Hi Remi,

> I currently use a dynamic approach for handling validation with
> Hibernate. I simply call the HibernateValidation code directly, and
> translate to Stripes error objects.
> Of course the dynamic version doesn't require any effort, Hibernate
> already does it fine so you just delegate to it. But you don't have
> the same integration level (e.g. messages are those from Hibernate
> etc.). In the end, I think the metadata translation approach pays
> off...

Indeed. This is what I do in my plugin as well. I just have a custom
exception handler that translates Hibernate Validator exceptions to
Stripes error messages. I don't even have to call the validator; I set
up JPA/Hibernate so that Hibernate calls the validator automatically
for you.

> The best would be a plugin that allows reuse of standard Bean
> Validation annotations on your model, just like the regular Stripes
> Validation stuff...

True, that would be more work but would provide tighter integration.

Cheers,
Freddy
http://www.stripesbook.com


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Stripes-users mailing list
Stripes-users@...
https://lists.sourceforge.net/lists/listinfo/stripes-users