Tag method calls and namespacing

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Tag method calls and namespacing

Marc Palmer Local
Hi,

Graeme has just committed a solution for invoking namespaced tags as  
methods.

This basically involves:

class YourTaglib {
     static namespace = 'user'
     def someTag = { attrs -> }
}

...and then invoking someTag in a controller would be achieved so:

def index = {
    user.someTag(...)
}

We've discussed this and wanted to know what you guys thought. I have  
a strong objection to the above approach because the namespace you  
define could clash with a "reserved" grails keyword/dynamic property  
i.e. "request" et al.

The dynamic property would be found first but the problem is that  
upgrading over time, either by upgrading plugins or Grails itself,  
your application could break. For example if Grails 1.1 added a  
"user" dynamic property to controllers all of a sudden you have  
runtime errors all over the place that you may or may not spot  
depending on the extent of your functional testing.

I feel this is particularly pernicious with plugins given the dynamic  
nature of Groovy and Grails, where a simple plugin upgrade might  
cause you a lot of not-so-obvious problems.

My preference is there for to have either:

tags.user.someTag(...)

or

userTags.someTag(...)

or maybe something else that scopes this safely?

I know I'm often a lone voice of dissent - what do others think? I  
believe that long-lived grails application development and  
maintenance where you have many plugins and potentially several  
grails upgrades to perform over time will get increasingly painful if  
we do not take very simple measures to minimize the potential for  
applications to break.

Marc


---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

Re: Tag method calls and namespacing

graemer
Just to be clear, I don't agree with Marc ;-)

And favour clarity of code over additional namespacing. I think that
plugins will inevitably have to be aware of changes to Grails core
over time and in the relatively unlikely event that something like
this happened would need to change the namespace which they occupy

Cheers

On 9/5/07, Marc Palmer <[hidden email]> wrote:

> Hi,
>
> Graeme has just committed a solution for invoking namespaced tags as
> methods.
>
> This basically involves:
>
> class YourTaglib {
>      static namespace = 'user'
>      def someTag = { attrs -> }
> }
>
> ...and then invoking someTag in a controller would be achieved so:
>
> def index = {
>     user.someTag(...)
> }
>
> We've discussed this and wanted to know what you guys thought. I have
> a strong objection to the above approach because the namespace you
> define could clash with a "reserved" grails keyword/dynamic property
> i.e. "request" et al.
>
> The dynamic property would be found first but the problem is that
> upgrading over time, either by upgrading plugins or Grails itself,
> your application could break. For example if Grails 1.1 added a
> "user" dynamic property to controllers all of a sudden you have
> runtime errors all over the place that you may or may not spot
> depending on the extent of your functional testing.
>
> I feel this is particularly pernicious with plugins given the dynamic
> nature of Groovy and Grails, where a simple plugin upgrade might
> cause you a lot of not-so-obvious problems.
>
> My preference is there for to have either:
>
> tags.user.someTag(...)
>
> or
>
> userTags.someTag(...)
>
> or maybe something else that scopes this safely?
>
> I know I'm often a lone voice of dissent - what do others think? I
> believe that long-lived grails application development and
> maintenance where you have many plugins and potentially several
> grails upgrades to perform over time will get increasingly painful if
> we do not take very simple measures to minimize the potential for
> applications to break.
>
> Marc
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>


--
Graeme Rocher
Grails Project Lead
http://grails.org

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

Re: Tag method calls and namespacing

Lee Butts
My vote goes to tags.user.someTag() syntax.

I actually think this has better clarity than only calling user.someTag, especially if the tag method is something like createLink instead of someTag :) I agree it's more verbose, but disagree that it is less clear.

My 2c

cheers

Lee

On 05/09/07, Graeme Rocher <[hidden email]> wrote:
Just to be clear, I don't agree with Marc ;-)

And favour clarity of code over additional namespacing. I think that
plugins will inevitably have to be aware of changes to Grails core
over time and in the relatively unlikely event that something like
this happened would need to change the namespace which they occupy

