Q? Packaging app best practices (lots of questions)

[Charles Thayer]

I'm new to packaging apps for external users, so I've been trying to

generalize something from a site of mine.  I have a bunch of questions

about best practices that I thought you might have good input on.

It's an app to support "like" and "bookmark" of any object in your

system (I realize there are many flavors of this in the wild).  The

code is https://github.com/cgthayer/test/tree/master/django-userlinks

* Examples: is there a canonical example app that covers enough ground

  to be _the_ "best practices" example?

* Examples templates: I include a eg_urls.py and

  templates/eg/index.html so that people could bring it up and try it

  out under a standalone test project. Is there a common way to do

  this?

* Ajax: Turns out that I only ever implemented ajax methods in this

  app, and they're all in views.py. I see other projects sometimes use

  ajax.py or api.py, would that be better? 

* Code style: All my ajax functions have an "_ajax" suffix, is there a code 

  style standard for django? This isn't discussed in http://bit.ly/2n4TDj3

* Implementation: For the app, I wanted to be able to like / bookmark

  any object in the system. Some folks use an abstract model mixin

  which creates a new table for every model that needs "like" support.

  I just create a single UserLink Model with a generic foreign field

  (and ContentType) instead.  Is there a best practice around this?

* Dependencies: I have a small amount of JS which depends on JQuery,

  animateCss, and Font Awesome. Is there a standard way to express

  these dependencies or should this be somehow simplified / ripped

  out.

* JS.html: I have some templates which generate javascript which

  include some {% url %} lookups. Is this acceptable, or is generated

  js from templates a bad idea.

* Using apps: I found the workflow quite painful because I'm putting

  the app in github but my project is actually in a different repo

  (public vs private). To manage this I have 3 directories --is there

  a better way?

  * work/test/django-userlinks: the bits in github

  * work/private_project/private_project: part of a private repo,

    has a symlink "userlinks" to "../../test/django-userlinks"

  * work/stubproj: how I test my app to be sure it works standalone,

    has a symlink "userlinks" to "../test/django-userlinks"

Thanks for any input,

/charles

[Melvyn Sopacua]

On Thursday 09 March 2017 14:07:45 Charles Thayer wrote:

 

> * Examples: is there a canonical example app that covers enough ground

> to be _the_ "best practices" example?

 

An "app" is a very loosely defined term. There has been work to come to a "reusable app standard". But since there's no certification, stickers, prestige, increased revenue or princess in a tower incentive - in practice a good ammount of developers don't know about it let alone adhere to it.

So, there's not really a solid standard to reference your "best practices" against.

 

> * Examples templates: I include a eg_urls.py and

> templates/eg/index.html so that people could bring it up and try it

> out under a standalone test project. Is there a common way to do

> this?

 

If I have to download an example project for an app, the documentation is lacking. If I want to see if it does it's job, I prefer a working demo (and my goal is then to see if I can break it).

 

> * Ajax: Turns out that I only ever implemented ajax methods in this

> app, and they're all in views.py. I see other projects sometimes use

> ajax.py or api.py, would that be better?

 

Ajax.py is common, but in itself has no benefit. Api.py is a bad choice. It's used by some apps for providing the API for the app.

 

> * Implementation: For the app, I wanted to be able to like / bookmark

> any object in the system. Some folks use an abstract model mixin

> which creates a new table for every model that needs "like" support.

> I just create a single UserLink Model with a generic foreign field

> (and ContentType) instead. Is there a best practice around this?

 

Yes, the contenttype approach. Apps who alter the database schema at runtime should be shot.

 

> * Dependencies: I have a small amount of JS which depends on JQuery,

> animateCss, and Font Awesome. Is there a standard way to express

> these dependencies or should this be somehow simplified / ripped

> out.

 

Whatever you do, do not auto-inject JQuery. Use two settings instead:

- include_jquery: boolean

- jquery_url: string

 

Example: Django Bootstrap3. I also like the dictionary approach to settings (another example of that: Django CKEditor ).

 

You could use Django FontAwesome as a requirement and let it handle the icons. Projects already using it, will appreciate it.

 

> * JS.html: I have some templates which generate javascript which

> include some {% url %} lookups. Is this acceptable, or is generated

> js from templates a bad idea.

 

It's fine. It's how you handle breakage that matters. One of the most annoying things about reusable apps is that quite a few don't namespace their lookups. So in a project I cannot re-namespace them to resolve conflicts.

 

> * Using apps: I found the workflow quite painful because I'm putting

> the app in github but my project is actually in a different repo

> (public vs private). To manage this I have 3 directories --is there

> a better way?

 

Yes, git submodules.

 

--

Melvyn Sopacua