I've been thinking of implementing this feature lately and I haven't
seen it proposed on this list yet. Any comments?
Summary:
Provide a means to flexibly plug in transformations that could
be applied to JavaBean properties for presentation in a JSP page.
What transformation to apply to which Ja
You can check the latest version of Strut by Strut. There are some
"stub" versions of what I use for value object there. Though, my
implementation is rather straight-forward, since I am not trying to hook
these up with enterprise beans, just use the same general design
pattern.
As a convenience,
On Wed, 30 May 2001, Rapheal Kaplan wrote:
> Has anyone thought about allowing for string based indexed fields (even
> though they do not fit in to the Java spec)?
>
> For example:
>
>
>
> would call:
>
> user.getEmail( "home" );
>
>
> -
On Wed, 30 May 2001, Jonathan Asbell wrote:
> Craig, that was the most excellent explanation.
Thanks.
> What currently IS available
> for use regarding the automatic properties, and how may I use them? I
> download the nightly builds ;^>
There's nothing in the "official" builds at the mome
Has anyone thought about allowing for string based indexed fields (even
though they do not fit in to the Java spec)?
For example:
would call:
user.getEmail( "home" );
- Rapheal Kaplan
Great explanation Ted. I am interested in your implementation of the
ValueObjects. It appears as though you dont use the ActionForm as a value
object, but rather pass the ActionForm beans values on to the value object
after validating symantics in the Action. Is this true? I ask because I
have
Craig, that was the most excellent explanation. What currently IS available
for use regarding the automatic properties, and how may I use them? I
download the nightly builds ;^>
- Original Message -
From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECT
Jonas Bjornerstedt wrote:
> I see little reason (yet) why the ActionForm should be modeled as such.
I think the keyword here is "yet". Much of the underlying Struts designs
are based on trends and patterns that have yet to reach their logical
conclusion.
For example, future Java design tools ar
craigmcc01/05/30 19:02:29
Modified:doc index.xml
Log:
Port the documentation change to the HEAD branch.
Revision ChangesPath
1.3 +6 -3 jakarta-struts/doc/index.xml
Index: index.xml
===
craigmcc01/05/30 19:01:38
Modified:doc Tag: STRUTS_1_0_BRANCH index.xml
Log:
Specifically identify the location of the source code download for the
1.0-b2 release.
Revision ChangesPath
No revision
No revision
1.2
On Wed, 30 May 2001, William Shulman wrote:
>
> > The problem with your suggestion of implementing this using the Struts
> > BeanUtils is that it has been deprecated because its been donated to the
> > Jakarta Commons project. I understand Struts will be changed to use the
> > Jakarta Comm
> > The problem with your suggestion of implementing this using the Struts
> > BeanUtils is that it has been deprecated because its been
> donated to the
> > Jakarta Commons project. I understand Struts will be changed to use the
> > Jakarta Commons version in 1.1. BeanUtils are "utility metho
> The problem with your suggestion of implementing this using the Struts
> BeanUtils is that it has been deprecated because its been donated to the
> Jakarta Commons project. I understand Struts will be changed to use the
> Jakarta Commons version in 1.1. BeanUtils are "utility methods for
>
The problem with your suggestion of implementing this using the Struts
BeanUtils is that it has been deprecated because its been donated to the
Jakarta Commons project. I understand Struts will be changed to use the
Jakarta Commons version in 1.1. BeanUtils are "utility methods for
populating Java
Johan
I take that as definite No! with no room for negotiation - oh shit, better
tell my boss I did it all wrong ;)
As I said to William...
The problem of implementing this using the Struts BeanUtils is that it has
been deprecated because its been donated to the Jakarta Commons project -
will w
> Dynamic properties are a very very very heavily requested feature, and
> will undoubtedly be addressed early in the Struts 1.1 development
> cycle. Supporting them elegantly is more than just a couple of tweaks
> here and there, so we want to make sure that we've got all the bases
> covered wit
Thanks for taking some time to answer my "naiive question.
>
> I think you've really got two threads of questions here, so
> let me try to
> address them separately.
>
> (1) Why use getXxx and setXxx for properties?
>
> This is a general design pattern called JavaBeans, and you
> will find it ver
If someone were to do as you suggest, then Struts would not be adding much
to the Servlet specification, namely an HttpServletRequest. If getting
values from a hashtable is all you want, use HttpServletRequest.
HttpServletRequest is generic enough to handle all values, and like Perl,
turns everyt
On Wed, 30 May 2001, Jonas Bjornerstedt wrote:
> Although you get basic type conversion with the getter/setter methods, it is
> not a convincing argument. The price you pay for getting something that is
> rather simple, is that 1) you have to always extend ActionForm 2) often use
> reflection /
Although you get basic type conversion with the getter/setter methods, it is
not a convincing argument. The price you pay for getting something that is
rather simple, is that 1) you have to always extend ActionForm 2) often use
reflection / PropertyUtils to get the information out.
Wouldn't it be
> In a Been, you can use a Hashtable to save your attributes,
> but you don't have to use a Hashtable. I normaly don't.
> Because I know which attributes to expect, I implement these
> as fields in the Bean, and save the values in these. I know
> that a Hashtable has an expected constant-time on t
I wanted to crank out a prototype of something and
didn't want to make all of the setter/getter methods
so I modified PropertyUtils to handle java.util.Map.
I posted some source, but other people have cleaner OO
implementation ideas that they have posted. Something
along this idea is scheduled i
- Original Message -
From: "Jonas Björnerstedt" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, May 30, 2001 4:55 PM
Subject: Bean philosophy
> Having just switched from Perl to Java web development, perhaps I am missing
> something fundamental. Being new to the for
Having just switched from Perl to Java web development, perhaps I am missing
something fundamental. Being new to the forum, I also don't know if this
issue has been discussed before.
It strikes me as odd that in beans in general and ActionForm beans in
particular that properties are set by setXx
I agree with William 100%.
I have to admit I was guilty of doing in my jpath code
something similar to what David is doing, simply
because I needed the functionality and I could not
easily customize BeanUtils. Here's what I did: I
introduced a DynamicPropertyHandler interface, which
is like Dy
You got my Vote (see my other mail)
Johan Compagner
> I think this *may* solve the problem at the wrong level of
> abstraction. The
> concept of Dynamic Properties, while useful in dealing with forms, has
> nothing to do with forms and ActionForms intrinsicly. Dynamic
> Properties should be av
> 1) Created a "DynamicProperties" interface which has the
> following methods:
>
> public String getValue(String property);
> public String getValue(int index, String property);
> public void setValue(String property, String value);
> public void setValue(int index, String
27 matches
Mail list logo