Cheers

On 9/5/07, Marc Palmer <[hidden email]> wrote:
> Hi,
>
> Graeme has just committed a solution for invoking namespaced tags as
> methods.
>

> This basically involves:
>
> class YourTaglib {
>      static namespace = 'user'
>      def someTag = { attrs -> }
> }
>
> ...and then invoking someTag in a controller would be achieved so:
>
> def index = {
>     user.someTag(...)
> }
>
> We've discussed this and wanted to know what you guys thought. I have
> a strong objection to the above approach because the namespace you
> define could clash with a "reserved" grails keyword/dynamic property
> i.e. "request" et al.
>
> The dynamic property would be found first but the problem is that
> upgrading over time, either by upgrading plugins or Grails itself,
> your application could break. For example if Grails 1.1 added a
> "user" dynamic property to controllers all of a sudden you have
> runtime errors all over the place that you may or may not spot
> depending on the extent of your functional testing.
>
> I feel this is particularly pernicious with plugins given the dynamic
> nature of Groovy and Grails, where a simple plugin upgrade might
> cause you a lot of not-so-obvious problems.

>
> My preference is there for to have either:
>
> tags.user.someTag(...)
>
> or
>
> userTags.someTag(...)
>
> or maybe something else that scopes this safely?
>
> I know I'm often a lone voice of dissent - what do others think? I
> believe that long-lived grails application development and
> maintenance where you have many plugins and potentially several
> grails upgrades to perform over time will get increasingly painful if
> we do not take very simple measures to minimize the potential for
> applications to break.
>
> Marc
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>


--
Graeme Rocher
Grails Project Lead
http://grails.org

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Tag method calls and namespacing

corey_s
On Wednesday 05 September 2007 02:31:28 am Lee Butts wrote:
> My vote goes to tags.user.someTag() syntax.
>
> I actually think this has better clarity than only calling user.someTag,
> especially if the tag method is something like createLink instead of
> someTag
>
> :) I agree it's more verbose, but disagree that it is less clear.
>

+1


---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

Re: Tag method calls and namespacing

graemer
In reply to this post by Lee Butts
Bah,

Ok but only within controllers surely? To me it doesn't make sense in
GSPs or tag libraries

And also as of 0.6 core tags can already be invoked without any prefix
from controllers tags and gsps, so this would break apps previous to
that

Cheers

On 9/5/07, Lee Butts <[hidden email]> wrote:

> My vote goes to tags.user.someTag() syntax.
>
> I actually think this has better clarity than only calling user.someTag,
> especially if the tag method is something like createLink instead of someTag
> :) I agree it's more verbose, but disagree that it is less clear.
>
> My 2c
>
> cheers
>
> Lee
>
>
> On 05/09/07, Graeme Rocher <[hidden email]> wrote:
> > Just to be clear, I don't agree with Marc ;-)
> >
> > And favour clarity of code over additional namespacing. I think that
> > plugins will inevitably have to be aware of changes to Grails core
> > over time and in the relatively unlikely event that something like
> > this happened would need to change the namespace which they occupy
> >
> > Cheers
> >
> > On 9/5/07, Marc Palmer <[hidden email]> wrote:
> > > Hi,
> > >
> > > Graeme has just committed a solution for invoking namespaced tags as
> > > methods.
> > >
> > > This basically involves:
> > >
> > > class YourTaglib {
> > >      static namespace = 'user'
> > >      def someTag = { attrs -> }
> > > }
> > >
> > > ...and then invoking someTag in a controller would be achieved so:
> > >
> > > def index = {
> > >     user.someTag(...)
> > > }
> > >
> > > We've discussed this and wanted to know what you guys thought. I have
> > > a strong objection to the above approach because the namespace you
> > > define could clash with a "reserved" grails keyword/dynamic property
> > > i.e. "request" et al.
> > >
> > > The dynamic property would be found first but the problem is that
> > > upgrading over time, either by upgrading plugins or Grails itself,
> > > your application could break. For example if Grails 1.1 added a
> > > "user" dynamic property to controllers all of a sudden you have
> > > runtime errors all over the place that you may or may not spot
> > > depending on the extent of your functional testing.
> > >
> > > I feel this is particularly pernicious with plugins given the dynamic
> > > nature of Groovy and Grails, where a simple plugin upgrade might
> > > cause you a lot of not-so-obvious problems.
> > >
> > > My preference is there for to have either:
> > >
> > > tags.user.someTag(...)
> > >
> > > or
> > >
> > > userTags.someTag(...)
> > >
> > > or maybe something else that scopes this safely?
> > >
> > > I know I'm often a lone voice of dissent - what do others think? I
> > > believe that long-lived grails application development and
> > > maintenance where you have many plugins and potentially several
> > > grails upgrades to perform over time will get increasingly painful if
> > > we do not take very simple measures to minimize the potential for
> > > applications to break.
> > >
> > > Marc
> > >
> > >
> > >
> ---------------------------------------------------------------------
> > > To unsubscribe from this list please visit:
> > >
> > >     http://xircles.codehaus.org/manage_email
> > >
> > >
> >
> >
> > --
> > Graeme Rocher
> > Grails Project Lead
> > http://grails.org
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe from this list please visit:
> >
> >     http://xircles.codehaus.org/manage_email
> >
> >
>
>


