: "Brian Pontarelli" <[EMAIL PROTECTED]>
To: "Struts Developers List"
Date: Tue, 23 Oct 2007 13:13:24 -0600
Subject: Re: [S2] Plugins gone wild!
This sounds more of a security level concern and is currently handled by
ACEGI and I would assume other projects as well. Or am
I'm more than happy to provide these archetypes as part of AppFuse
Light (or putting them under the Struts umbrella). I plan on adding
support for Struts 2 + JSF Plugin in the near future.
Currently, I'm waiting for Maven to release their ArchetypeNG plugin
that allows you to create archetypes fro
l
feautre? I'd rather annotate what I want to permit to be set than
exclude my DAO/Services (which are required by the Spring plugin).
- Original message -
From: "Ted Husted" <[EMAIL PROTECTED]>
To: "Struts Developers List"
Date: Tue, 23 Oct 2007 06:20:13 -040
gt;
To: "Struts Developers List"
Date: Tue, 23 Oct 2007 09:06:07 -0700
Subject: Re: [S2] Plugins gone wild!
> My initial
> idea was another flag on the parameter interceptor which, when enabled,
> would only set against the action when an annotation is present on the
> se
> My initial
> idea was another flag on the parameter interceptor which, when enabled,
> would only set against the action when an annotation is present on the
> setter. It might make more sense for this feature/annotation to be part
> of the annotations plugin. Does anyone else see this as a use
Ted Husted wrote:
On 10/22/07, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
True, but I was talking about APT, and in that case it's not really
making anything easier as far as I can tell... APT is already pretty
close to plug-and-play as you know... aside from making the config file
name a d
nt to permit to be set than
> exclude my DAO/Services (which are required by the Spring plugin).
>
>
> - Original message -
> From: "Ted Husted" <[EMAIL PROTECTED]>
> To: "Struts Developers List"
> Date: Tue, 23 Oct 2007 06:20:13 -0400
&g
"Ted Husted" <[EMAIL PROTECTED]>
To: "Struts Developers List"
Date: Tue, 23 Oct 2007 06:20:13 -0400
Subject: Re: [S2] Plugins gone wild!
So, to follow-up, the amended struts-core-plugins.jar list seems to be
* annotations plugin (new)
* codebehind plugin (including zero-c
So, to follow-up, the amended struts-core-plugins.jar list seems to be
* annotations plugin (new)
* codebehind plugin (including zero-config)
* tags plugin (new)
I'd like to keep codebehind in the core, since I believe we are on
track for making XML-action-free Struts apps the recommended a
On 10/22/07, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
> True, but I was talking about APT, and in that case it's not really
> making anything easier as far as I can tell... APT is already pretty
> close to plug-and-play as you know... aside from making the config file
> name a default, which wo
On 10/22/07, Don Brown <[EMAIL PROTECTED]> wrote:
> It might be interesting to have several "bundles":
> * Core - codebehind, dojo
> * Starter - codebehind, dojo, spring, jpa
> * Rest - codebehind, rest, dojo
This might be a great role for AppFuse-style Maven prototypes!
-Ted.
---
e name core may be confusing/misleading, more so as
> there is already struts2-core.
>
>
> - Original message -
> From: "Don Brown" <[EMAIL PROTECTED]>
> To: "Struts Developers List"
> Date: Tue, 23 Oct 2007 10:38:02 +1000
> Subject: Re: [S2] P
e may be confusing/misleading, more so as
there is already struts2-core.
- Original message -
From: "Don Brown" <[EMAIL PROTECTED]>
To: "Struts Developers List"
Date: Tue, 23 Oct 2007 10:38:02 +1000
Subject: Re: [S2] Plugins gone wild!
It might be interesting to have s
It might be interesting to have several "bundles":
* Core - codebehind, dojo
* Starter - codebehind, dojo, spring, jpa
* Rest - codebehind, rest, dojo
Of course, the value of this bundle concept is low for those that use
Maven 2 or any other transitive dependency system. For my rest
example ap
On 10/22/07, Ted Husted <[EMAIL PROTECTED]> wrote:
>
> Bringing together a couple of other threads, for Struts 2.1.x (or
> even Struts 2.2.x), we seem to be talking about
>
> * Creating a "plugin" artifact, along the lines of the "apps"
> artifact, which would include all the plugins we maintain i
Ted Husted wrote:
On 10/22/07, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
I'm still not 100% convinced there's a ton of benefit to this plugin
frankly, other than perhaps visibility, but it's there now in any case.
The benefit of the Dojo plugin isn't that it enables Dojo, but that it
enable
> * Creating a "struts2-core-plugin" artifact that would include the
> plugins that are needed to write a "typical" Struts 2 application.
I like this most :-)
To have a standard way of doing things makes development a lot faster and
easier.
> I haven't looked into yet, but we might also conside
On 10/22/07, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
> I'm still not 100% convinced there's a ton of benefit to this plugin
> frankly, other than perhaps visibility, but it's there now in any case.
The benefit of the Dojo plugin isn't that it enables Dojo, but that it
enables some of the Stru
On 10/22/07, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
> I'm still not 100% convinced there's a ton of benefit to this plugin
> frankly, other than perhaps visibility, but it's there now in any case.
That how I feel too with most of the plugins I've written. I wish we
could add a plugin voting
On Mon, October 22, 2007 6:48 am, Ted Husted wrote:
> Arguably, we could also include an Ajax plugin in the "standard
> array", but I would like to explore alternatives to the Dojo plugin. I
> think we should maintain a Dojo plugin, just as we plan to maintain a
> Spring plugin, but I'd also like t
Bringing together a couple of other threads, for Struts 2.1.x (or
even Struts 2.2.x), we seem to be talking about
* Creating a "plugin" artifact, along the lines of the "apps"
artifact, which would include all the plugins we maintain in the
Struts repository
* Creating a "struts2-core-plugin"
21 matches
Mail list logo
