This idea came up in the original thread, but no one stepped forward with any code.
The one and only time there is a problem is when the nested object makes a direct and immediate change to the internal system state. So long as the nested object is buffering the input, and can be validated before any change is committed, then it's a non-issue. Arron Bates wrote: > > Not a special class, I'm talking about placing it into the process. > Before the servlet updates the properties it checks for a security > mapping. Based on the request and the security, it updates the > properties. It would be more secure, and every property which is up to > be set, can rest assured that it's safe. And that includes the > properties that we "mean to expose" nested or otherwise. > > All amounting to better security and an easier development path for the > developers. > I've had to use a decoupling through nested objects for an app that's in > development. 100's of input fields. Writing proxy classes for it all. > You have to be kidding. > > Ted, there are some requirements out there where you *must* use nested > objects. > When is Struts going to *properly* support this!!??... > > Arron. > > Ted Husted wrote: > > >Personally, I have the feeling that it's better to encourage people to > >define a proxy object, or wrapper, as was done with the ActionServlet, > >than invent a special class for people to learn. > > > >I actually believe that this is the approach that should have been used > >in the first place, and in other places in the codebase. The > >ActionServlet was placed there to provide access to certain properties, > >and now the wrapper object defines exactly which properties those are. > >An Encapsulate Class refactoring, if you will. > > > >Meanwhile, I'm suggesting that we do the same sort of thing with > >multiple ActionSerlvets in another thread. Instead of exposing the > >ActionServlet, we should expose a JavaBean with only the properites we > >mean to expose. > > > >I think the important thing is to pound on the point that the ActionForm > >is a firewall; it, and any objects it nests, are in the wild. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
