+1 to get rid of "do" support.
Cheers,
Paul
On Mon, Dec 22, 2014 at 12:34 AM, Lukasz Lenart
wrote:
> 2014-12-21 23:19 GMT+01:00 Paul Benedict :
> > Why do we support the "do" prefix at all? I don't know the answer. I'd
> just
> > like to know how it came to be.
>
> No idea :)
>
>
> Regards
> -
2014-12-21 23:19 GMT+01:00 Paul Benedict :
> Why do we support the "do" prefix at all? I don't know the answer. I'd just
> like to know how it came to be.
No idea :)
Regards
--
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/
---
+1, no real need for it.
On Sun, Dec 21, 2014 at 2:24 PM, Lukasz Lenart wrote:
> What do you think about throwing away support for the "do" prefix? If
> an action method cannot be found, the framework will prepend the "do"
> prefix to it and will try again, this pushes a bit of hassle into flow
>
Why do we support the "do" prefix at all? I don't know the answer. I'd just
like to know how it came to be.
PS: I am in favor of simplifying the internals of Struts. I don't like
having multiple ways of naming an execution method.
Cheers,
Paul
On Sun, Dec 21, 2014 at 1:24 PM, Lukasz Lenart
wro
What do you think about throwing away support for the "do" prefix? If
an action method cannot be found, the framework will prepend the "do"
prefix to it and will try again, this pushes a bit of hassle into flow
logic. Dropping support will allow simplify code in few places.
Regards
--
Łukasz
+ 4
Steven Benitez wrote:
> I said:
>> I prefer strong decoupling between layers; accessing Servlet spec artifacts
>> smells.
> [...] wouldn't the servlet API and Struts actions be considered controllers?
I think my view of an S2 action is that it's more of a command handler,
coincidentally called mo
2014-12-16 0:11 GMT+01:00 Steven Benitez :
>>> I much prefer a strong decoupling between layers, and accessing Servlet spec
> artifacts is a smell.
>
> Decoupling between layers is definitely a good thing, but wouldn't the
> servlet API and Struts actions both be considered the controller layer?
>
2014-12-15 17:23 GMT+01:00 Ken McWilliams :
> +1 for the request/response wrappers. Have you had a chance to check out:
> https://tiles.apache.org/tiles-request/ ?
Thanks, will do!
> +1 for getting rid of Strings. Could see the benefit of what you say, but
> if you only meant getting rid of con
Well if you're implementing a custom result type for which a currently
defined method does not exists, then you'll probably touch the response.
Although everything normal is covered. But why would you need to touch the
request (the raw request object and not an Aware-Interface) when using
Struts2?
> Date: Mon, 15 Dec 2014 16:49:32 -0600
> Subject: Re: Few ideas related to Struts 3
> From: pbened...@apache.org
> To: dev@struts.apache.org
>
> Why do you guys find it bad to access the raw request/response? I haven't
> found a problem doing that as a fallback.
>> I much prefer a strong decoupling between layers, and accessing Servlet spec
artifacts is a smell.
Decoupling between layers is definitely a good thing, but wouldn't the
servlet API and Struts actions both be considered the controller layer?
Assuming so, why do you think accessing the Servlet A
I think it's just that-a last ditch fallback.
I much prefer a strong decoupling between layers, and accessing Servlet
spec artifacts is a smell.
On Dec 15, 2014 5:49 PM, "Paul Benedict" wrote:
> Why do you guys find it bad to access the raw request/response? I haven't
> found a problem doing tha
Why do you guys find it bad to access the raw request/response? I haven't
found a problem doing that as a fallback. I'd like to know what you think.
Cheers,
Paul
On Mon, Dec 15, 2014 at 10:23 AM, Ken McWilliams
wrote:
>
> +1 for the request/response wrappers. Have you had a chance to check out:
+1 for the request/response wrappers. Have you had a chance to check out:
https://tiles.apache.org/tiles-request/ ?
+1 for getting rid of Strings. Could see the benefit of what you say, but
if you only meant getting rid of const Strings in favour of enums that
alone would be pretty nice.
On Su
Lukasz Lenart wrote:
>
> Request/Response wrappers
> Right now user can access raw Request or Response [...]
Seems reasonable, although I wonder if the appearance of not being able to
get the raw request/response will make people run away--they're very used
to doing things icky.
> No more Strin
Hi,
I would like to share few ideas I have that should be
implemented/introduced in Struts 3.
Request/Response wrappers
Right now user can access raw Request or Response which is quite often
a bad idea. I would like to wrap them with custom interfaces with
default implementation - this will allow
16 matches
Mail list logo
