ServletRequestAware Interface doubled
Working on the ProxyPrincipal problem, I discovered that we have two different ServletRequestAware interfaces: - org.apache.struts2.servlet.ServletRequestAware in api - org.apache.struts2.interceptor.ServletRequestAware in core I doubt this is by intention. ServletConfigInterceptor uses the second variant, which is IMO bad choice and makes it difficult to remove it in favor for the api variant, as it will most likely break many users code. On the other hand, since we are not in production yet, we should work on clean interfaces and risk some minor/easy to fix code breaks for users. I'm +1 for dropping the core variant. - Rene -- Rene Gielen | http://it-neering.net/ Aachen | PGP-ID: BECB785A Germany | gielen at it-neering.net - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[S2] s:div (BindDiv) ajaxTheme
Hi All,
Why the BindDiv inside a tabbed pane does two posts insted for one?
Like if I run this code:
dojo.widget.createWidget("BindDiv", {label:'Details',
executeScripts:true, href:'personDetails.action', parseContent:true,
refreshOnShow:false, id:'detailTab'});
The dojo makes two posts... Is that correct?
Have a nice Day,
Regards,
André Faria
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [S2] Experimental Features
I use all of these with HostedQA. > It's exciting to see that we've added a number of > brave, new features > since Struts 2.0.1. > > * codebehind plugin > * zero configuration > * REST-ful URLS > * direct results > > As implemented, these features seem solid and useful, > but I wonder if > anyone has a chance to use them all beyond "proof of > concept" > examples. (Wendy?) > > If not, I would suggest that we consider documenting > these features as > "experimental" for Struts 2.0.2, until we have had a > chance to put > them to use ourselves in our own applications. > > Of course, one GA in a series is only the beginning, > and we can soon > bring out another 2.0.x that promotes the > "experimental" features to > "mainstream". > > -Ted. > > -- > --- > To unsubscribe, e-mail: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > > - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=52728&messageID=120092#120092 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [S2] Experimental Features
I'm also using codebehind and zero config. Is it time to promote them from experimental? Patrick Lightbody wrote: I use all of these with HostedQA. It's exciting to see that we've added a number of brave, new features since Struts 2.0.1. * codebehind plugin * zero configuration * REST-ful URLS * direct results As implemented, these features seem solid and useful, but I wonder if anyone has a chance to use them all beyond "proof of concept" examples. (Wendy?) If not, I would suggest that we consider documenting these features as "experimental" for Struts 2.0.2, until we have had a chance to put them to use ourselves in our own applications. Of course, one GA in a series is only the beginning, and we can soon bring out another 2.0.x that promotes the "experimental" features to "mainstream". -Ted. -- --- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=52728&messageID=120092#120092 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ServletRequestAware Interface doubled
On 2/1/07, Rene Gielen <[EMAIL PROTECTED]> wrote: I doubt this is by intention. ServletConfigInterceptor uses the second variant, which is IMO bad choice and makes it difficult to remove it in favor for the api variant, as it will most likely break many users code. On the other hand, since we are not in production yet, we should work on clean interfaces and risk some minor/easy to fix code breaks for users. +1 -- now is the time, definitely. -- Joe Germuska [EMAIL PROTECTED] * http://blog.germuska.com "The truth is that we learned from João forever to be out of tune." -- Caetano Veloso
Re: [S2] Experimental Features
On 2/1/07, David H. DeWolf <[EMAIL PROTECTED]> wrote: I'm also using codebehind and zero config. Is it time to promote them from experimental? The best thing might be for us to update the MailReader to use all of these features. Then it would be easier for everyone to try the features on various platforms. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ServletRequestAware Interface doubled
Last I knew, the "new" API was incomplete, and I don't know if we want to start forcing people to use it before it is complete. The plan was to leave the old API in place until the new one was done, then depreciate the old. But, again, I believe the new API is still incomplete. -Ted. On 2/1/07, Rene Gielen <[EMAIL PROTECTED]> wrote: Working on the ProxyPrincipal problem, I discovered that we have two different ServletRequestAware interfaces: - org.apache.struts2.servlet.ServletRequestAware in api - org.apache.struts2.interceptor.ServletRequestAware in core I doubt this is by intention. ServletConfigInterceptor uses the second variant, which is IMO bad choice and makes it difficult to remove it in favor for the api variant, as it will most likely break many users code. On the other hand, since we are not in production yet, we should work on clean interfaces and risk some minor/easy to fix code breaks for users. I'm +1 for dropping the core variant. - Rene - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ServletRequestAware Interface doubled
-1, IIRC the API is not yet in place, but shall be the foundation for the upcoming xwork abstraction. Who can give us an update on the current API status? Since the API is not yet implemented at all, I think there is currently no need to remove anything, before the API has been finalized. -Rainer > On 2/1/07, Rene Gielen <[EMAIL PROTECTED]> wrote: >> >> I doubt this is by intention. ServletConfigInterceptor uses the second >> variant, which is IMO bad choice and makes it difficult to remove it in >> favor for the api variant, as it will most likely break many users code. >> On the other hand, since we are not in production yet, we should work on >> clean interfaces and risk some minor/easy to fix code breaks for users. > > > +1 -- now is the time, definitely. > > > -- > Joe Germuska > [EMAIL PROTECTED] * http://blog.germuska.com > > "The truth is that we learned from João forever to be out of tune." > -- Caetano Veloso > -- Rainer Hermanns aixcept Neupforte 16 52062 Aachen - Germany w: http://aixcept.de/ t:+49-241-4012247 m: +49-170-3432912 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ServletRequestAware Interface doubled
Then should we remove the dependency on the api from core to prevent confusion? Rainer Hermanns wrote: -1, IIRC the API is not yet in place, but shall be the foundation for the upcoming xwork abstraction. Who can give us an update on the current API status? Since the API is not yet implemented at all, I think there is currently no need to remove anything, before the API has been finalized. -Rainer On 2/1/07, Rene Gielen <[EMAIL PROTECTED]> wrote: I doubt this is by intention. ServletConfigInterceptor uses the second variant, which is IMO bad choice and makes it difficult to remove it in favor for the api variant, as it will most likely break many users code. On the other hand, since we are not in production yet, we should work on clean interfaces and risk some minor/easy to fix code breaks for users. +1 -- now is the time, definitely. -- Joe Germuska [EMAIL PROTECTED] * http://blog.germuska.com "The truth is that we learned from João forever to be out of tune." -- Caetano Veloso - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ServletRequestAware Interface doubled
If we are going to do that, then perhaps we should send the new API to the sandbox, until someone is ready to finish it. On 2/1/07, David H. DeWolf <[EMAIL PROTECTED]> wrote: Then should we remove the dependency on the api from core to prevent confusion? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
License Headers (was Re: ServletRequestAware Interface doubled)
One thing I did notice when looking through the api quickly is that a lot of the api doesn't have license headers. We should probably fix that ASAP. https://issues.apache.org/struts/browse/WW-1698 Does this mean we should stop the current release that's about to go out? David Rene Gielen wrote: Working on the ProxyPrincipal problem, I discovered that we have two different ServletRequestAware interfaces: - org.apache.struts2.servlet.ServletRequestAware in api - org.apache.struts2.interceptor.ServletRequestAware in core I doubt this is by intention. ServletConfigInterceptor uses the second variant, which is IMO bad choice and makes it difficult to remove it in favor for the api variant, as it will most likely break many users code. On the other hand, since we are not in production yet, we should work on clean interfaces and risk some minor/easy to fix code breaks for users. I'm +1 for dropping the core variant. - Rene -- Rene Gielen | http://it-neering.net/ Aachen | PGP-ID: BECB785A Germany | gielen at it-neering.net - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: License Headers (was Re: ServletRequestAware Interface doubled)
All release *must* include the license.txt ... and ... all source files *should* include the header. So, assuming there's a difference between "must" and "should", I would say that we only need to correct it in future releases. * http://apache.org/legal/src-headers.html The rationale for "should" is to cover the case where the source file becomes detached from the distribution. And, in this case, we're only talking about an interface. From the discussion, I'm thinking 2.0.4 is only going to be beta anyway, so we should just fix it for 2.0.5, and move on. -Ted. On 2/1/07, David H. DeWolf <[EMAIL PROTECTED]> wrote: One thing I did notice when looking through the api quickly is that a lot of the api doesn't have license headers. We should probably fix that ASAP. https://issues.apache.org/struts/browse/WW-1698 Does this mean we should stop the current release that's about to go out? David Rene Gielen wrote: > Working on the ProxyPrincipal problem, I discovered that we have two > different ServletRequestAware interfaces: > - org.apache.struts2.servlet.ServletRequestAware in api > - org.apache.struts2.interceptor.ServletRequestAware in core > > I doubt this is by intention. ServletConfigInterceptor uses the second > variant, which is IMO bad choice and makes it difficult to remove it in > favor for the api variant, as it will most likely break many users code. > On the other hand, since we are not in production yet, we should work on > clean interfaces and risk some minor/easy to fix code breaks for users. > > I'm +1 for dropping the core variant. > > - Rene > > -- > Rene Gielen | http://it-neering.net/ > Aachen | PGP-ID: BECB785A > Germany | gielen at it-neering.net - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
problem in using html:checkbox
Hi All, In my application, I need to generate check boxes for every row of data. I set the data as a list of objects in my controller and I access the same in JSP using For each row of this data, I need to add a checkbox with 'value' attribute as a field in the data row object... here it is user_id.(data set is in request scope) How can I achieve this? Or do I need to use traditional java code in JSP :( I have like this: and I have other data: ... Any help is appreciated. Thanks in Advance, Shekar. -- View this message in context: http://www.nabble.com/problem-in-using-html%3Acheckbox-tf3155409.html#a8749946 Sent from the Struts - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [S2] s:div (BindDiv) ajaxTheme
On showcase, tabbed panel, example 3, I tried this:
dojo.widget.createWidget("BindDiv", {label:'Details', executeScripts:true,
href:'/struts2-showcase/AjaxTest.action', parseContent:true,
refreshOnShow:false, id:'ryh1'});
And the first request that it makes it to load "dojo.js" (caching
problem that will be fixed in the future), and the second is for the
href. Are those the two posts that you are seeing, or are you getting
two posts to the same href?
regards
musachy
André Faria wrote:
Hi All,
Why the BindDiv inside a tabbed pane does two posts insted for one?
Like if I run this code:
dojo.widget.createWidget("BindDiv", {label:'Details',
executeScripts:true, href:'personDetails.action', parseContent:true,
refreshOnShow:false, id:'detailTab'});
The dojo makes two posts... Is that correct?
Have a nice Day,
Regards,
André Faria
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: License Headers (was Re: ServletRequestAware Interface doubled)
Ted and I disagree on this - I don't believe the intention of that policy is to make headers for source files optional. If you read the whole policy document rather than focusing on a single word it seems pretty clear to me that they are required. For example in the FAQ it states the following about why source file headers are required: Why is a licensing header necessary? License headers allow someone examining the file to know the terms for the work, even when it is distributed without the rest of the distribution. Without a licensing notice, it must be assumed that the author has reserved all rights, including the right to copy, modify, and redistribute. Niall On 2/1/07, Ted Husted <[EMAIL PROTECTED]> wrote: All release *must* include the license.txt ... and ... all source files *should* include the header. So, assuming there's a difference between "must" and "should", I would say that we only need to correct it in future releases. * http://apache.org/legal/src-headers.html The rationale for "should" is to cover the case where the source file becomes detached from the distribution. And, in this case, we're only talking about an interface. From the discussion, I'm thinking 2.0.4 is only going to be beta anyway, so we should just fix it for 2.0.5, and move on. -Ted. On 2/1/07, David H. DeWolf <[EMAIL PROTECTED]> wrote: > One thing I did notice when looking through the api quickly is that > a lot of the api doesn't have license headers. We should probably fix > that ASAP. > > https://issues.apache.org/struts/browse/WW-1698 > > Does this mean we should stop the current release that's about to go out? > > David > > Rene Gielen wrote: > > Working on the ProxyPrincipal problem, I discovered that we have two > > different ServletRequestAware interfaces: > > - org.apache.struts2.servlet.ServletRequestAware in api > > - org.apache.struts2.interceptor.ServletRequestAware in core > > > > I doubt this is by intention. ServletConfigInterceptor uses the second > > variant, which is IMO bad choice and makes it difficult to remove it in > > favor for the api variant, as it will most likely break many users code. > > On the other hand, since we are not in production yet, we should work on > > clean interfaces and risk some minor/easy to fix code breaks for users. > > > > I'm +1 for dropping the core variant. > > > > - Rene > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [S2] s:div (BindDiv) ajaxTheme
oopswrong 'reply to'
musachy
Musachy Barroso wrote:
On showcase, tabbed panel, example 3, I tried this:
dojo.widget.createWidget("BindDiv", {label:'Details',
executeScripts:true,
href:'/struts2-showcase/AjaxTest.action', parseContent:true,
refreshOnShow:false, id:'ryh1'});
And the first request that it makes it to load "dojo.js" (caching
problem that will be fixed in the future), and the second is for the
href. Are those the two posts that you are seeing, or are you getting
two posts to the same href?
regards
musachy
André Faria wrote:
Hi All,
Why the BindDiv inside a tabbed pane does two posts insted for one?
Like if I run this code:
dojo.widget.createWidget("BindDiv", {label:'Details',
executeScripts:true, href:'personDetails.action', parseContent:true,
refreshOnShow:false, id:'detailTab'});
The dojo makes two posts... Is that correct?
Have a nice Day,
Regards,
André Faria
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [S2] s:div (BindDiv) ajaxTheme
I am getting two requests to the same href...
Thank's for reply!!!
André Faria
Musachy Barroso escreveu:
On showcase, tabbed panel, example 3, I tried this:
dojo.widget.createWidget("BindDiv", {label:'Details',
executeScripts:true,
href:'/struts2-showcase/AjaxTest.action', parseContent:true,
refreshOnShow:false, id:'ryh1'});
And the first request that it makes it to load "dojo.js" (caching
problem that will be fixed in the future), and the second is for the
href. Are those the two posts that you are seeing, or are you getting
two posts to the same href?
regards
musachy
André Faria wrote:
Hi All,
Why the BindDiv inside a tabbed pane does two posts insted for one?
Like if I run this code:
dojo.widget.createWidget("BindDiv", {label:'Details',
executeScripts:true, href:'personDetails.action', parseContent:true,
refreshOnShow:false, id:'detailTab'});
The dojo makes two posts... Is that correct?
Have a nice Day,
Regards,
André Faria
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Atenciosamente,
*/André Faria/*
/Bluesoft Consultoria em Informática/
/Fone: [55 11] 5543-5406/
/e-mail: [EMAIL PROTECTED]/
/Web: www.bluesoft.com.br/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Future of Struts API (was ServletRequestAware Interface doubled)
Yeah, I think we really need a commitment from Bob or someone else willing to really finish this effort. If no one signs up, I'm all for pull it out into the sandbox. Right now, there are too many duplicate classes and code that is very confusing as a developer. Personally, I think this should even be resolved in the 2.0.x branch. Don Ted Husted wrote: If we are going to do that, then perhaps we should send the new API to the sandbox, until someone is ready to finish it. On 2/1/07, David H. DeWolf <[EMAIL PROTECTED]> wrote: Then should we remove the dependency on the api from core to prevent confusion? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Future of Struts API (was ServletRequestAware Interface doubled)
I tend to agree. Unless someone says they are ready, willing, and ablle to resolve the "new API" this weekend, lets just pull it out and roll 2.0.5 now. We can then slate the "new API" for 2.1.x, along with the AJAX/Dojo plugin. (Which, I believe, would be *plenty* for a 2.1.x, without getting into other things that aren't ready yet.) -Ted. On 2/1/07, Don Brown <[EMAIL PROTECTED]> wrote: Yeah, I think we really need a commitment from Bob or someone else willing to really finish this effort. If no one signs up, I'm all for pull it out into the sandbox. Right now, there are too many duplicate classes and code that is very confusing as a developer. Personally, I think this should even be resolved in the 2.0.x branch. Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Future of Struts API (was ServletRequestAware Interface doubled)
Ted Husted wrote: I tend to agree. Unless someone says they are ready, willing, and ablle to resolve the "new API" this weekend, lets just pull it out and roll 2.0.5 now. +1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Future of Struts API (was ServletRequestAware Interface doubled)
I'm cool with that. I'm not going to finish it by this weekend--I'm working feverishly toward a Guice release, and I plan on using Guice in the API anyway (we won't need *Aware interfaces). Bob On 2/1/07, Ted Husted <[EMAIL PROTECTED]> wrote: I tend to agree. Unless someone says they are ready, willing, and ablle to resolve the "new API" this weekend, lets just pull it out and roll 2.0.5 now. We can then slate the "new API" for 2.1.x, along with the AJAX/Dojo plugin. (Which, I believe, would be *plenty* for a 2.1.x, without getting into other things that aren't ready yet.) -Ted. On 2/1/07, Don Brown <[EMAIL PROTECTED]> wrote: > Yeah, I think we really need a commitment from Bob or someone else > willing to really finish this effort. If no one signs up, I'm all for > pull it out into the sandbox. Right now, there are too many duplicate > classes and code that is very confusing as a developer. Personally, I > think this should even be resolved in the 2.0.x branch. > > Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Future of Struts API (was ServletRequestAware Interface doubled)
OK, I'll try to roll 2.0.5 tonight, so that we can vote over the weekend, and try to get at least another beta out. -Ted. On 2/1/07, Bob Lee <[EMAIL PROTECTED]> wrote: I'm cool with that. I'm not going to finish it by this weekend--I'm working feverishly toward a Guice release, and I plan on using Guice in the API anyway (we won't need *Aware interfaces). Bob On 2/1/07, Ted Husted <[EMAIL PROTECTED]> wrote: > > I tend to agree. Unless someone says they are ready, willing, and > ablle to resolve the "new API" this weekend, lets just pull it out and > roll 2.0.5 now. > > We can then slate the "new API" for 2.1.x, along with the AJAX/Dojo > plugin. > > (Which, I believe, would be *plenty* for a 2.1.x, without getting into > other things that aren't ready yet.) > > -Ted. > > On 2/1/07, Don Brown <[EMAIL PROTECTED]> wrote: > > Yeah, I think we really need a commitment from Bob or someone else > > willing to really finish this effort. If no one signs up, I'm all for > > pull it out into the sandbox. Right now, there are too many duplicate > > classes and code that is very confusing as a developer. Personally, I > > think this should even be resolved in the 2.0.x branch. > > > > Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Future of Struts API (was ServletRequestAware Interface doubled)
As it turns out, the new API is being used by the StrutsObjectFactory. I'll put off rolling 2.0.5 until Sunday, in case anyone has a chance to look at refactoring the new API out of StrutsObjectFactory. Worse case, Nial has fixed the license headers, so we can roll it again either way. If anyone wants to take a crack at any of the other 2.0.5 issues, please feel free. -Ted. On 2/1/07, Ted Husted <[EMAIL PROTECTED]> wrote: OK, I'll try to roll 2.0.5 tonight, so that we can vote over the weekend, and try to get at least another beta out. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Pluggable URL building proposal
Ok, I had a little time tonight to put together a preliminary design for the URLBuilder. Here's what I have so far for the interface: URLBuilder +buildURL(CustomAttributes, ActionMapping) // this method is for when an action, namespace, method, etc. is supplied +buildURL(CustomAttributes, String) // this method is for when the url value itself is provided My expectation is each builder would use the default ActionMapper under the hood. From an infrastructure standpoint, it would be configured and injected the same as the ActionMapper is. The custom attributes that I've come up with so far are: CustomPortletAttributes: RenderRequest, RenderResponse windowState portletUrlType portletMode CustomServletAttributes: HttpServletRequest, HttpServletResponse encodeParams includeContext scheme I'm not exactly sure how we'll build these up. Either the client code of the builder will have to know how to build each type or we'll need a static helper class that does most of the work. I'll probably be taking a stab at implementation this weekend. Tom Patrick Lightbody wrote: Tom, How is this coming along? I imagine that some of this work would also relate to the ActionMapper interface, since it does have some responsibilities for rendering out URLs. Keep us posted. - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=59916&messageID=119811#119811 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
