Note that Playdoh is more specific to Mozilla websites than it should be, specifically around L10n, how it loads libraries, and deployment. It's also not being as actively maintained as it used to be. The big win for us is that it conforms to some requirements we had around deploying Django apps, and makes security reviews on our sites go a lot quicker.
It has some really cool libraries included, like jingo, useful middlewares in commonware, bleach, django-browserid(I maintain this!) and django-waffle.
IMO at the least it's an example of how a production Django application looks (something I appreciated when I was first learning Django) and is worth a look through the code.
Indeed, although I honestly have no experience with other templates similar to Playdoh (although I know they exist).
In my dream world, Playdoh is a Django project template (rather than this installable-as-command stuff that happened before Django had project template support) that makes it easy to enabled/disable certain annoying aspects, like Mozilla-like L10n. It'd get rid of the vendor submodules and load everything in via pip requirements (Erik Rose's peep would be super-helpful here to avoid having to run a PyPI mirror). It'd also get rid of a lot of the old not-commonly-used code, like the pre-commander deploy script, and it'd take away or make optional some of the extra libraries that not everyone uses (django-waffle is amazing but there's no point in loading it if you're not using it).
This is nice. I particularly like the addition of the Vagrant config. These days any app example that requires external resources should include them. It makes things so much easier for someone to go from read, to download, to run.
One thing I'd change though is to add RabbitMQ to the dev Vagrant config. There's no reason dev should not match up with prod:
> While developing locally, Playdoh defaults to:
CELERY_ALWAYS_EAGER = True
> This causes your Celery tasks to happen during the request-response cycle, which is great for development.
In this case in particular there can be huge differences to doing tasks async vs sync. With sync tasks you can assume that task is completed and a subsequent request can rely on the completion of the task. With async it'd be a race condition unless you explicitly handle it.
You'd never catch those kind of bugs in dev or even be able to reproduce them if the tasks are executed synchronously.
Excuse the naive question, I just woke up and this is what went through my mind:
How do I change Playdoh's rendering to AngularJS, it's backend to NodeJS, to be used on top of CoreOS (http://coreos.com/blog/coreos-vagrant-images/) since it also uses Vagrant? A full stack like the MEAN (MongoDB, ExpressJS, AngularJS, NodeJS [http://mean.io/]) with an interachangele database. The point is to be production ready. Can somone do a writeup like: (https://medium.com/code-adventures/438bce155dcb) with proper yeoman integration.
Someone who's altruistic (thanks for the new word HN) can launch a bitcoin crowdfunder (https://bitcoinstarter.com/) or an indiegogo / kickstarter but this definitely needs to happen. Especially NoFlo supporting it. This will help a lot of visual learners and the k-12 demographic.
Edit: Is this considered spam here or what because I got downvoted.
Either you're trolling, or you are...very confused. Giving you the benefit of the doubt........
You're looking at a django project template which is based on Python, Django, Postgres, a traditional response cycle, and asking how to swap out every single component, leaving literally nothing of the original project. The answer to "how do I do it" is "by rewriting the entire thing, from scratch".
Worse, you say "the point is to be production ready", but what you're suggesting is to rewrite an app written on a very stable, very battle tested stack with one written in the latest hipster frameworks. For something like this project, BY DEFINITION what you're asking will make it less production ready. Even if we grant that MongoDB or NodeJS is useful for production in some circumstances (and in the case of MongoDB, that's actually an open question, but I digress), it ain't these.
There's a stereotype that the average HN commenter is obsessed with hipster technology like MongoDB and NodeJS, and wants to use them even when, as here, they aren't appropriate. In addition, the stereotype also holds that the same commenter is probably into bitcoins (which you mentioned), loves scaffolding tools like Yeoman (which you mentioned), and indigogo projects (which you also mentioned). All of this just screams "troll"; the only false note is your mention of NoFlo and the k-12 demographic; unless I've missed an influx of hipsters, tha's the one line in your post which doesn't sound like a parody of the stereotypical HN commenter.
So...yeah. If you're a troll, you're a good one. If you're being serious, you need to step away from the Kool-Aid because you honestly sound like a walking parody. The technologies you mention are not silver bullets, and in no way "production ready" compared to a traditional webapp. What you're asking about is both impossible and a terrible idea.
Thanks for being blunt, and no I wasn't trolling, I was definitely very confused earlier this morning...I just saw MEAN and everything else SEEMED to connect but like you said these are NOT interchangeable and not production ready.
I believe you were downvoted because your comment sounds like you are trolling. You have not said what it is about Playdoh that you would like to see in an AngularJS/NodeJS/CoreOS/etc stack. By the nature of Playdoh being a Django template, you cannot simply swap in NodeJS. You would be starting over from scratch with the goal producing (some of) the features of Playdoh with different technologies.
Not change it completely, but it obviously can be built on top of and implemented with other things like what the docker crew did with flynn.
I might be taken things wrong but I always take downvotes as a sign to keep my mouth shut the next time, especially when they don't explain themselves.
I think you might be misunderstanding just how much of playdoh is generic "basic site setup" vs how much is Django/Python-specific configuration. Playdoh is almost completely composed of configuration for a Django site.
Your suggestion sounds like you think that Playdoh is a generic application template that just happens to use Django, that could be adapted, but that's not the case. At best, you'd be able to see the kind of things Playdoh configures (Security things like X-Frames and CSRF, integrating Persona-based logins, etc) and implement similar things with another environment and framework, but Playdoh is pretty much 99% Python/Django stuff that would need to be replaced.
If you follow the installation instructions as given you get:
if settings.SECRET_KEY == '':
AttributeError: 'module' object has no attribute 'SECRET_KEY'
when you get to the first syncdb
The cause seems to be that funfactory is installed globally initially (to bootstrap things) so when you switch into the virtualenv to run syncdb you need to install it again so it's also in the virtualenv.
Also - the docs don't tell you to activate the virtualenv which might confused some people but I am guessing that's pretty essential.
And even when I fix the above problem I get a new error:
ImportError: No module named django.utils.functional
Looking in the virtualenv it seems that django doesn't get installed automatically.
Is anyone else seeing these problems following the official docs or am I being a doofus?
You might have avoided the downvotes by posting a source. While the parent's comment is correct (re: domains of trademarks) it's true that Monster has been a bit of a bully[1] and not unsuccessfully either.[2]
It would be a great blessing for Django beginners like me if some noble soul(s) could turn this into the go-to project template for Django based webapps (by making Mozilla specific stuff more generic).
Note that Playdoh is more specific to Mozilla websites than it should be, specifically around L10n, how it loads libraries, and deployment. It's also not being as actively maintained as it used to be. The big win for us is that it conforms to some requirements we had around deploying Django apps, and makes security reviews on our sites go a lot quicker.
It has some really cool libraries included, like jingo, useful middlewares in commonware, bleach, django-browserid(I maintain this!) and django-waffle.
IMO at the least it's an example of how a production Django application looks (something I appreciated when I was first learning Django) and is worth a look through the code.