--
Graeme Rocher
Grails Project Lead
http://grails.org

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

Re: Tag method calls and namespacing

Marc Palmer Local

On 5 Sep 2007, at 10:35, Graeme Rocher wrote:

> Bah,
>
> Ok but only within controllers surely? To me it doesn't make sense in
> GSPs or tag libraries
>
> And also as of 0.6 core tags can already be invoked without any prefix
> from controllers tags and gsps, so this would break apps previous to
> that
>

It should be everywhere IMO where taglib are called as functions. I  
would even be in favour of tags.xxxx() working where xxxx is a non-
namespaced tag.

I would go far as to suggest that unqualified access to tag functions  
be deprecated prior to 1.0. i.e. myTag() would be deprecated and  
tags.myTag() would work throughout.

To give some justification for this - why should we allow unscoped  
access to tags but not methods of request, response, session etc?  
Because they will pollute the scope and also clash.

Graeme's gonna hate that one :)

Marc


---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

Re: Tag method calls and namespacing

graemer
On 9/5/07, Marc Palmer <[hidden email]> wrote:

>
> On 5 Sep 2007, at 10:35, Graeme Rocher wrote:
>
> > Bah,
> >
> > Ok but only within controllers surely? To me it doesn't make sense in
> > GSPs or tag libraries
> >
> > And also as of 0.6 core tags can already be invoked without any prefix
> > from controllers tags and gsps, so this would break apps previous to
> > that
> >
>
> It should be everywhere IMO where taglib are called as functions. I
> would even be in favour of tags.xxxx() working where xxxx is a non-
> namespaced tag.
>
> I would go far as to suggest that unqualified access to tag functions
> be deprecated prior to 1.0. i.e. myTag() would be deprecated and
> tags.myTag() would work throughout.
>
> To give some justification for this - why should we allow unscoped
> access to tags but not methods of request, response, session etc?
> Because they will pollute the scope and also clash.
>
> Graeme's gonna hate that one :)

It is a breaking change and I'm not willing to go with anymore of those

Cheers

>
> Marc
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>


--
Graeme Rocher
Grails Project Lead
http://grails.org

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

Re: Tag method calls and namespacing

graemer
To further elaborate why I don't believe this is necessary. To me this
smacks of the over engineering to avoid clashes that we get in typical
Java projects that try to address all future concerns

For me it is a theorotical problem the cost of which is silly. You
could equally get the problem if a plugin introduced another "tags"
variable. Its just adding layers for the sake of layers

A better solution would be to make sure that if an new variable is
introduced that clashes with a tag namespace that we throw a decent
error message such as:

