The multiple unknown handler feature needs to be implemented. Yesterday I
started changing this patch:
http://jira.opensymphony.com/browse/XW-640
Because it uses some static helper classes, to use beans that are injected.
The plan was to wait until 2.2 to move this into trunk, but I was based on
Are there any news on this topic? It reads like there are missing parts that
need to be implemented before moving into trunk.
How to help out? Is there anything one can do to speed things up?
Piero
Am Montag 25 August 2008 15:19:45 schrieb Musachy Barroso:
> It wasn't technically a vote
---
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
--
View this message in context:
http://www.nabble.com/-VOTE--Bring-Convention-plugin-into-trunk-and-deprecate-Zer
hy
On Mon, Aug 25, 2008 at 9:10 AM, alvins <[EMAIL PROTECTED]> wrote:
>
> So what was the outcome of the vote - is this moving into trunk?
> --
> View this message in context:
> http://www.nabble.com/-VOTE--Bring-Convention-plugin-into-trunk-and-deprecate-Zero-Config-tp1722279
So what was the outcome of the vote - is this moving into trunk?
--
View this message in context:
http://www.nabble.com/-VOTE--Bring-Convention-plugin-into-trunk-and-deprecate-Zero-Config-tp17222798p19143586.html
Sent from the Struts - Dev mailing list archive at Nabble.com
Am Dienstag, 15. Juli 2008 16:43:22 schrieb Piero Sartini:
> > Then the classes that match the actionPackages
> > (named packages like "com.my.package") will be queued for processing,
> > as well as classes whose package matches one of the locators
> > ("action", "actions", etc). If you name your p
I was trying to find how if it was a different problem. After we
started using ASM only classes that match either the package name or
the "*Action" are loaded. Sometimes there are errors, for example, the
eclipse jar files have a bunch of "*Action" classes in packages that
have ".actions." in the
Just to update this thread quick...
The error is occurs mostly because the perm size is filling up or the
loading of a specific class is causing the ClassLoader to error out.
This the primary reason why I added the exclusions list. The other
reason is that scanning the entire classpath and
> I did use Toplink Essentials and in its jar there is a package
> called "persistence.antlr.actions". So the locators matched. Don't know why
> it comes to an error, but I think it is the same reason Brian excluded
> hibernate and some other packages by default.
>
Yes, that could be tricky, yet t
> Yes, the wiki needs to be updated, I think the most common use case
> will be that people will have their actions in their classes folder,
> instead of jar files, so I changed it, but we can talk about it.
I don't really care because its just one line of config. Personally I am with
Brian and t
Yes, the wiki needs to be updated, I think the most common use case
will be that people will have their actions in their classes folder,
instead of jar files, so I changed it, but we can talk about it.
musachy
On Tue, Jul 15, 2008 at 10:43 AM, Piero Sartini <[EMAIL PROTECTED]> wrote:
>> Then the
> Then the classes that match the actionPackages
> (named packages like "com.my.package") will be queued for processing,
> as well as classes whose package matches one of the locators
> ("action", "actions", etc). If you name your packages using
> actionPackages, the plugin will find the classes i
the important code is this PackageBasedActionConfigBuilder:findActions:
ClassFinder finder = new ClassFinder(getClassLoader(),
buildUrlSet().getUrls(), true);
// named packages
if (actionPackages != null) {
for (String packageName
> yes, the locators. We could have an option like a "jar locators" which
> would limit the jars scanned, it would be really easy to implement
> with the URLSets.
This could be a solution, but I can't imagine how to find a restriction that
is useful We had to enforce a naming scheme on the mod
yes, the locators. We could have an option like a "jar locators" which
would limit the jars scanned, it would be really easy to implement
with the URLSets.
musachy
On Tue, Jul 15, 2008 at 3:51 AM, Piero Sartini <[EMAIL PROTECTED]> wrote:
> Am Dienstag, 15. Juli 2008 09:44:52 schrieb Piero Sartini
Am Dienstag, 15. Juli 2008 09:44:52 schrieb Piero Sartini:
> The modules may be deployed in their own JAR file. If we disable global
> scanning they would be ignored, right?
JARScanning of course, not global scanning.
-
To unsubs
Am Dienstag, 15. Juli 2008 03:53:26 schrieb Musachy Barroso:
> The jars excluded from the scan will never have actions, like
> freemarker, velocity, jdk jars, etc. You can completely disable the
> scanning of jar files, and the plugin will scan only the specified
> packages, wouldn't that cover the
>
> I opened WW-2576 some time ago.
>
> After looking at the source I came to the conclusion that the convention
> plugin is designed to exclude a whole bunch of packages from classpath
> scanning. For my feeling that is not the best way to go because you can never
> be sure what is on your classpa
Am Freitag, 23. Mai 2008 05:51:39 schrieb Musachy Barroso:
> Yes I had a similar problem, and is not jdbc specific, it's just
> convention scanning too much, I can't really remember what my problem
> was, but convention was scanning the whole classpath. Anyway,
> that's why I added "struts.conventi
Musachy Barroso wrote:
Yes, that option is totally viable now that they can co-exist(assuming
that multiple unknown handlers are supported). One drawback it has, is
that for new users of the plugin, it would be confusing to have 2 sets
of similar annotations. The other problem would be the docume
Yes, that option is totally viable now that they can co-exist(assuming
that multiple unknown handlers are supported). One drawback it has, is
that for new users of the plugin, it would be confusing to have 2 sets
of similar annotations. The other problem would be the documentation,
we don't have ma
Musachy Barroso wrote:
WW-2667 is fixed on trunk. Has anybody taken a look at the multiple
unknown handlers proposal? I have the code ready to go but I am still
waiting for some confirmation :)
Hi Musachy, I think the proposal is fine. The use of multiple unknown
handlers will be rare.
H
WW-2667 is fixed on trunk. Has anybody taken a look at the multiple
unknown handlers proposal? I have the code ready to go but I am still
waiting for some confirmation :)
musachy
On Wed, Jun 4, 2008 at 5:30 PM, Musachy Barroso <[EMAIL PROTECTED]> wrote:
> I created a proposal page on the wiki for
ngs to convention so REST can plugin nicely.
>>> I have the rest-showcase app working. Does anybody have a bigger REST
>>> app to test against?
>>>
>>> //is svn down?
>>>
>>> musachy
>>>
>>> --
es anybody have a bigger REST
>> app to test against?
>>
>> //is svn down?
>>
>> musachy
>>
>> ---------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail:
Thanks for the testing :)
I added the dependency to rest-showcase to make build again. I also
added a note to the 2.1.1 release notes.
musachy
On Fri, Jun 6, 2008 at 10:24 AM, Jeromy Evans
<[EMAIL PROTECTED]> wrote:
> Hi Musachy,
>
> Just letting you know I just moved a large rest-plugin app fro
Hi Musachy,
Just letting you know I just moved a large rest-plugin app from an old
2.1.3-snapshot to the current head to try things out...and it still
works :-)
Here's what I had to do:
- added codebehind as a direct dependency for the application (for
now) as it was removed as a dependenc
I created a proposal page on the wiki for this:
http://cwiki.apache.org/confluence/display/S2WIKI/Convention%2CCodebehind+and+REST+2.3
I also opened a ticket for fixing the depenency between
REST->Codebehind, which I don't see why it should exists:
https://issues.apache.org/struts/browse/WW-2667
Some small changes would be needed to Codebehind, adding a few
configuration parameters, which REST now sets by overwriting the base
class. But we should do this anyway.
musachy
On Wed, Jun 4, 2008 at 9:25 AM, Musachy Barroso <[EMAIL PROTECTED]> wrote:
> Here is yet another idea, this one assumes
Here is yet another idea, this one assumes that multiple
UnknowHandler(s) can be stacked (which I am prototyping). If we modify
ControllerClasspathPackageProvider, so it delegates to an instance of
ClasspathPackageProvider instead of extending it, and using reflection
for the delegation of those fe
gt;
>> ---------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>>
>
> --
> View this message in context:
> http://www.nabble.
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
--
View this message in context:
http://www.nabble.com/-VOTE--Bring-Convention-plug
> Don's point is a valid one, but I also hope that he agrees that its a good
> thing to somehow combine REST and Convention. I am not so sure that
> changing how Struts fundamentally works so that we can include more and
> competing plugins at runtime is a good thing. It is that type of confusion
anyway,
i am not follow the REST feature
but i can see the ZeroConfig/CodeBehind/SmartURL/JSON vs current REST
is a smiliar but different world
anyone can share what should we do for this case?
i think this is good for us that investing our time, to know, which
one is depreciated and which one
------
>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>
>>>
>>
>>
>>
>> --
>> "Hey you! Would you help me to carry the stone?" Pink Floyd
>>
>> -
gt;>
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
>
>
> --
> "Hey you! Would you help me to carry the stone?
The only conflict between codebehind and convention is on the
UnknownHandler. If struts would support multiple UnknownHandler(s),
like it supports multiple PackageProvider(s), we wouldn't have a
problem at all, and they could be able to co-exist without knowing
anything about each other. Given a re
Why don't we get codebehind and rest together and make a
codebehind-rest-legacy.jar project. And make REST just depend on
convention, wouldn't that keep backward compatibility while allowing
us to move forward with REST+Convention?
musachy
On Fri, May 30, 2008 at 9:39 PM, Don Brown <[EMAIL PROTEC
On Thu, May 29, 2008 at 7:21 AM, dusty <[EMAIL PROTECTED]> wrote:
> So lets do it and consolidate all of the configuration automation into
> Convention. We can get the new Convention and REST in 2.1.3-SNAPSHOT and
> then update the Codebehind page that its being absorbed into Convention.
>
> I say
gt; From: [EMAIL PROTECTED]> To:
> dev@struts.apache.org> Subject: Re: [VOTE] Bring Convention plugin into trunk
> and deprecate Zero Config> > On Fri, May 30, 2008 at 7:56 AM, Musachy Barroso
> <[EMAIL PROTECTED]> wrote:> > > Sounds like a plan but we don't have
>>>>>>>> locators to find templates. The ResultPath and all the template
>> >>>>>>>> configuration is used elsewhere and separate. I keep my templates
>> in
>> >>>>>>>> WEB-INF/content and my actions are in *
gt;>>>> arbitrary. Even if you place your templates in /, you can still
> have
> >>>>>>>> a
> >>>>>>>> locator like "actions" and exclude packages however you need.
> >>>&
>>>> All that is necessary is that the namespace of the action and the
>>>>>>>> result are
>>>>>>>> matched. Therefore you could do this:
>>>>>>>>
t;>>> result -> /some-namespace/my-cool.ftl
>>>>>>>
>>>>>>> This works fine and the locator and exclude packages hasn't been
>>>>>>> modified.
>>>>>>> Unless I'm missing something, you case sh
That's not a problem, particularly if we jarjar the dependency in the xwork jar.
Don
On Wed, May 28, 2008 at 10:12 AM, Musachy Barroso <[EMAIL PROTECTED]> wrote:
> It depends on ASM
>
> musachy
>
> On Tue, May 27, 2008 at 8:07 PM, Don Brown <[EMAIL PROTECTED]> wrote:
>> My vote is we bring the cl
It depends on ASM
musachy
On Tue, May 27, 2008 at 8:07 PM, Don Brown <[EMAIL PROTECTED]> wrote:
> My vote is we bring the classes into XWork to replace the existing
> classpath scanner.
>
> Don
>
> On Wed, May 28, 2008 at 10:04 AM, Musachy Barroso <[EMAIL PROTECTED]> wrote:
>> I will check it out
My vote is we bring the classes into XWork to replace the existing
classpath scanner.
Don
On Wed, May 28, 2008 at 10:04 AM, Musachy Barroso <[EMAIL PROTECTED]> wrote:
> I will check it out. Is this something that another plugin could use
> or core itself?
>
> musachy
>
> On Tue, May 27, 2008 at 7
I will check it out. Is this something that another plugin could use
or core itself?
musachy
On Tue, May 27, 2008 at 7:24 PM, Don Brown <[EMAIL PROTECTED]> wrote:
> Hmm...this should really be another thread, but there is a much better
> solution for classpath scanning - xbean-finder. It is a sm
The blockers were:
1. Support REST
2. Support Codebehind
We agreed on #1, and it should be working (more testing would be
nice). We haven't got to an agreement on #2 yet.
musachy
On Tue, May 27, 2008 at 7:27 PM, Paul Benedict <[EMAIL PROTECTED]> wrote:
> Does this vote have a conclusion? Does t
Does this vote have a conclusion? Does the discussion merit a wiki page so
we can keep this thread for the vote itself?
Paul
On Tue, May 27, 2008 at 9:18 AM, Musachy Barroso <[EMAIL PROTECTED]> wrote:
> You are right and I am confused with another problem, if your action is:
>
> action ->act
Hmm...this should really be another thread, but there is a much better
solution for classpath scanning - xbean-finder. It is a small library
used by OpenEJB and Geronimo, three classes, that scans the classpath,
but uses a technique that doesn't require the class to be loaded into
memory. As a re
You are right and I am confused with another problem, if your action is:
action ->actions.MyCoolAction (@ResultPath("/"))
result -> /my-cool.ftl
what you get is a bunch of (with different jars)
SEVERE: Unable to scan [C:\Program
Files\apache-tomcat-6.0.16\lib\catalina.jar] for resources
Musachy Barroso wrote:
The scanning doesn't have anything to do with the location of the JSP files.
It is entirely based on the set of package locators and exclude packages. It
uses the classpath scanning mechanism that simply opens all the JAR files
and looks at them. It only loads a class into
> The scanning doesn't have anything to do with the location of the JSP files.
> It is entirely based on the set of package locators and exclude packages. It
> uses the classpath scanning mechanism that simply opens all the JAR files
> and looks at them. It only loads a class into the JVM if it is
Musachy Barroso wrote:
The plugin will scan the entire classpath, but that's not to large of an
issue and pretty fast (considering). The issue is when it starts loading
classes into the perm space to determine if the class is in fact an Action
or not. This is the part where your perm space can be
> The plugin will scan the entire classpath, but that's not to large of an
> issue and pretty fast (considering). The issue is when it starts loading
> classes into the perm space to determine if the class is in fact an Action
> or not. This is the part where your perm space can become full and the
body have a bigger REST
app to test against?
//is svn down?
musachy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
View this message in context:
http://www.nabble.
>
> Yes I had a similar problem, and is not jdbc specific, it's just
> convention scanning too much, I can't really remember what my problem
> was, but convention was scanning the whole classpath.
I remember what it was, because the jsps in rest-showcase where under
the root of webapp, I added @Re
> First off, Hi.. My name is Dusty Pearce and I am long time webwork user.
> How do I pronounce your name? In my head its something like
> Moose-atch-ee
Pretty close (outlook always wants to "fix" it and suggests "Mustache" ) :)
>
> With that out of the way, I feel like I am missing somethin
-
>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>
>>>
>>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/-VOTE--Bring-Convention-plugin-into
app to test against?
> >
> > //is svn down?
> >
> > musachy
> >
> > ---------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PR
s to convention so REST can plugin nicely.
>> I have the rest-showcase app working. Does anybody have a bigger REST
>> app to test against?
>>
>> //is svn down?
>>
>> musachy
>>
>> ---------------------
>> T
il: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
--
View this message in context:
http://www.nabble.com/-VOTE--Bring-Convention-plugin-into-trunk-and-deprecate-Zero-Config-tp17222798p17397185.html
Sent from the Struts - Dev mailing list archive at N
> I am trying to figure out what this means! :-) Sounds humorous.
yeah, just kidding :)
I added a couple of settings to convention so REST can plugin nicely.
I have the rest-showcase app working. Does anybody have a bigger REST
app to test against?
//is svn down?
musachy
--
I don't think XML vs annotations is a correct split for a plugin. It would
be a split on unrelated features.
In that case then REST should continue to be in it's own plugin. I
> don't know where Paul gets those ideas :).
I am trying to figure out what this means! :-) Sounds humorous.
Paul
> What I meant is that with some effort, instead of the convention plugin
> providing both Configuration and Mapping/Invocation is could be split into
> two: a plugin that provides config via annotation and a plugin that provides
> mapping & invocation conventions. If that were the case then devel
What I meant is that with some effort, instead of the convention plugin
providing both Configuration and Mapping/Invocation is could be split
into two: a plugin that provides config via annotation and a plugin that
provides mapping & invocation conventions. If that were the case then
developer
Sounds good Musachy.
Musachy Barroso wrote:
As far as I can see the only dependency between REST and Codebehind is
this class:
http://svn.apache.org/viewvc/struts/struts2/trunk/plugins/rest/src/main/java/org/apache/struts2/rest/ControllerClasspathPackageProvider.java?view=markup
which all it d
On Fri, May 16, 2008 at 11:05 AM, Musachy Barroso <[EMAIL PROTECTED]> wrote:
> Not really, but so far some people think we should support it on
> others think it is a bad idea.
Right. But my point is that building consensus, while it may take longer,
provides a better basis on which to move forw
Well, votes can be just talk sometimes If someone wants to branch and
write a combination plugin or fix the dependency in another way, go for it.
Nothing wrong with experimental branches -- in fact Maven does this
constantly.
Paul
On Fri, May 16, 2008 at 1:05 PM, Musachy Barroso <[EMAIL PROTE
Not really, but so far some people think we should support it on
others think it is a bad idea.
musachy
On Fri, May 16, 2008 at 2:01 PM, Martin Cooper <[EMAIL PROTECTED]> wrote:
> On Fri, May 16, 2008 at 10:50 AM, Musachy Barroso <[EMAIL PROTECTED]> wrote:
>
>> As far as I can see the only depend
On Fri, May 16, 2008 at 10:50 AM, Musachy Barroso <[EMAIL PROTECTED]> wrote:
> As far as I can see the only dependency between REST and Codebehind is
> this class:
>
>
> http://svn.apache.org/viewvc/struts/struts2/trunk/plugins/rest/src/main/java/org/apache/struts2/rest/ControllerClasspathPackageP
I think it also depends on the unknown mapping handler in Codebehind. The
class takes care of determining the jsp to use when nothing is specified in
the configurations.
On Fri, May 16, 2008 at 1:50 PM, Musachy Barroso <[EMAIL PROTECTED]> wrote:
> As far as I can see the only dependency betwe
As far as I can see the only dependency between REST and Codebehind is
this class:
http://svn.apache.org/viewvc/struts/struts2/trunk/plugins/rest/src/main/java/org/apache/struts2/rest/ControllerClasspathPackageProvider.java?view=markup
which all it does is use Codebehind to detect actions that en
ly and concentrated effort
>>> with
>>> regards to this plugin :)
>>>
>>> Are there any objections to merging these plugins? Does the REST plugin
>>> embody a set of conventions on urls alone, or does it go deeper than
>>> that?
>>>
>&g
My head is spinning now :). Can you use REST with Xml Conf?
musachy
On Fri, May 16, 2008 at 2:30 AM, Jeromy Evans
<[EMAIL PROTECTED]> wrote:
> Jeromy Evans wrote:
>>
>> I wouldn't rush into this decision.
>>
>> Users of the REST plugin require @Namespace, @Result, etc annotations.
>> Creating a
Jeromy Evans wrote:
I wouldn't rush into this decision.
Users of the REST plugin require @Namespace, @Result, etc
annotations. Creating a duplicate set of annotations with the same
purpose is not sensible.
It's appropriate that the REST plugin has a dependency on the plugin
that auto-popul
-
From: "Musachy Barroso" <[EMAIL PROTECTED]>
Sent: Thursday, May 15, 2008 7:48 PM
To: "Struts Developers List"
Subject: Re: [VOTE] Bring Convention plugin into trunk and deprecate Zero
Config
Indeed :). I don't see why we shouldn't.
musachy
On Thu,
PM
> To: "Struts Developers List"
> Subject: Re: [VOTE] Bring Convention plugin into trunk and deprecate Zero
> Config
>
>> Indeed :). I don't see why we shouldn't.
>>
>> musachy
>>
>> On Thu, May 15, 2008 at 5:37 PM, Paul Benedict
?
--
From: "Musachy Barroso" <[EMAIL PROTECTED]>
Sent: Thursday, May 15, 2008 7:48 PM
To: "Struts Developers List"
Subject: Re: [VOTE] Bring Convention plugin into trunk and deprecate Zero
Config
Indeed :). I don't see why we shouldn't.
musachy
O
Indeed :). I don't see why we shouldn't.
musachy
On Thu, May 15, 2008 at 5:37 PM, Paul Benedict <[EMAIL PROTECTED]> wrote:
> It appears you're making the argument for combining these plugins. :-) +1 to
> that.
>
> Paul
>
> On Thu, May 15, 2008 at 4:20 PM, Musachy Barroso <[EMAIL PROTECTED]> wrote
It appears you're making the argument for combining these plugins. :-) +1 to
that.
Paul
On Thu, May 15, 2008 at 4:20 PM, Musachy Barroso <[EMAIL PROTECTED]> wrote:
> Looking at the rest plugin, something doesn't feel right. Doesn't the
> dependency between REST and Codebehind looks wrong? From
Looking at the rest plugin, something doesn't feel right. Doesn't the
dependency between REST and Codebehind looks wrong? From
http://struts.apache.org/2.x/docs/plugins.html
"Plugins are not loaded in any particular order. Plugins should not
have dependencies on each other. A plugin may depend on
uot;
Sent: Thursday, May 15, 2008 2:21 PM
Subject: Re: [VOTE] Bring Convention plugin into trunk and deprecate Zero
Config
I don't think there is any page that compares them, quick overview:
Code-behind: Provides default mappings for pages without actions,
default results (finds templa
>>
>>> It could also help some of us understand what each one does ;).
>>>
>>> Al.
>>>
>>> - Original Message - From: "Bob Tiernay" <[EMAIL PROTECTED]>
>>> To: "Struts Developers List"
>>> Sent:
gt;
To: "Struts Developers List"
Sent: Thursday, May 15, 2008 2:21 PM
Subject: Re: [VOTE] Bring Convention plugin into trunk and deprecate Zero
Config
I don't think there is any page that compares them, quick overview:
Code-behind: Provides default mappings for pages without actions,
d
; It could also help some of us understand what each one does ;).
>
> Al.
>
> - Original Message - From: "Bob Tiernay" <[EMAIL PROTECTED]>
> To: "Struts Developers List"
> Sent: Wednesday, May 14, 2008 8:43 PM
> Subject: RE: [VOTE] Bring Conven
From: "Bob Tiernay" <[EMAIL PROTECTED]>
To: "Struts Developers List"
Sent: Wednesday, May 14, 2008 8:43 PM
Subject: RE: [VOTE] Bring Convention plugin into trunk and deprecate Zero
Config
+1
I think that this plugin is of great worth to every day development. I
TED]> To:
> dev@struts.apache.org> Subject: [VOTE] Bring Convention plugin into trunk and
> deprecate Zero Config> > With the addition of @IntereceptorRefs to the
> Convention plugin, it is> now possible to do most of the action mapping using
> annotations. Also> having 2 pl
We all agree on updating the REST plugin, but we can't do that until
Convention lands on trunk. If we are divided on the topic of
Convention supporting Codebehind vs keeping them as stand alone
plugins, should we then vote on that?
musachy
On Wed, May 14, 2008 at 12:46 PM, Brian Pontarelli <[EMAI
+1
Here are the goals of this plugin. Any movement to integrate plugins and
make all things compatible (which I gracefully disagree with) MUST
satisfy these goals:
- Simple API that is fixed and will not change anytime soon
- Usable with absolutely no configuration or annotations
- M
It turns out that making codebehind work from convention is quite easy
(DI FTW!), but again, I think this would be a bad choice.
musachy
On Wed, May 14, 2008 at 11:18 AM, Musachy Barroso <[EMAIL PROTECTED]> wrote:
> I will take a look at the migration of the REST plugin. But I don't
> see the poi
FWIW, I am also against the name "convention" plugin. Conventions change
over time, and I don't think any one plugin should be "the" convention. I'd
like to have a name that explains the intent behind the convention. That's
why names like Zero Config or REST are much more affable.
Paul
On Wed, Ma
I will take a look at the migration of the REST plugin. But I don't
see the point of supporting codebehind from convention, as they are
separate plugins, users can choose any one they like, we are just
saying that "convention" is the recommended one, and there won't be
more development on codebehin
I reaffirm my -1. Since there is overlap between the three plugins, I
suggest either a new plugin is created that merges all their respective
features, or one of the existing plugins should absorb the others.
Paul
On Wed, May 14, 2008 at 9:05 AM, Jeromy Evans <
[EMAIL PROTECTED]> wrote:
> I have
I haven't tested the latest Convention plugin yet so I can't vote yet,
but I'd probably give a [-1] because I don't like the options provided.
I support moving Convention plugin from the sandbox to become the
recommended convention for new users, replacing ZeroConfig and CodeBehind.
However, I
+0
Personally, I'd like to see the the CodeBehind, Zero-Config, Convention and
Rest plugins better integrated and the overlap reduced. Right now there are
multiple ways to skin the same cat and that can be confusing to new and
experienced users alike. The question they will likely have is: Which
p
I've spoken to quiet a few people that are already using zero-config in
production. I understand that it was always experimental, but it was
also solid and now used. I'd have to agree with Don (even though my
vote is now non-binding) and vote +0 if the existing zero-config
features are suppor
Has any work been done to support existing zero config applications
with this new plugin? If not, I'd kinda consider that a blocker (-1)
because a sufficiently flexible configuration system should be able to
support multiple conventions. Also, someone will have to sign up to
convert the REST plug
+1
2008/5/14 Musachy Barroso <[EMAIL PROTECTED]>:
> With the addition of @IntereceptorRefs to the Convention plugin, it is
> now possible to do most of the action mapping using annotations. Also
> having 2 plugins to do the same thing is really confusing for users,
> so we should deprecate Zero C
1 - 100 of 103 matches
Mail list logo
