On 7/25/06, Jason Carreira <[EMAIL PROTECTED]> wrote:
Why are we trying to follow what Stripes has done? I'm sure Stripes is nice,
but why do
we need to try to follow what it does instead of trying to figure out what
makes the most
sense to us?
Why not start with what Stripes has done, and th
>
> Though, I would strongly suggest that we try to
> follow the Stripes
> annotations wherever possible. And if there's a hard
> reason why we
> want to use a different term, we should work with Tim
> on an
> alternative. There's really no reason to have two
> annotation APIs that
> are trying to
On 7/25/06, Jason Carreira <[EMAIL PROTECTED]> wrote:
@Action to mark it as an Action method?
On 7/25/06, Bob Lee <[EMAIL PROTECTED]> wrote:
+1 for @Action
Action is already so overloaded, it's painful to see us trying to
reuse it again in another context. Sure, we have an Action interface,
On 7/25/06, Don Brown <[EMAIL PROTECTED]> wrote:
however we would have to thoroughly think
through the consequences.
Which in my mind puts it on the map for phase 2 / Struts 3.
-Ted.
-
To unsubscribe, e-mail: [EMAIL PROTECTED
+1 for @Action
On 7/25/06, Jason Carreira <[EMAIL PROTECTED]> wrote:
>
>
> Works for me. What should we call this annotation?
> @Published?
@Action to mark it as an Action method?
-
Posted via Jive Forums
http://forums.opensy
Instead of returning a Result object, we can also consider calling out to a
result method. This is how Rails works. For example:
class FooAction ... {
Foo foo = new Foo(); // populated from request parameters.
public void create() {
if (foo.isValid())
redirectTo("ListFoos");
else
On 7/25/06, Ted Husted <[EMAIL PROTECTED]> wrote:
On 7/25/06, Jason Carreira <[EMAIL PROTECTED]> wrote:
> @Action to mark it as an Action method?
Stripes uses the annontation @DefaultHandler where we would configure
a default action, which might imply the annotation @Handler for what
we are talk
Tim Fennell wrote:
I was going to chime in on this, so I may as well now. Stripes, through
it's default way of routing events, will allow a submitted form or URL
to invoke any method that is public no-arg and returns a Resolution -
this seems much safer because Resolution is a Stripes specific
While it might imply that, Stripes actually uses
@HandlesEvent
Which can take an optional String parameter which is the name of the
handled event (which is defaulted to the method name otherwise)
I was going to chime in on this, so I may as well now. Stripes,
through it's default w
On 7/25/06, Ted Husted <[EMAIL PROTECTED]> wrote:
On 7/25/06, Jason Carreira <[EMAIL PROTECTED]> wrote:
> @Action to mark it as an Action method?
Stripes uses the annontation @DefaultHandler where we would configure
a default action, which might imply the annotation @Handler for what
we are talk
On 7/25/06, Jason Carreira <[EMAIL PROTECTED]> wrote:
@Action to mark it as an Action method?
Stripes uses the annontation @DefaultHandler where we would configure
a default action, which might imply the annotation @Handler for what
we are talking about here.
* http://stripes.mc4j.org/confluen
Sorry about the double-post, thought I hit cancel in time :)
Speaking of @Remotable... might that make a good tie-in for the DWR
integration, or indeed any other AJAX-type integration? Kill two birds
with one stone is what I'm getting at... marks a method as available for
DWR/AJAX remoting, as we
@Callable or @Executable, so it's more explicit? Maybe even @Remotable?
(nah, probably not)
Frank
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM: fzammetti
Yahoo: fzammetti
MSN: [EMAIL PROTECTED]
Java Web Parts -
http://javawebparts.sou
@Callable or @Executable, so it's somewhat more explicit?
Frank
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM: fzammetti
Yahoo: fzammetti
MSN: [EMAIL PROTECTED]
Java Web Parts -
http://javawebparts.sourceforge.net
Supplying the wheel, s
>
>
> Works for me. What should we call this annotation?
> @Published?
@Action to mark it as an Action method?
-
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=38338&messageID=75682#75682
--
That all makes sense, and thanks to you, Bob and Ted for your openness
in discussing these issues with a non-commiter. In looking through the
snapshot, I'm really excited to see where things are going, this
framework is going to be a joy to work with.
dave
On Tue, 2006-07-25 at 10:36 -0700, Don B
On 7/25/06, Don Brown <[EMAIL PROTECTED]> wrote:
In the future, I could see an interceptor that checks the method specified
for a
method-level annotation, and only if it is present, allow the request to
continue.
Works for me. What should we call this annotation? @Published?
_If_ you use a wildcard for an action, and _if_ you have that matched value as
your method name, then yes, you are intentionally allowing anyone to access any
method on that action class. This isn't a concern, IMO, because it was
explicitly allowed by the developer, where the old capability was
On Mon, 2006-07-24 at 21:27 -0400, Ted Husted wrote:
> On 7/24/06, David Evans <[EMAIL PROTECTED]> wrote:
> > I understand the security concerns, but the flexibility is far more
> > important to me. If a user wants to protect themselves, they can make
> > methods they don't want run by xwork privat
> I'd much rather annotate methods which can be called
> than specify them in
> XML.
>
> Also, this doesn't pose much of a security risk in
> practice as it only
> applies to public, no-arg methods which return String
> in actions.
>
> Bob
>
No-arg, yes, but it will convert anything else to a S
On 7/24/06, Bob Lee <[EMAIL PROTECTED]> wrote:
I'd much rather annotate methods which can be called than specify them in
XML.
Feel free to do so then.
Also, this doesn't pose much of a security risk in practice as it only
applies to public, no-arg methods which return String in actions.
Goi
I'd much rather annotate methods which can be called than specify them in
XML.
Also, this doesn't pose much of a security risk in practice as it only
applies to public, no-arg methods which return String in actions.
Bob
On 7/24/06, Ted Husted <[EMAIL PROTECTED]> wrote:
On 7/24/06, Don Brown <
On 7/24/06, David Evans <[EMAIL PROTECTED]> wrote:
I understand the security concerns, but the flexibility is far more
important to me. If a user wants to protect themselves, they can make
methods they don't want run by xwork private. Or maybe have an explicit
list of this,that,theOther.
The fr
If something like this was implemented, I'd hope that there would be a
way for those of us who use JSTL to still be able to specify method
names.
I understand the security concerns, but the flexibility is far more
important to me. If a user wants to protect themselves, they can make
methods they d
On 7/24/06, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
Potentially simple solution: a config switch to turn this functionality
on (the ability to specify method in the URL). It'd be off by default.
That way everyone can be happy... security "hole" closed, but easy to
activate for those who w
On 7/24/06, Don Brown <[EMAIL PROTECTED]> wrote:
The problem is that prefix allows anyone to specify the method to be called on
the action through the URL, any URL. I'd argue it is a security concern, so the
developer should have to work at explicitly allowing a method to be arbitrarily
called.
I agree it's a security concern, and it still is if the developer uses a
path pattern, except in the latter case, it's harder for us to secure.
I was hoping we'd store which methods are OK to invoke in the session or
sign them or something. For example, we could have tags like this:
...
Update
Potentially simple solution: a config switch to turn this functionality
on (the ability to specify method in the URL). It'd be off by default.
That way everyone can be happy... security "hole" closed, but easy to
activate for those who want it.
Frank
Don Brown wrote:
The problem is that pre
The problem is that prefix allows anyone to specify the method to be called on
the action through the URL, any URL. I'd argue it is a security concern, so the
developer should have to work at explicitly allowing a method to be arbitrarily
called.
Don
Bob Lee wrote:
I think "method:foo" migh
I think "method:foo" might still make sense. It's orthogonal to path
mappings. Maybe.
Bob
On 7/24/06, David Evans <[EMAIL PROTECTED]> wrote:
On Mon, 2006-07-24 at 15:15 -0700, Don Brown wrote:
> David Evans wrote:
> > I was looking in DefaultActionMapper and am wondering about the
> > compatib
On Mon, 2006-07-24 at 15:15 -0700, Don Brown wrote:
> David Evans wrote:
> > I was looking in DefaultActionMapper and am wondering about the
> > compatibilityMode switch functionality. In getMapping compatibilityMode
> > is used to see whether to check for the ! method idiom. I assume this is
> > b
David Evans wrote:
I was looking in DefaultActionMapper and am wondering about the
compatibilityMode switch functionality. In getMapping compatibilityMode
is used to see whether to check for the ! method idiom. I assume this is
because it will eventually be removed because wildcard mappings make
32 matches
Mail list logo