"Sorry the name 'foo' is already taken by  a variable and hence cannot
be used as a tag library namespace in tag lib 'Bar'. Please change the
namespace that your tag lives in"

If this is not good enough we could always add the capability to alias
namespaces in a controller

static tagAlias = [g:"foo"]

and then later you can use the foo. prefix

Cheers
On 9/5/07, Graeme Rocher <[hidden email]> wrote:

> On 9/5/07, Marc Palmer <[hidden email]> wrote:
> >
> > On 5 Sep 2007, at 10:35, Graeme Rocher wrote:
> >
> > > Bah,
> > >
> > > Ok but only within controllers surely? To me it doesn't make sense in
> > > GSPs or tag libraries
> > >
> > > And also as of 0.6 core tags can already be invoked without any prefix
> > > from controllers tags and gsps, so this would break apps previous to
> > > that
> > >
> >
> > It should be everywhere IMO where taglib are called as functions. I
> > would even be in favour of tags.xxxx() working where xxxx is a non-
> > namespaced tag.
> >
> > I would go far as to suggest that unqualified access to tag functions
> > be deprecated prior to 1.0. i.e. myTag() would be deprecated and
> > tags.myTag() would work throughout.
> >
> > To give some justification for this - why should we allow unscoped
> > access to tags but not methods of request, response, session etc?
> > Because they will pollute the scope and also clash.
> >
> > Graeme's gonna hate that one :)
>
> It is a breaking change and I'm not willing to go with anymore of those
>
> Cheers
>
> >
> > Marc
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this list please visit:
> >
> >     http://xircles.codehaus.org/manage_email
> >
> >
>
>
> --
> Graeme Rocher
> Grails Project Lead
> http://grails.org
>


--
Graeme Rocher
Grails Project Lead
http://grails.org

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

Re: Tag method calls and namespacing

Marc Palmer Local

On 5 Sep 2007, at 11:22, Graeme Rocher wrote:

> To further elaborate why I don't believe this is necessary. To me this
> smacks of the over engineering to avoid clashes that we get in typical
> Java projects that try to address all future concerns
>
> For me it is a theorotical problem the cost of which is silly. You
> could equally get the problem if a plugin introduced another "tags"
> variable. Its just adding layers for the sake of layers
>

"tags" would be part of grails core from 1.0, so it would be widely  
known. It would be a dynamic property, to like you say in defence of  
the case with a namespace called "request" for example it would  
resolve first anyway.

> A better solution would be to make sure that if an new variable is
> introduced that clashes with a tag namespace that we throw a decent
> error message such as:
>
> "Sorry the name 'foo' is already taken by  a variable and hence cannot
> be used as a tag library namespace in tag lib 'Bar'. Please change the
> namespace that your tag lives in"
>

This does not protect against new properties being introduced by  
Grails in future versions. Every single new property added to any  
class dynamically in future Grails versions could break someone's  
application because we cannot second-guess which properties have or  
have not been used by Grails developers.

For example if we don't already have it, we may add "flow" as a  
dynamic var to all controllers. Any existing applications (nevermind  
plugins) would then require perhaps not insignifcant modifications to  
workaround this. Given the dynamic nature of Groovy, many errors of  
this kind may not be spotted until in the live environment, as we all  
know that in the real world functional test coverage is inevitably  
far less than 100%

> If this is not good enough we could always add the capability to alias
> namespaces in a controller
>
> static tagAlias = [g:"foo"]
>
> and then later you can use the foo. prefix
>

That imo, is an ugly hack around the problem instead of fixing the  
root cause.

:)

Marc


---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

Re: Tag method calls and namespacing

graemer
On 9/5/07, Marc Palmer <[hidden email]> wrote:

