Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

why double registration if "name" is given? #9

Open
petri opened this issue May 23, 2016 · 5 comments
Open

why double registration if "name" is given? #9

petri opened this issue May 23, 2016 · 5 comments

Comments

@petri
Copy link
Member

petri commented May 23, 2016

If the "name" attribute is given in behavior ZCML registration, the behavior is registered twice. From user perspective, the registrations appear the same. This is very confusing.

Yet this behavior of p.b. is actually mentioned in the p.b. docs which leads me to assume this is intended behavior rather than a bug.

Is this indeed intended feature, and if, for what purpose?

@jensens
Copy link
Member

jensens commented Mar 15, 2017

A name_only="yes" registers only the name and not the dotted name. It's default is no.
Since name was added later, lots of code expects a dotted path.

We could deprecate usage of the dotted path in 1.x-series and in a 2.0 release change the default of name_only to yes.
Would that help?

@gforcada
Copy link
Member

I would add right now a deprecation notice, if we want users to use one approach rather than the other let's be clear and open about it.

It has the extra benefit of "forcing" you to fix the code and take a look at it, as well as a nice feeling of following best practices 😃

@gforcada
Copy link
Member

Oh, and this could mean that the name_only attribute could be removed all together in a new major release.

Keep code clean and simple! 😃

@jensens
Copy link
Member

jensens commented Mar 20, 2017

And we need to change all our documentation too.

@gforcada
Copy link
Member

So point is: we allow to register by name and by dotted path, it seems that there is no real benefit of having both registrations, it was just out of organic evolution, so we should decided on one method and clearly mark the other as deprecated so all code can be ported to it.

Who's going to make the decision? :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants