Sounds like a cool idea to me, but that's not saying much on this topic. I have been thinking about how in the heck i'd implement some security/ACL-type stuff just today without having to write my own subclasses of the stripes tags, and this seems like it would help me do most of what I would want.
One question, tho. Do you have plans to use this feature to do further Stripes facilities for security-done-the-Stripes-way (that would be to Acegi as, say, Stripes Layout Reuse is to Tiles), or add default support for dojo's rich UI widgets? Or is this more for all of us to do what we want and we shouldn't hold our breath for those sorts of things to built in to Stripes?
-BD aka RJ
----- Original Message ----
From: Tim Fennell <[EMAIL PROTECTED]>
To: Stripes Development List <[email protected]>
Sent: Monday, September 4, 2006 3:39:33 PM
Subject: [Stripes-dev] Proposal: Tag Interceptors
The purpose of this email is to document my initial thoughts around a new feature for Stripes, and more specifically to get feedback on the idea and the possible implementation strategy outlined...
From: Tim Fennell <[EMAIL PROTECTED]>
To: Stripes Development List <[email protected]>
Sent: Monday, September 4, 2006 3:39:33 PM
Subject: [Stripes-dev] Proposal: Tag Interceptors
The purpose of this email is to document my initial thoughts around a new feature for Stripes, and more specifically to get feedback on the idea and the possible implementation strategy outlined...
When I first started thinking about this idea I had in mind the idea of 'TagRenderer's that behaved much like the current ErrorTagRenderer[1] except that they'd apply to tags even when there are no errors. In fact Greg even logged a feature request[2] for it ages ago! But the more I've been thinking about it, the more I think a model closer to Stripes' interceptor model might be more appropriate.
The use cases I have in mind for this kind of thing are things like:
1. Display a red * next to all required fields
2. Display a <div> instead of a text box if the user does not have edit permissions
3. Automatically add dojo:type (or equivelant) attribute based on ActionBean property type
4. Set length="" constraints and such on form input fields
They key difference I see is that a tag "interceptor" should be able to stop rendering of the tag as opposed to a "renderer" akin to the error renderer really only affects the tag output but doesn't really control it.
This approach is in contrast to "render kits" or "themes" as adopted by JSF and WebWork respectively. In that approach there is one class (or template fragment) responsible for rendering each tag and you can substitute either an entire "theme" with your own implementation, or just specified tags' renderer. The downside to this approach (as it appears to me) is that you often have to change many/all renderers for even to make a simple change like #1 above. So it's hard to create cross-cutting behaviors, which seems like the primary use case for this kind of system.
What I am proposing is that each tag is responsible for it's own rendering but that tag interceptors have the ability to:
- add/remove/modify tag attributes prior to rendering
- write to the output before and after the tag renders itself
- stop the tag from rendering
- stop the tag from evaluating it's body?
I think that the interface would look pretty similar to the current TagErrorRenderer interface. Something like:
public TagInterceptor {
void init(tag);
boolean doBeforeRender();
void doAfterRender();
}
I'm not settled on this yet...and in most cases these calls would probably happen from doStartTag() and doEndTag(). If the doBeforeRender() returns false, then the tag would *not* render any output (though the interceptor may do).
A few more points I've been thinking about:
- Like interceptors, I think you should be able to have multiple tag interceptors
- It should probably be possible to intercept all Stripes tags, not just input tags
- Maybe an annotation could be used to restrict calls, e.g. @TagsIntercepted(FormTag.class)
I think that'll probably do to get the conversation started ;) What do you guys think of this approach? Are there other things you'd like to be able to do?
-t
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Stripes-development mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/stripes-development
Stripes-development mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/stripes-development
------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________ Stripes-development mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/stripes-development
