Survey about naming conventions - please participate!
jrief opened this issue · 25 comments
I noticed, that the current naming conventions are not very consistent.
Django-Angular's Javascript code, Directives start with djng-..., which is in my opinion is a good choice.
Django-Angular modules start with ng.django.... , which is distracting. In my opinion, a better prefix would be to also use djng....
Django-Angular Providers start with django, for instance djangoForm, djangoRMI and djangoWebsocket. This in my opinion is somehow acceptable, since they already are part of a Django-Angular namespace.
In Django-Angular's Python code, Mixins are Prefixed with Ng.... For consistency, shouldn't they rather be renamed to say DjNg... or djng?
Please participate and point my on conventions used in similar third party modules.
As for modules, I agree ng.django. is kinda strange, don't think top level name should have a dot in it.
Also I agree DjNg would be a better prefix for python code, to increase overall consistency.
Which leaves providers, is there a reason these don't start with djng ?
While django prefix definitely makes sense I would argue djng would be better, because it distinguishes the code from other possible django-angular-ish packages or custom code one might be using.
Modules
Many modules for AngularJS use a camel-case prefix, or just lower case, but there is apparently no common standard. Multiple prefixes are unusual. I agree here that it would certainly make sense prefixing modules with djng. instead of ng.django.. This provides a consistent syntax with directives.
Providers
I can see both mentioned points here; providers are already in a namespace, and using django as a prefix appears to be intuitive. Changing to djng is not so necessary for consistency, but on the other hand may avoid confusion with other Django-based implementations. I would tend to rename this as well.
Python classes
Ng in my opinion was originally a good choice to express the AngularJS relation, but now that significantly more JS code has been added, following the naming pattern here might seem more consistent to new users. I would however prefer a simple prefix Djng over DjNg.
I tend to agree with what others have written that using djng or a minor variant across the board (such as DjNg or Djng would be better for reasoning about what you're working on. One thing I did notice (while we're on the topic of naming conventions) the project is installed under the name django-angular but in installed apps it has the name of another project djangular. I usually deal with more of the front-end work so I'm not really sure what kind of trouble changing that would cause, but thought this would be a good time to mention it.
I've got a slight preference for djng - but probably not enough angular experience to know if it's right thing to do.
I agree with @jrief. Consistency is important, and mixins should not be preffixed Ng because that's the preffix for default directives in angular world. DjNg or Djng looks better
I agree with @merll on all points, including the use of djng for Providers (to avoid confusion) and Djng because it is easier to write than DjNg.
I would also prefer changing the Python module to match the package name: django_angular.
I agree on all of these, they all sound very sensible.
S++
On Thursday, June 19, 2014 4:20 PM, Espen Angell Kristiansen notifications@github.com wrote:
I agree with @merll on all points, including the use of djng for Providers (to avoid confusion) and Djng because it is easier to write than DjNg.
I would also prefer changing the Python module to match the package name: django_angular.
—
Reply to this email directly or view it on GitHub.
OK, great!
Renaming will be done for the next bigger release, which will be 0.8.0.
I just released 0.7.3.
Hi!
Will you retain backwards compatibility with v0.7.x in v0.8.0?
Changing from version 0.7.x to 0.8 should just refactor the names. In Python it might be, that I keep the old name pointing onto the new one and adding a deprecation warning. JavaScript unfortunately doesn't offer such a feature.
FWIW djng and django_angular (what espenak said) sound good.
Anything but djangular...
vote up for django_angular
I don't like to repeat the lemma "django" as part of a library name, because its too redundant.
My preference for now is djng because that makes sense in Django includes, as well as in Angular injections.
@AncientSwordRage I agree, using djangular was a bad decision. Sorry for that.
Other proposal:
What do you think about moving members from Form mixins, such as scope_prefix into the Form's Meta class?
IME the bad thing is when the importable name is much too generic, i.e. a django-comments PyPI package that installs a Python package named comments. Avoiding these import-name conflicts is important. For the PyPI names, we have PyPI to avoid conflicts. I don’t think naming a package that adds tags to Django projects “django-tags” is redundant: to the contrary, it says clearly what it does. It’s also easy to match pip install django-tags to a django_tags directory in site-packages.
FTR naming extensions “pyramid_thing” is also a standard habit in the Pyramid community (which comes from the Zope community, where best practices for packaging have a long tradition).
Please vote here:
@AncientSwordRage thanks for setting up the ballot.
Vote is closed. Name has been chosen and must change when releasing version 0.8 right @jrief ? Closing this
Yes, it will be changed for 0.8. Then in JS and Python we will use djng?
yep ! 👍
As a newer for Angular, I want to know why the "app.js" does not show in the Demo? What should I do for Angular file struct with django architecture? Thanks for your patience in advance
Please open a new issue for that. It is not related to the original post...
And your problem is not quite clear for me.
Have a look at base.html in the templates folder :
<script type="text/javascript">
{% block ng_module_definition %}
var my_app = angular.module('djangular-demo', {% block ng_module_dependencies %}[]
{% endblock ng_module_dependencies %});
{% endblock %}
</script>
We define here the module 'djangular-demo'. It's the base of our angular app as you could find in any app.js file in some demo angularjs apps. Then for each different example, we add more specific code :
{% block demo_scripts %}
<script src="{{ STATIC_URL }}js/djng-tutorial.js" type="text/javascript"></script>
{% endblock %}
Maybe try stackoverflow first if the question is more related to angularjs than directly this library. Thanks.
In 0.8.0 djangular has been renamed to djng.