> > >This idea came up in the original thread, but no one stepped forward >with any code. > It has my interest. I'll first take a squizz at the target areas, generate a hack version, look at the viability, and see what happens from there.
>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. > How does the current buffering mechanism do its thing for flat beans?... Is there a short answer without telling me to go read the code?... :) Arron. > > >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]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
