You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Stefan Wachter <st...@gmx.de> on 2001/11/26 11:52:39 UTC
Re: Re[2]: Fwd: Re: Extensibility of struts
Hi Oleg,
for our current problem the first option is the better solution because it
does not require to repeat in all JSPs the on... attributes. The overloaded
tag class can automatically append some javascript code without a JSP
developer
even to know about it. In this case the only thing of struts that we have to
patch is the tld which is acceptable.
The second option is also a great idea because then javascript logic is no
longer scattered everywhere but can be centralized. I think lots of
developers
would be very grateful to have this possiblity.
However in our case the (automatically added) javascript code is already
centralized in the overloading classes. To be able to configure it we would
need
some session- or application-scope object where we could define such global
settings for all html-elements of certain kinds. I think this would be a big
undertaking but maybe it would be enough to define somewhere default values
for all attributes of all JSP tags.
To summarize: we are completely happy if just the member access in the tags
is replaced by getter methods.
Ciao,
Stefan
> Hello Stefan,
>
> How do you want to specify default javascript code for tags? I view
> two ways to do so (all this variants uses your model - with proxy
> getXXX() methods and avoid direct variable values retrieving) -
>
> 1. Extend html:input tag with your own tag and reload all
> getXXXJscriptCode methods to generate default client side code.
> 2. Write new version of html:input tag with support of resource
> strings. So developer can specify key to retrieve string from
> resources and use it as attribute value -
>
> <html:input name="someField" onKeyDown="javascript:alert('Wow!')"/>
> <html:input name="someField" onKeyDownKey="javascript.alert.field"/>
>
> Last example uses key 'javascript.alert.field' to retrieve value
> from resources.
>
> I think that second method is more powerful and flexible. Is it
> way to solve your problem?
>
> Thursday, November 22, 2001, 10:29:28 AM, you wrote:
>
> SW> Hi Oleg,
>
> SW> we want to add automaticallly additional javascript code to all input
> SW> fields, links, and (non-submitting) buttons to implement a
> dirty-check-mechanism.
>
> SW> The original problem is that if some enters lots of data in a form and
> then
> SW> clicks a link then all the the entered form data is lost. Our customer
> does
> SW> not accept this behaviour (because many unskilled people use the
> application).
> SW> Therefore we added onchange-javascript-code to all input fields and
> SW> checking-javascript-code to all links and (non-submitting) buttons.
> Now in case of
> SW> dirtyness of a form a dialog pops up saying that the entered data will
> be lost
> SW> and allowing to cancel the request.
>
> SW> We already use the <html:input>-tags in all our JSPs but we don't want
> to
> SW> have the necessary javascript code repeated everywhere (for
> consistency and
> SW> maintainance reasons). Therefore we want the necessary javascript code
> to be
> SW> added automatically.
>
> SW> If you think our solution is general enough then maybe this behaviour
> could
> SW> also be directly incorparted into struts.
>
> SW> Ciao,
> SW> --Stefan
>
> >> Hello Stefan,
> >>
> >> Wednesday, November 21, 2001, 6:33:38 PM, you wrote:
> >>
> >> SW> our first proposal concerning the extensibility of struts concerns
> the
> >> SW> html-taglib. Currently in the
> org.apache.struts.taglib.BaseHandlerTag
> >> the
> >> SW> members
> >> SW> (onClick, onDblClick, ...) are directly accessed. If the prepare
> >> methods
> >> SW> would use getter methods then you could easily extend the tags by
> >> SW> overloading the
> >> SW> getter method:
> >>
> >> SW> Current version of BaseHandler has methods like this:
> >>
> >> SW> private void prepareKeyEvents(StringBuffer handlers) {
> >>
> >> SW> if (onKeyDown != null) {
> >> SW> handlers.append(" onKeyDown=\"");
> >> SW> handlers.append(onKeyDown);
> >> SW> handlers.append("\"");
> >> SW> }
> >>
> >> SW> if (onKeyUp != null) {
> >> SW> handlers.append(" onKeyUp=\"");
> >> SW> handlers.append(onKeyUp);
> >> SW> handlers.append("\"");
> >> SW> }
> >>
> >> SW> if (onKeyPress != null) {
> >> SW> handlers.append(" onKeyPress=\"");
> >> SW> handlers.append(onKeyPress);
> >> SW> handlers.append("\"");
> >> SW> }
> >> SW> }
> >>
> >> SW> Our proposed version is:
> >>
> >> SW> private void prepareKeyEvents(StringBuffer handlers) {
> >>
> >> SW> if (getOnKeyDown() != null) {
> >> SW> handlers.append(" onKeyDown=\"");
> >> SW> handlers.append(getOnKeyDown());
> >> SW> handlers.append("\"");
> >> SW> }
> >>
> >> SW> if (getOnKeyUp() != null) {
> >> SW> handlers.append(" onKeyUp=\"");
> >> SW> handlers.append(getOnKeyUp());
> >> SW> handlers.append("\"");
> >> SW> }
> >>
> >> SW> if (getOnKeyPress() != null) {
> >> SW> handlers.append(" onKeyPress=\"");
> >> SW> handlers.append(getOnKeyPress());
> >> SW> handlers.append("\"");
> >> SW> }
> >> SW> }
> >>
> >> SW> Admittedly this is not a great change, but it would help
> extensibility
> >> a
> >> SW> lot. Who decides if this proposal is incorporated into the next
> >> version?
> >>
> >> SW> I will send you some more proposals soon.
> >>
> >> It is good addition. But what reason to do so? Can you explain any
> >> situation when such methods can be used?
> >>
> --
> Best regards,
> Oleg mailto:gonza@penza.net
>
>
--
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Tomcat 4.0 and Digester
Posted by Bo Majewski <ma...@cisco.com>.
I've been digging through the struts-dev mailing list but had no luck,
hence this e-mail. I seem to have a problem running Struts 1.0 and Tomcat
4.0.1. The digester does not work correctly, unless I place parser.jar in
the WEB-INF/lib directory. If Tomcat uses xerces.jar I never get call-backs
on certain methods. Is anybody familiar with this? Is it a new problem, a
known problem? What is a solution, except for removing xerces and using
parser.jar? Thanks!
Bo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Fwd: Re: Extensibility of struts... a solution, maybe
Posted by Ted Husted <hu...@apache.org>.
It's true that I don't have the bandwidth right now to take a careful
look at your code, but I'm sure its quite good. It's linked both on my
site and the Struts resource page, and I'm sure people are getting value
from it.
My statement about nesting objects on ActionForm does hold. Strut's
autopopulate mechanism can be exploited if nested object have public
String or boolean properties that affect the system state. In Struts
1.0, you can do things like change the temporary directory for uploads
from a browser. We made this mistake on the original design of the
ActionForm, and I'm just trying to bring this to people's attention
whenever I can. I do not mean to discourage people from using nested
objects, only to use them wisely. Forewarned is forearmed.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4997
If your code provides an additional firewall, then a discussion of that
might be helpful, and draw more people into your package.
Arron wrote:
>
> That was kind of an ignorant comment. I don't know why you people
> resisting it so much.
> There is no danger in nesting objects at all.
>
> It is possible (however truly ugly) to do the same thing in out of the
> box struts. It's all about getting the JSP's to elegantly manage data
> structures you're most likely already using to some point. They release
> it to go free and make life terribly easier..
>
> Take a look at the code. They really do sit on struts. It relies on
> struts to do what it does. They only guide the struts tags to write out
> the write properties for things and fetch the right data. ALL the brains
> of it are a 38 line method.
> org.apache.struts.taglib.nested.NestedPropertyHelper.
> Please read it, I 'aint lyin'. :)
>
> At the risk of sounding cocky, the nested system introduces nothing but
> elegant data modelling and management.
>
> The rest (which takes more talent) I willingly leave to the rest of you
> boys. I just managed to finish something that I can't believe was left
> out. It really was 95% done for me.
>
> Stuts rocks, but this just lined it a little for the boys that have to
> cut it.
> It does cut developer time.
>
> Arron.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re[2]: Extensibility of struts & Property Security
Posted by Oleg V Alexeev <go...@penza.net>.
Hello Arron,
Ideas... Great.
I think that source code samples can be more useful than abstract
ideas in free style. Every developer in this list has his own work and
doing struts-related activity by his free time.
If you can help in this way to the community, please post code and
config samples to the list.
Wednesday, November 28, 2001, 5:22:45 PM, you wrote:
A> No code, just an idea after Ted provided a link to a thread of mails
A> that had to do with the original problem of getting at the struts system
A> objects.
A> But I'm lookin into it.
A> I'll get back to ya, but should be able to get a mock set-up running of
A> the idea itself...
A> ...then the debate can start as to the syntax of configuring it, and
A> when, should it be a singleton, ad-infinitum. :)
A> Arron
A> Oleg V Alexeev wrote:
>>Hello Arron,
>>
>>I think that it is intersting and flexible approach. Can you supply
>>samples for it or refactor existing code to support such ideas?
>>
>>Wednesday, November 28, 2001, 6:37:06 AM, you wrote:
>>
>>AB> Not a special class, I'm talking about placing it into the process.
>>AB> Before the servlet updates the properties it checks for a security
>>AB> mapping. Based on the request and the security, it updates the
>>AB> properties. It would be more secure, and every property which is up to
>>AB> be set, can rest assured that it's safe. And that includes the
>>AB> properties that we "mean to expose" nested or otherwise.
>>
>>AB> All amounting to better security and an easier development path for the
>>AB> developers.
>>AB> I've had to use a decoupling through nested objects for an app that's in
>>AB> development. 100's of input fields. Writing proxy classes for it all.
>>AB> You have to be kidding.
>>
>>AB> Ted, there are some requirements out there where you *must* use nested
>>AB> objects.
>>AB> When is Struts going to *properly* support this!!??...
>>
>>
>>AB> Arron.
>>
>>AB> 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.
>>>>
>>>>Arron Bates wrote:
>>>>
>>>>> Yes, yes. Point made.
>>>>>That series of emails makes for some good bedside reading.
>>>>>
>>>>>I think that the solution that was arrived at is fine for protecting the
>>>>>struts system objects themselves.
>>>>>Is there anything happening to allow the developer to protect their own
>>>>>properties from this kind of arbitrary attack?
>>>>>
>>>>>Thought I had would be to configure a property modifier, or property
>>>>>mapping which yields other "security properties" which have to be
>>>>>checked before a property is set. ie: getMyProperty() property method
>>>>>uses a getMyPropertySecurity() to return a defined value which was set
>>>>>while writing the view so you can't just pass the one key value pair to
>>>>>change a value, but a two key value pairs with the second value being a
>>>>>specific hashing or such. This would stop the casual hacking of any
>>>>>property via the URL. You could also then define a security property for
>>>>>all things struts within the ActionForm.
>>>>>
>>>>>The possibility then in extending this would be to define a security
>>>>>property to each property to be set, or a more simpler global security
>>>>>property for the entire request, and let the developer decide as to how
>>>>>fine grained the property setting security should be, if at all.
>>>>>
>>>>>Just a thought.
>>>>>
>>>>>Arron.
>>>>>
>>>>--
>>>>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>>>>For additional commands, e-mail: <ma...@jakarta.apache.org>
>>>>
>>
>>
>>
>>AB> --
>>AB> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>>AB> For additional commands, e-mail: <ma...@jakarta.apache.org>
>>
>>
>>
A> --
A> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
A> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
Best regards,
Oleg mailto:gonza@penza.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Extensibility of struts & Property Security
Posted by Arron <ar...@keyboardmonkey.com>.
No code, just an idea after Ted provided a link to a thread of mails
that had to do with the original problem of getting at the struts system
objects.
But I'm lookin into it.
I'll get back to ya, but should be able to get a mock set-up running of
the idea itself...
...then the debate can start as to the syntax of configuring it, and
when, should it be a singleton, ad-infinitum. :)
Arron
Oleg V Alexeev wrote:
>Hello Arron,
>
>I think that it is intersting and flexible approach. Can you supply
>samples for it or refactor existing code to support such ideas?
>
>Wednesday, November 28, 2001, 6:37:06 AM, you wrote:
>
>AB> Not a special class, I'm talking about placing it into the process.
>AB> Before the servlet updates the properties it checks for a security
>AB> mapping. Based on the request and the security, it updates the
>AB> properties. It would be more secure, and every property which is up to
>AB> be set, can rest assured that it's safe. And that includes the
>AB> properties that we "mean to expose" nested or otherwise.
>
>AB> All amounting to better security and an easier development path for the
>AB> developers.
>AB> I've had to use a decoupling through nested objects for an app that's in
>AB> development. 100's of input fields. Writing proxy classes for it all.
>AB> You have to be kidding.
>
>AB> Ted, there are some requirements out there where you *must* use nested
>AB> objects.
>AB> When is Struts going to *properly* support this!!??...
>
>
>AB> Arron.
>
>AB> 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.
>>>
>>>Arron Bates wrote:
>>>
>>>> Yes, yes. Point made.
>>>>That series of emails makes for some good bedside reading.
>>>>
>>>>I think that the solution that was arrived at is fine for protecting the
>>>>struts system objects themselves.
>>>>Is there anything happening to allow the developer to protect their own
>>>>properties from this kind of arbitrary attack?
>>>>
>>>>Thought I had would be to configure a property modifier, or property
>>>>mapping which yields other "security properties" which have to be
>>>>checked before a property is set. ie: getMyProperty() property method
>>>>uses a getMyPropertySecurity() to return a defined value which was set
>>>>while writing the view so you can't just pass the one key value pair to
>>>>change a value, but a two key value pairs with the second value being a
>>>>specific hashing or such. This would stop the casual hacking of any
>>>>property via the URL. You could also then define a security property for
>>>>all things struts within the ActionForm.
>>>>
>>>>The possibility then in extending this would be to define a security
>>>>property to each property to be set, or a more simpler global security
>>>>property for the entire request, and let the developer decide as to how
>>>>fine grained the property setting security should be, if at all.
>>>>
>>>>Just a thought.
>>>>
>>>>Arron.
>>>>
>>>--
>>>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>>>For additional commands, e-mail: <ma...@jakarta.apache.org>
>>>
>
>
>
>AB> --
>AB> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>AB> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re[2]: Extensibility of struts & Property Security
Posted by Oleg V Alexeev <go...@penza.net>.
Hello Arron,
I think that it is intersting and flexible approach. Can you supply
samples for it or refactor existing code to support such ideas?
Wednesday, November 28, 2001, 6:37:06 AM, you wrote:
AB> Not a special class, I'm talking about placing it into the process.
AB> Before the servlet updates the properties it checks for a security
AB> mapping. Based on the request and the security, it updates the
AB> properties. It would be more secure, and every property which is up to
AB> be set, can rest assured that it's safe. And that includes the
AB> properties that we "mean to expose" nested or otherwise.
AB> All amounting to better security and an easier development path for the
AB> developers.
AB> I've had to use a decoupling through nested objects for an app that's in
AB> development. 100's of input fields. Writing proxy classes for it all.
AB> You have to be kidding.
AB> Ted, there are some requirements out there where you *must* use nested
AB> objects.
AB> When is Struts going to *properly* support this!!??...
AB> Arron.
AB> 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.
>>
>>Arron Bates wrote:
>>
>>> Yes, yes. Point made.
>>>That series of emails makes for some good bedside reading.
>>>
>>>I think that the solution that was arrived at is fine for protecting the
>>>struts system objects themselves.
>>>Is there anything happening to allow the developer to protect their own
>>>properties from this kind of arbitrary attack?
>>>
>>>Thought I had would be to configure a property modifier, or property
>>>mapping which yields other "security properties" which have to be
>>>checked before a property is set. ie: getMyProperty() property method
>>>uses a getMyPropertySecurity() to return a defined value which was set
>>>while writing the view so you can't just pass the one key value pair to
>>>change a value, but a two key value pairs with the second value being a
>>>specific hashing or such. This would stop the casual hacking of any
>>>property via the URL. You could also then define a security property for
>>>all things struts within the ActionForm.
>>>
>>>The possibility then in extending this would be to define a security
>>>property to each property to be set, or a more simpler global security
>>>property for the entire request, and let the developer decide as to how
>>>fine grained the property setting security should be, if at all.
>>>
>>>Just a thought.
>>>
>>>Arron.
>>>
>>
>>--
>>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>>For additional commands, e-mail: <ma...@jakarta.apache.org>
>>
AB> --
AB> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
AB> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
Best regards,
Oleg mailto:gonza@penza.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Extensibility of struts & Property Security
Posted by Ted Husted <hu...@apache.org>.
Arron wrote:
> 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?... :)
The ActionForms ~are~ the buffering mechanism. That's one reason why
they are not an interface. They should not be tied directly to a model,
but serve as a pessimistic firewall betweeen the untrusted presentation
layer (HTTP/HTML), and the rest of your application, which can then be
more optimistic about the quality of data passed between components.
What's happened is that when we added the nesting feature (late in the
1.0 cycle), we opened a backdoor that can realize some of the same
problems caused when ActionForm was an interface. Someone can nest a
bean that is tied directly to the model, and a hostile user can make
unchecked system state changes.
But, so long as the beans you nest do not update the system state (as
the ActionServlet bean did), then there is nothing to worry about. A
value object, for example, would generally be OK, since they accept data
at one point, and then commit it at another. Between the accept and
commit points, you can validate the input. But the ActionServlet exposed
a direct setter, which is a bad thing on an ActionForm. So, we in
affect, we wrapped it in a value object, so unauthorized system state
changes could not be made.
Nesting beans on an ActionForm is a powerful tool, but with power comes
responsibility.
The one and only danger is nesting a bean that makes direct changes to
the system state via a public property which accepts a single String or
boolean parameter. Protected or private properties or properties with
complex signatures or types will not make it past the autopopulation
guantlet.
-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel +1 716 737-3463
-- http://www.husted.com/struts/
> 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: <ma...@jakarta.apache.org>
> >For additional commands, e-mail: <ma...@jakarta.apache.org>
> >
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Extensibility of struts & Property Security
Posted by Arron <ar...@keyboardmonkey.com>.
>
>
>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: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Extensibility of struts & Property Security
Posted by Ted Husted <hu...@apache.org>.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Extensibility of struts & Property Security
Posted by Arron Bates <ar...@keyboardmonkey.com>.
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.
>
>Arron Bates wrote:
>
>> Yes, yes. Point made.
>>That series of emails makes for some good bedside reading.
>>
>>I think that the solution that was arrived at is fine for protecting the
>>struts system objects themselves.
>>Is there anything happening to allow the developer to protect their own
>>properties from this kind of arbitrary attack?
>>
>>Thought I had would be to configure a property modifier, or property
>>mapping which yields other "security properties" which have to be
>>checked before a property is set. ie: getMyProperty() property method
>>uses a getMyPropertySecurity() to return a defined value which was set
>>while writing the view so you can't just pass the one key value pair to
>>change a value, but a two key value pairs with the second value being a
>>specific hashing or such. This would stop the casual hacking of any
>>property via the URL. You could also then define a security property for
>>all things struts within the ActionForm.
>>
>>The possibility then in extending this would be to define a security
>>property to each property to be set, or a more simpler global security
>>property for the entire request, and let the developer decide as to how
>>fine grained the property setting security should be, if at all.
>>
>>Just a thought.
>>
>>Arron.
>>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Extensibility of struts & Property Security
Posted by Ted Husted <hu...@apache.org>.
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.
Arron Bates wrote:
>
> Yes, yes. Point made.
> That series of emails makes for some good bedside reading.
>
> I think that the solution that was arrived at is fine for protecting the
> struts system objects themselves.
> Is there anything happening to allow the developer to protect their own
> properties from this kind of arbitrary attack?
>
> Thought I had would be to configure a property modifier, or property
> mapping which yields other "security properties" which have to be
> checked before a property is set. ie: getMyProperty() property method
> uses a getMyPropertySecurity() to return a defined value which was set
> while writing the view so you can't just pass the one key value pair to
> change a value, but a two key value pairs with the second value being a
> specific hashing or such. This would stop the casual hacking of any
> property via the URL. You could also then define a security property for
> all things struts within the ActionForm.
>
> The possibility then in extending this would be to define a security
> property to each property to be set, or a more simpler global security
> property for the entire request, and let the developer decide as to how
> fine grained the property setting security should be, if at all.
>
> Just a thought.
>
> Arron.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Extensibility of struts & Property Security
Posted by Arron Bates <ar...@keyboardmonkey.com>.
Yes, yes. Point made.
That series of emails makes for some good bedside reading.
I think that the solution that was arrived at is fine for protecting the
struts system objects themselves.
Is there anything happening to allow the developer to protect their own
properties from this kind of arbitrary attack?
Thought I had would be to configure a property modifier, or property
mapping which yields other "security properties" which have to be
checked before a property is set. ie: getMyProperty() property method
uses a getMyPropertySecurity() to return a defined value which was set
while writing the view so you can't just pass the one key value pair to
change a value, but a two key value pairs with the second value being a
specific hashing or such. This would stop the casual hacking of any
property via the URL. You could also then define a security property for
all things struts within the ActionForm.
The possibility then in extending this would be to define a security
property to each property to be set, or a more simpler global security
property for the entire request, and let the developer decide as to how
fine grained the property setting security should be, if at all.
Just a thought.
Arron.
Ted Husted wrote:
>http://nagoya.apache.org/bugzilla/showattachment.cgi?attach_id=813
>
>"So, someone could also call
>
>getServlet().setTempDir(whatever)
>
>with
>
>http://whatever.com/do/someAction?servlet.tempdir=whatever
>
>Hmmm."
>
>-- Ted Husted, Husted dot Com, Fairport NY USA.
>-- Custom Software ~ Technical Services.
>-- Tel +1 716 737-3463
>-- http://www.husted.com/struts/
>
>
>Arron Bates wrote:
>
>>It doesn't even have to be a careful look at the code. It's not complex
>>in the least.
>>
>>I must be missing something with the "String or boolean properties that
>>affect the system state" thing.
>>
>>Do you mean what it is that I do with the example, where I have a string
>>property that represents a submit button that add objects to the tree
>>and another that can delete them?... If it isn't, can I get an example?...
>>
>>Arron.
>>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Fwd: Re: Extensibility of struts... a solution, maybe
Posted by Ted Husted <hu...@apache.org>.
http://nagoya.apache.org/bugzilla/showattachment.cgi?attach_id=813
"So, someone could also call
getServlet().setTempDir(whatever)
with
http://whatever.com/do/someAction?servlet.tempdir=whatever
Hmmm."
-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel +1 716 737-3463
-- http://www.husted.com/struts/
Arron Bates wrote:
>
> It doesn't even have to be a careful look at the code. It's not complex
> in the least.
>
> I must be missing something with the "String or boolean properties that
> affect the system state" thing.
>
> Do you mean what it is that I do with the example, where I have a string
> property that represents a submit button that add objects to the tree
> and another that can delete them?... If it isn't, can I get an example?...
>
> Arron.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Fwd: Re: Extensibility of struts... a solution, maybe
Posted by Arron Bates <ar...@keyboardmonkey.com>.
It doesn't even have to be a careful look at the code. It's not complex
in the least.
I must be missing something with the "String or boolean properties that
affect the system state" thing.
Do you mean what it is that I do with the example, where I have a string
property that represents a submit button that add objects to the tree
and another that can delete them?... If it isn't, can I get an example?...
Arron.
Ted Husted wrote:
>It's true that I don't have the bandwidth right now to take a careful
>look at your code, but I'm sure its quite good. It's linked both on my
>site and the Struts resource page, and I'm sure people are getting value
>from it.
>
>My statement about nesting objects on ActionForm does hold. Strut's
>autopopulate mechanism can be exploited if nested object have public
>String or boolean properties that affect the system state. In Struts
>1.0, you can do things like change the temporary directory for uploads
>from a browser. We made this mistake on the original design of the
>ActionForm, and I'm just trying to bring this to people's attention
>whenever I can. I do not mean to discourage people from using nested
>objects, only to use them wisely. Forewarned is forearmed.
>
>http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4997
>
>If your code provides an additional firewall, then a discussion of that
>might be helpful, and draw more people into your package.
>
>Arron wrote:
>
>>That was kind of an ignorant comment. I don't know why you people
>>resisting it so much.
>>There is no danger in nesting objects at all.
>>
>>It is possible (however truly ugly) to do the same thing in out of the
>>box struts. It's all about getting the JSP's to elegantly manage data
>>structures you're most likely already using to some point. They release
>>it to go free and make life terribly easier..
>>
>>Take a look at the code. They really do sit on struts. It relies on
>>struts to do what it does. They only guide the struts tags to write out
>>the write properties for things and fetch the right data. ALL the brains
>>of it are a 38 line method.
>>org.apache.struts.taglib.nested.NestedPropertyHelper.
>>Please read it, I 'aint lyin'. :)
>>
>>At the risk of sounding cocky, the nested system introduces nothing but
>>elegant data modelling and management.
>>
>>The rest (which takes more talent) I willingly leave to the rest of you
>>boys. I just managed to finish something that I can't believe was left
>>out. It really was 95% done for me.
>>
>>Stuts rocks, but this just lined it a little for the boys that have to
>>cut it.
>>It does cut developer time.
>>
>>Arron.
>>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
Arron wrote:
> That was kind of an ignorant comment. I don't know why you people
> resisting it so much.
> There is no danger in nesting objects at all.
>
> It is possible (however truly ugly) to do the same thing in out of the
> box struts. It's all about getting the JSP's to elegantly manage data
> structures you're most likely already using to some point. They
> release it to go free and make life terribly easier..
>
> Take a look at the code. They really do sit on struts. It relies on
> struts to do what it does. They only guide the struts tags to write
> out the write properties for things and fetch the right data. ALL the
> brains of it are a 38 line method.
> org.apache.struts.taglib.nested.NestedPropertyHelper.
> Please read it, I 'aint lyin'. :)
>
> At the risk of sounding cocky, the nested system introduces nothing
> but elegant data modelling and management.
>
> The rest (which takes more talent) I willingly leave to the rest of
> you boys. I just managed to finish something that I can't believe was
> left out. It really was 95% done for me.
>
> Stuts rocks, but this just lined it a little for the boys that have to
> cut it.
> It does cut developer time.
>
>
> Arron.
>
>
> Ted Husted wrote:
>
>> The one thing to watch with nested objects is that they don't expose
>> anything that should not be exposed.
>> One thing we plugged in the imminent 1.01 release candidate is "nesting"
>> ActionServlet on the ActionForm. This let you do silly things like set
>> the temporary directory for uploads from a browser. It now uses a
>> ActionServletWrapper to only expose the non-String properties which are
>> absolutely needed (a proxy object).
>>
>> So it's important that any object nested on an ActionForm not make state
>> changes without validation, at least through String and boolean
>> properties.
>> -- Ted Husted, Husted dot Com, Fairport NY USA.
>> -- Custom Software ~ Technical Services.
>> -- Tel +1 716 737-3463
>> -- http://www.husted.com/struts/
>>
>>
>> Arron Bates wrote:
>>
>>> Just a note on this subject....
>>>
>>> You know that you can get absolutely sweet decoupling from everything
>>> struts for your data model with the use of nesting objects?... And no
>>> messy property copying!
>>>
>>> I wanted to get a simple persistence mechanism running for my form
>>> object, so I placed a little serialization logic into my action (Some
>>> app servers need their session objects to serialize also, like
>>> iPlanet).
>>> The struts action form wouldn't serialize for me so all I did was
>>> add an
>>> extra nest level and serialized from there down leaving my entire
>>> structure nothing but the data that I wanted. All the child objects
>>> implement serializeable, extend nothing, and know nothing of struts.
>>>
>>> This is all elegantly managed in the JSP's with the use of the
>>> handy-dandy nesting extension. :)
>>>
>>> That's my two cents.
>>> If you want the code for what I just blabbed on about, mail me...
>>> arron@keyboardmonkey.com
>>>
>>> Arron.
>>> (theKM*)
>>> * I think, therefore, I nest ;)
>>>
>>> --
>>> To unsubscribe, e-mail:
>>> <ma...@jakarta.apache.org>
>>> For additional commands, e-mail:
>>> <ma...@jakarta.apache.org>
>>>
>>
>> --
>> To unsubscribe, e-mail:
>> <ma...@jakarta.apache.org>
>> For additional commands, e-mail:
>> <ma...@jakarta.apache.org>
>>
>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Fwd: Re: Extensibility of struts... a solution, maybe
Posted by Arron <ar...@keyboardmonkey.com>.
That was kind of an ignorant comment. I don't know why you people
resisting it so much.
There is no danger in nesting objects at all.
It is possible (however truly ugly) to do the same thing in out of the
box struts. It's all about getting the JSP's to elegantly manage data
structures you're most likely already using to some point. They release
it to go free and make life terribly easier..
Take a look at the code. They really do sit on struts. It relies on
struts to do what it does. They only guide the struts tags to write out
the write properties for things and fetch the right data. ALL the brains
of it are a 38 line method.
org.apache.struts.taglib.nested.NestedPropertyHelper.
Please read it, I 'aint lyin'. :)
At the risk of sounding cocky, the nested system introduces nothing but
elegant data modelling and management.
The rest (which takes more talent) I willingly leave to the rest of you
boys. I just managed to finish something that I can't believe was left
out. It really was 95% done for me.
Stuts rocks, but this just lined it a little for the boys that have to
cut it.
It does cut developer time.
Arron.
Ted Husted wrote:
>The one thing to watch with nested objects is that they don't expose
>anything that should not be exposed.
>
>One thing we plugged in the imminent 1.01 release candidate is "nesting"
>ActionServlet on the ActionForm. This let you do silly things like set
>the temporary directory for uploads from a browser. It now uses a
>ActionServletWrapper to only expose the non-String properties which are
>absolutely needed (a proxy object).
>
>So it's important that any object nested on an ActionForm not make state
>changes without validation, at least through String and boolean
>properties.
>
>-- Ted Husted, Husted dot Com, Fairport NY USA.
>-- Custom Software ~ Technical Services.
>-- Tel +1 716 737-3463
>-- http://www.husted.com/struts/
>
>
>Arron Bates wrote:
>
>>Just a note on this subject....
>>
>>You know that you can get absolutely sweet decoupling from everything
>>struts for your data model with the use of nesting objects?... And no
>>messy property copying!
>>
>>I wanted to get a simple persistence mechanism running for my form
>>object, so I placed a little serialization logic into my action (Some
>>app servers need their session objects to serialize also, like iPlanet).
>>The struts action form wouldn't serialize for me so all I did was add an
>>extra nest level and serialized from there down leaving my entire
>>structure nothing but the data that I wanted. All the child objects
>>implement serializeable, extend nothing, and know nothing of struts.
>>
>>This is all elegantly managed in the JSP's with the use of the
>>handy-dandy nesting extension. :)
>>
>>That's my two cents.
>>If you want the code for what I just blabbed on about, mail me...
>>arron@keyboardmonkey.com
>>
>>Arron.
>>(theKM*)
>>* I think, therefore, I nest ;)
>>
>>--
>>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>>For additional commands, e-mail: <ma...@jakarta.apache.org>
>>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Fwd: Re: Extensibility of struts... a solution, maybe
Posted by Ted Husted <hu...@apache.org>.
The one thing to watch with nested objects is that they don't expose
anything that should not be exposed.
One thing we plugged in the imminent 1.01 release candidate is "nesting"
ActionServlet on the ActionForm. This let you do silly things like set
the temporary directory for uploads from a browser. It now uses a
ActionServletWrapper to only expose the non-String properties which are
absolutely needed (a proxy object).
So it's important that any object nested on an ActionForm not make state
changes without validation, at least through String and boolean
properties.
-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel +1 716 737-3463
-- http://www.husted.com/struts/
Arron Bates wrote:
>
> Just a note on this subject....
>
> You know that you can get absolutely sweet decoupling from everything
> struts for your data model with the use of nesting objects?... And no
> messy property copying!
>
> I wanted to get a simple persistence mechanism running for my form
> object, so I placed a little serialization logic into my action (Some
> app servers need their session objects to serialize also, like iPlanet).
> The struts action form wouldn't serialize for me so all I did was add an
> extra nest level and serialized from there down leaving my entire
> structure nothing but the data that I wanted. All the child objects
> implement serializeable, extend nothing, and know nothing of struts.
>
> This is all elegantly managed in the JSP's with the use of the
> handy-dandy nesting extension. :)
>
> That's my two cents.
> If you want the code for what I just blabbed on about, mail me...
> arron@keyboardmonkey.com
>
> Arron.
> (theKM*)
> * I think, therefore, I nest ;)
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Fwd: Re: Extensibility of struts... a solution, maybe
Posted by Arron <ar...@keyboardmonkey.com>.
It's all here... the original nesting extension and the saving model I
just mentioned.
http://www.keyboardmonkey.com/downloads/struts/index.html
The main part of the action simply gets the data that held in a
hierarchy of objects from one method and serializes the result. It's in
the example "SavingMonkey" war file on the link above. It's all there.
Arron
Oleg V Alexeev wrote:
>Hello Arron,
>
>Tuesday, November 27, 2001, 11:53:25 AM, you wrote:
>
>AB> Just a note on this subject....
>
>AB> You know that you can get absolutely sweet decoupling from everything
>AB> struts for your data model with the use of nesting objects?... And no
>AB> messy property copying!
>
>AB> I wanted to get a simple persistence mechanism running for my form
>AB> object, so I placed a little serialization logic into my action (Some
>AB> app servers need their session objects to serialize also, like iPlanet).
>AB> The struts action form wouldn't serialize for me so all I did was add an
>AB> extra nest level and serialized from there down leaving my entire
>AB> structure nothing but the data that I wanted. All the child objects
>AB> implement serializeable, extend nothing, and know nothing of struts.
>
>AB> This is all elegantly managed in the JSP's with the use of the
>AB> handy-dandy nesting extension. :)
>
>AB> That's my two cents.
>AB> If you want the code for what I just blabbed on about, mail me...
>AB> arron@keyboardmonkey.com
>
>Can you post some samples to the list?
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re[2]: Fwd: Re: Extensibility of struts... a solution, maybe
Posted by Oleg V Alexeev <go...@penza.net>.
Hello Arron,
Tuesday, November 27, 2001, 11:53:25 AM, you wrote:
AB> Just a note on this subject....
AB> You know that you can get absolutely sweet decoupling from everything
AB> struts for your data model with the use of nesting objects?... And no
AB> messy property copying!
AB> I wanted to get a simple persistence mechanism running for my form
AB> object, so I placed a little serialization logic into my action (Some
AB> app servers need their session objects to serialize also, like iPlanet).
AB> The struts action form wouldn't serialize for me so all I did was add an
AB> extra nest level and serialized from there down leaving my entire
AB> structure nothing but the data that I wanted. All the child objects
AB> implement serializeable, extend nothing, and know nothing of struts.
AB> This is all elegantly managed in the JSP's with the use of the
AB> handy-dandy nesting extension. :)
AB> That's my two cents.
AB> If you want the code for what I just blabbed on about, mail me...
AB> arron@keyboardmonkey.com
Can you post some samples to the list?
--
Best regards,
Oleg mailto:gonza@penza.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Fwd: Re: Extensibility of struts... a solution, maybe
Posted by Arron Bates <ar...@keyboardmonkey.com>.
Just a note on this subject....
You know that you can get absolutely sweet decoupling from everything
struts for your data model with the use of nesting objects?... And no
messy property copying!
I wanted to get a simple persistence mechanism running for my form
object, so I placed a little serialization logic into my action (Some
app servers need their session objects to serialize also, like iPlanet).
The struts action form wouldn't serialize for me so all I did was add an
extra nest level and serialized from there down leaving my entire
structure nothing but the data that I wanted. All the child objects
implement serializeable, extend nothing, and know nothing of struts.
This is all elegantly managed in the JSP's with the use of the
handy-dandy nesting extension. :)
That's my two cents.
If you want the code for what I just blabbed on about, mail me...
arron@keyboardmonkey.com
Arron.
(theKM*)
* I think, therefore, I nest ;)
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re[2]: Fwd: Re: Extensibility of struts
Posted by Oleg V Alexeev <go...@penza.net>.
Hello Ted,
Monday, November 26, 2001, 8:14:19 PM, you wrote:
TH> I think its a clever idea. It's important that the framework not require
TH> Javascript for nominal operation, but using it is a fact of life for
TH> most applications, and getting it into a tag can be problematic.
TH> Though, should we allow for the Javascript to come from a separate bean,
TH> the ActionForm (or name=) bean being the default? So, we might have an
TH> optional scriptName="JavaScriptBean".
Add method to ActionForm and rewrite it in extended classes -
public class ActionForm {
protected ClentSideScripts scripts = null;
public ClentSideScripts getClientSideScripts() {
return scripts;
}
public void setClientSideScripts() {
this.scripts = scripts;
}
}
public class ClientSideScripts {
public String getOnkeydown() {
return "";
}
.....
}
public class MyScripts extends ClientSideScripts {
public String getOnkeydown() {
return "javascript:alert('Hey!')";
}
}
and in struts-config.xml add additional attribute to the action form
definition -
<form-bean name="logonForm"
type="org.apache.struts.webapp.example.LogonForm"
scriptSourceBeanClass="some.package.MyScripts"/>
or
public class SomeForm extends ActionForm {
public ClentSideScripts getClientSideScripts() {
// any custom code to return bean with script
// definitions
}
}
Some implementation of ClientSideScripts can read scripts from
resources, for example... 8)
TH> The other thing I've always wanted to add to the tags is a "literal" or
TH> ("custom" or "verbatim") property, that would just spit out whatever you
TH> put into it. This would solve the problems with tags like textarea,
TH> where the wrap attribute is not an official attribute. So, there we
TH> could use literal="wrap=virtual" and have it add that to the textarea
TH> tag. Of course, we would add this to all the tags, for consistency.
Great. It is simple and flexible.
TH> -- Ted Husted, Husted dot Com, Fairport NY USA.
TH> -- Custom Software ~ Technical Services.
TH> -- Tel +1 716 737-3463
TH> -- http://www.husted.com/struts/
TH> Oleg V Alexeev wrote:
>>
>> Hello friends,
>>
>> Is it interesting for somebody to implement for html tags such logic
>> as listed below?
>>
>> Add to tags xxxKey attributes for all scripting support attributes
>> and extend html tags with ability to retrieve client side code from
>> resources by the key from attribute value. For example -
>>
>> <html:input name="someField" onKeyDownKey="javascript.alert.field"/>
>>
>> In this example 'javascript.alert.field' is the key to retireve
>> client code script.
>>
>> Is it interesting? I think it is useful and easy to implement.
>>
>> Monday, November 26, 2001, 1:52:39 PM, you wrote:
>>
>> SW> Hi Oleg,
>>
>> SW> for our current problem the first option is the better solution because it
>> SW> does not require to repeat in all JSPs the on... attributes. The overloaded
>> SW> tag class can automatically append some javascript code without a JSP
>> SW> developer
>> SW> even to know about it. In this case the only thing of struts that we have to
>> SW> patch is the tld which is acceptable.
>>
>> SW> The second option is also a great idea because then javascript logic is no
>> SW> longer scattered everywhere but can be centralized. I think lots of
>> SW> developers
>> SW> would be very grateful to have this possiblity.
>>
>> SW> However in our case the (automatically added) javascript code is already
>> SW> centralized in the overloading classes. To be able to configure it we would
>> SW> need
>> SW> some session- or application-scope object where we could define such global
>> SW> settings for all html-elements of certain kinds. I think this would be a big
>> SW> undertaking but maybe it would be enough to define somewhere default values
>> SW> for all attributes of all JSP tags.
>>
>> SW> To summarize: we are completely happy if just the member access in the tags
>> SW> is replaced by getter methods.
>>
>> SW> Ciao,
>> SW> Stefan
>> >> Hello Stefan,
>> >>
>> >> How do you want to specify default javascript code for tags? I view
>> >> two ways to do so (all this variants uses your model - with proxy
>> >> getXXX() methods and avoid direct variable values retrieving) -
>> >>
>> >> 1. Extend html:input tag with your own tag and reload all
>> >> getXXXJscriptCode methods to generate default client side code.
>> >> 2. Write new version of html:input tag with support of resource
>> >> strings. So developer can specify key to retrieve string from
>> >> resources and use it as attribute value -
>> >>
>> >> <html:input name="someField" onKeyDown="javascript:alert('Wow!')"/>
>> >> <html:input name="someField" onKeyDownKey="javascript.alert.field"/>
>> >>
>> >> Last example uses key 'javascript.alert.field' to retrieve value
>> >> from resources.
>> >>
>> >> I think that second method is more powerful and flexible. Is it
>> >> way to solve your problem?
>> >>
>>
>> --
>> Best regards,
>> Oleg mailto:gonza@penza.net
>>
>> --
>> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>> For additional commands, e-mail: <ma...@jakarta.apache.org>
TH> --
TH> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
TH> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
Best regards,
Oleg mailto:gonza@penza.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Fwd: Re: Extensibility of struts
Posted by Ted Husted <hu...@apache.org>.
I think its a clever idea. It's important that the framework not require
Javascript for nominal operation, but using it is a fact of life for
most applications, and getting it into a tag can be problematic.
Though, should we allow for the Javascript to come from a separate bean,
the ActionForm (or name=) bean being the default? So, we might have an
optional scriptName="JavaScriptBean".
The other thing I've always wanted to add to the tags is a "literal" or
("custom" or "verbatim") property, that would just spit out whatever you
put into it. This would solve the problems with tags like textarea,
where the wrap attribute is not an official attribute. So, there we
could use literal="wrap=virtual" and have it add that to the textarea
tag. Of course, we would add this to all the tags, for consistency.
-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel +1 716 737-3463
-- http://www.husted.com/struts/
Oleg V Alexeev wrote:
>
> Hello friends,
>
> Is it interesting for somebody to implement for html tags such logic
> as listed below?
>
> Add to tags xxxKey attributes for all scripting support attributes
> and extend html tags with ability to retrieve client side code from
> resources by the key from attribute value. For example -
>
> <html:input name="someField" onKeyDownKey="javascript.alert.field"/>
>
> In this example 'javascript.alert.field' is the key to retireve
> client code script.
>
> Is it interesting? I think it is useful and easy to implement.
>
> Monday, November 26, 2001, 1:52:39 PM, you wrote:
>
> SW> Hi Oleg,
>
> SW> for our current problem the first option is the better solution because it
> SW> does not require to repeat in all JSPs the on... attributes. The overloaded
> SW> tag class can automatically append some javascript code without a JSP
> SW> developer
> SW> even to know about it. In this case the only thing of struts that we have to
> SW> patch is the tld which is acceptable.
>
> SW> The second option is also a great idea because then javascript logic is no
> SW> longer scattered everywhere but can be centralized. I think lots of
> SW> developers
> SW> would be very grateful to have this possiblity.
>
> SW> However in our case the (automatically added) javascript code is already
> SW> centralized in the overloading classes. To be able to configure it we would
> SW> need
> SW> some session- or application-scope object where we could define such global
> SW> settings for all html-elements of certain kinds. I think this would be a big
> SW> undertaking but maybe it would be enough to define somewhere default values
> SW> for all attributes of all JSP tags.
>
> SW> To summarize: we are completely happy if just the member access in the tags
> SW> is replaced by getter methods.
>
> SW> Ciao,
> SW> Stefan
> >> Hello Stefan,
> >>
> >> How do you want to specify default javascript code for tags? I view
> >> two ways to do so (all this variants uses your model - with proxy
> >> getXXX() methods and avoid direct variable values retrieving) -
> >>
> >> 1. Extend html:input tag with your own tag and reload all
> >> getXXXJscriptCode methods to generate default client side code.
> >> 2. Write new version of html:input tag with support of resource
> >> strings. So developer can specify key to retrieve string from
> >> resources and use it as attribute value -
> >>
> >> <html:input name="someField" onKeyDown="javascript:alert('Wow!')"/>
> >> <html:input name="someField" onKeyDownKey="javascript.alert.field"/>
> >>
> >> Last example uses key 'javascript.alert.field' to retrieve value
> >> from resources.
> >>
> >> I think that second method is more powerful and flexible. Is it
> >> way to solve your problem?
> >>
>
> --
> Best regards,
> Oleg mailto:gonza@penza.net
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re[4]: Fwd: Re: Extensibility of struts
Posted by Oleg V Alexeev <go...@penza.net>.
Hello friends,
Is it interesting for somebody to implement for html tags such logic
as listed below?
Add to tags xxxKey attributes for all scripting support attributes
and extend html tags with ability to retrieve client side code from
resources by the key from attribute value. For example -
<html:input name="someField" onKeyDownKey="javascript.alert.field"/>
In this example 'javascript.alert.field' is the key to retireve
client code script.
Is it interesting? I think it is useful and easy to implement.
Monday, November 26, 2001, 1:52:39 PM, you wrote:
SW> Hi Oleg,
SW> for our current problem the first option is the better solution because it
SW> does not require to repeat in all JSPs the on... attributes. The overloaded
SW> tag class can automatically append some javascript code without a JSP
SW> developer
SW> even to know about it. In this case the only thing of struts that we have to
SW> patch is the tld which is acceptable.
SW> The second option is also a great idea because then javascript logic is no
SW> longer scattered everywhere but can be centralized. I think lots of
SW> developers
SW> would be very grateful to have this possiblity.
SW> However in our case the (automatically added) javascript code is already
SW> centralized in the overloading classes. To be able to configure it we would
SW> need
SW> some session- or application-scope object where we could define such global
SW> settings for all html-elements of certain kinds. I think this would be a big
SW> undertaking but maybe it would be enough to define somewhere default values
SW> for all attributes of all JSP tags.
SW> To summarize: we are completely happy if just the member access in the tags
SW> is replaced by getter methods.
SW> Ciao,
SW> Stefan
>> Hello Stefan,
>>
>> How do you want to specify default javascript code for tags? I view
>> two ways to do so (all this variants uses your model - with proxy
>> getXXX() methods and avoid direct variable values retrieving) -
>>
>> 1. Extend html:input tag with your own tag and reload all
>> getXXXJscriptCode methods to generate default client side code.
>> 2. Write new version of html:input tag with support of resource
>> strings. So developer can specify key to retrieve string from
>> resources and use it as attribute value -
>>
>> <html:input name="someField" onKeyDown="javascript:alert('Wow!')"/>
>> <html:input name="someField" onKeyDownKey="javascript.alert.field"/>
>>
>> Last example uses key 'javascript.alert.field' to retrieve value
>> from resources.
>>
>> I think that second method is more powerful and flexible. Is it
>> way to solve your problem?
>>
--
Best regards,
Oleg mailto:gonza@penza.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re[4]: Fwd: Re: Extensibility of struts
Posted by Oleg V Alexeev <go...@penza.net>.
Hello Stefan,
Check nightly build.
Monday, November 26, 2001, 1:52:39 PM, you wrote:
SW> Hi Oleg,
SW> for our current problem the first option is the better solution because it
SW> does not require to repeat in all JSPs the on... attributes. The overloaded
SW> tag class can automatically append some javascript code without a JSP
SW> developer
SW> even to know about it. In this case the only thing of struts that we have to
SW> patch is the tld which is acceptable.
SW> The second option is also a great idea because then javascript logic is no
SW> longer scattered everywhere but can be centralized. I think lots of
SW> developers
SW> would be very grateful to have this possiblity.
SW> However in our case the (automatically added) javascript code is already
SW> centralized in the overloading classes. To be able to configure it we would
SW> need
SW> some session- or application-scope object where we could define such global
SW> settings for all html-elements of certain kinds. I think this would be a big
SW> undertaking but maybe it would be enough to define somewhere default values
SW> for all attributes of all JSP tags.
SW> To summarize: we are completely happy if just the member access in the tags
SW> is replaced by getter methods.
SW> Ciao,
SW> Stefan
--
Best regards,
Oleg mailto:gonza@penza.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>