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
[email protected]
https://lists.sourceforge.net/lists/listinfo/stripes-users