>
> On 5 Sep 2007, at 11:22, Graeme Rocher wrote:
>
> > To further elaborate why I don't believe this is necessary. To me this
> > smacks of the over engineering to avoid clashes that we get in typical
> > Java projects that try to address all future concerns
> >
> > For me it is a theorotical problem the cost of which is silly. You
> > could equally get the problem if a plugin introduced another "tags"
> > variable. Its just adding layers for the sake of layers
> >
>
> "tags" would be part of grails core from 1.0, so it would be widely
> known. It would be a dynamic property, to like you say in defence of
> the case with a namespace called "request" for example it would
> resolve first anyway.
>
> > A better solution would be to make sure that if an new variable is
> > introduced that clashes with a tag namespace that we throw a decent
> > error message such as:
> >
> > "Sorry the name 'foo' is already taken by  a variable and hence cannot
> > be used as a tag library namespace in tag lib 'Bar'. Please change the
> > namespace that your tag lives in"
> >
>
> This does not protect against new properties being introduced by
> Grails in future versions. Every single new property added to any
> class dynamically in future Grails versions could break someone's
> application because we cannot second-guess which properties have or
> have not been used by Grails developers.
>
> For example if we don't already have it, we may add "flow" as a
> dynamic var to all controllers. Any existing applications (nevermind
> plugins) would then require perhaps not insignifcant modifications to
> workaround this. Given the dynamic nature of Groovy, many errors of
> this kind may not be spotted until in the live environment, as we all
> know that in the real world functional test coverage is inevitably
> far less than 100%

In this case you would get the exception above. In fact since we
set-up the tag libraries at start-up time we could even throw the
previous error on start-up then it doesn't matter what test coverage
you have

Once the error is thrown you then have the choice to rename your
namespace or rename the variable/property causing the conflict to
resolve it (again this is something that would happen pretty rarely
imo) or use an alias (as per the previous example)

Thus we have an elegant API and the ability to work around the problem
for users of it


>
> > If this is not good enough we could always add the capability to alias
> > namespaces in a controller
> >
> > static tagAlias = [g:"foo"]
> >
> > and then later you can use the foo. prefix
> >
>
> That imo, is an ugly hack around the problem instead of fixing the
> root cause.

The tags. prefix is imo an ugly hack that will be visible all over the
place and in every application. At least the above would only be
visible in these nice corner cases where this may happen

Cheers

>
> :)
>
> Marc
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>


--
Graeme Rocher
Grails Project Lead
http://grails.org

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

Re: Tag method calls and namespacing

Marc Palmer Local

On 5 Sep 2007, at 12:07, Graeme Rocher wrote:

>>>
>> This does not protect against new properties being introduced by
>> Grails in future versions. Every single new property added to any
>> class dynamically in future Grails versions could break someone's
>> application because we cannot second-guess which properties have or
>> have not been used by Grails developers.
>>
>> For example if we don't already have it, we may add "flow" as a
>> dynamic var to all controllers. Any existing applications (nevermind
>> plugins) would then require perhaps not insignifcant modifications to
>> workaround this. Given the dynamic nature of Groovy, many errors of
>> this kind may not be spotted until in the live environment, as we all
>> know that in the real world functional test coverage is inevitably
>> far less than 100%
>
> In this case you would get the exception above. In fact since we
> set-up the tag libraries at start-up time we could even throw the
> previous error on start-up then it doesn't matter what test coverage
> you have
>

Fair enough, but these things should not be taken so lightly. "flow"  
might be used by a popular plugin with 100s of usages in 100s of  
applications. I think it is unreasonable to expect people to update  
their apps. We might try to avoid using names of namespaces used in  
very popular plugins, but I bet we wouldn't want to call our property  
"tide" just because someone has a popular plugin with a "flow"  
namespace.

> Once the error is thrown you then have the choice to rename your
> namespace or rename the variable/property causing the conflict to
> resolve it (again this is something that would happen pretty rarely
> imo) or use an alias (as per the previous example)
>

"you then have the choice..." to be forced to do work to existing  
apps, re-QA and test them, just because someone didn't want to allow  
"tags." prefix :) That's no choice at all.

> Thus we have an elegant API and the ability to work around the problem
> for users of it

Hmm ;-)
>> That imo, is an ugly hack around the problem instead of fixing the
>> root cause.
>
> The tags. prefix is imo an ugly hack that will be visible all over the
> place and in every application. At least the above would only be
> visible in these nice corner cases where this may happen
>

