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
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... I
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
> anyo
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 U
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 ar
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 vario
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,
-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
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
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?
---
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 wr
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
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
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
proble
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 abo
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
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
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 shou
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 i
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 a
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
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 us
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 anyon
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, Str
24 matches
Mail list logo