...but when it happens will cause all users time and money.

Marc


---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

Re: Tag method calls and namespacing

graemer
My suggestion is to go with the current mechanism. I believe the
problem is being over stated

If we change it now it introduces a breaking change for users. Yes we
are pre 1.0, but we have many users for a pre 1.0 project

I think that if it really is an issue (which I doubt) we can consider
adding a "tags" prefix later

Cheers

On 9/5/07, Marc Palmer <[hidden email]> wrote:

>
> On 5 Sep 2007, at 12:07, Graeme Rocher wrote:
>
> >>>
> >> This does not protect against new properties being introduced by
> >> Grails in future versions. Every single new property added to any
> >> class dynamically in future Grails versions could break someone's
> >> application because we cannot second-guess which properties have or
> >> have not been used by Grails developers.
> >>
> >> For example if we don't already have it, we may add "flow" as a
> >> dynamic var to all controllers. Any existing applications (nevermind
> >> plugins) would then require perhaps not insignifcant modifications to
> >> workaround this. Given the dynamic nature of Groovy, many errors of
> >> this kind may not be spotted until in the live environment, as we all
> >> know that in the real world functional test coverage is inevitably
> >> far less than 100%
> >
> > In this case you would get the exception above. In fact since we
> > set-up the tag libraries at start-up time we could even throw the
> > previous error on start-up then it doesn't matter what test coverage
> > you have
> >
>
> Fair enough, but these things should not be taken so lightly. "flow"
> might be used by a popular plugin with 100s of usages in 100s of
> applications. I think it is unreasonable to expect people to update
> their apps. We might try to avoid using names of namespaces used in
> very popular plugins, but I bet we wouldn't want to call our property
> "tide" just because someone has a popular plugin with a "flow"
> namespace.
>
> > Once the error is thrown you then have the choice to rename your
> > namespace or rename the variable/property causing the conflict to
> > resolve it (again this is something that would happen pretty rarely
> > imo) or use an alias (as per the previous example)
> >
>
> "you then have the choice..." to be forced to do work to existing
> apps, re-QA and test them, just because someone didn't want to allow
> "tags." prefix :) That's no choice at all.
>
> > Thus we have an elegant API and the ability to work around the problem
> > for users of it
>
> Hmm ;-)
> >> That imo, is an ugly hack around the problem instead of fixing the
> >> root cause.
> >
> > The tags. prefix is imo an ugly hack that will be visible all over the
> > place and in every application. At least the above would only be
> > visible in these nice corner cases where this may happen
> >
>
> ...but when it happens will cause all users time and money.
>
> Marc
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>


--
Graeme Rocher
Grails Project Lead
http://grails.org

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

Re: Tag method calls and namespacing

corey_s
On Wednesday 05 September 2007 04:27:47 am Graeme Rocher wrote:
> My suggestion is to go with the current mechanism. I believe the
> problem is being over stated
>
> If we change it now it introduces a breaking change for users. Yes we
> are pre 1.0, but we have many users for a pre 1.0 project
>
> I think that if it really is an issue (which I doubt) we can consider
> adding a "tags" prefix later
>

As a mere lowly end-user, I'm going to risk making an annoyance of myself
with a few comments:

* I'm still with Marc and Lee; and disagree with Graeme's counter arguments

* It's true that it could be argued that plugins would inevitably have to be
  aware of changes to Grails core over time -- but what about the users of
  said plugins, who may have ample calls all over their app; and who are
  likely even to be maintaining multiple apps as well

* Adding a "tags" prefix later, post-1.0, would cause even worse breakage
  for an even larger number of users who would all be even more put off by
  the change

* Maybe this is a decision worth at least the opinions of existing users
  before settling? I believe you've done such things in the past: a post to
  the grails-user list for a vote?


Aside from that, I'll duck out of the conversation from here on out as I don't
have any more to add from what was already said.


Cheers!


---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email