<div dir="ltr">Thanks for tip Paul. Jinja2 does look a bunch nicer than the defaults.<div><br></div><div style>Would love to get your input on basic architecture for the new MOOC Maker app we're building sometime soon. We're going to be in the thick of the design probably in early february so chatting architecture sometime around then would be most appreciated. :-) </div>
<div style><br></div><div style>Cheers</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jan 24, 2013 at 5:17 PM, Paul Osman <span dir="ltr"><<a href="mailto:paul@eval.ca" target="_blank">paul@eval.ca</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Just chiming in with a quick FYI re: templates.<div><br></div><div>It's possible to use Jinja2 with Django instead of the default Django template engine (which I agree, is horrible). Have a look and see if any of you prefer it:</div>

<div><br></div><div><a href="http://jinja.pocoo.org/docs/" target="_blank">http://jinja.pocoo.org/docs/</a><br></div><div><br></div><div>There are certain trade-offs with going with anything other than the default Django templates, especially around using 3rd party apps that package templates, but worth a look.</div>
<span class="HOEnZb"><font color="#888888">
<div><br></div><div>-P</div></font></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jan 23, 2013 at 11:24 PM, Chris Ewald <span dir="ltr"><<a href="mailto:chris@p2pu.org" target="_blank">chris@p2pu.org</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">@Dirk - so there's a few reasons why I don't like the django templating layer. First off, I am spoiled with erb which lets you use the full ruby language in the templates. I think that using a full language rather than tags or whatever is usually preferable - it's more powerful and is one less del to learn. The downside is that they usually a little more verbose. On the JS side, I know that ejs and eco work similarly, giving you full JS in your templates, so my preference is for that as opposed to mustache or handlebars. The filters is what really bug me with the django templates. I don't really like the syntax for them and it feels to me like a hodgepodge of theoretically useful functions in a global context... it's approaching PHP style which is really bad IMHO. I don't know all of the filters, so I'm never really sure if I should do string manipulations in the controller function or with a filter. It's also not straightforward how you define and use your own filters - to me at least, maybe this is not true. All of this is a non-issue if you are using a full programming language in your templates where you can create and use non-global (even OO - yay!) functions the same way as the rest of the language.<div>


<br></div><div>I'm not attached to ejs in any way really, but I do think it makes sense to do the view layer of this app in JS. As we mentioned - the big advantage of using a JS view layer is that they all speak JSON, so we wouldn't need to change anything from our REST API. Freebie!</div>


<div><br></div><div>@José - I shared with you the original grant proposal for the MOOC Maker. Check it out, but read it skeptically. It's the super long term version - right now we want to make each MOOC it's own instance so we can learn from the experience of running different MOOCs. Really right now, all we want is to recreate what we currently have in ruby in python and add an email scheduler. The app described in the proposal is pretty big and would definitely be a django app.</div>


<div><br></div><div>As for JS MVC frameworks - I have experience with backbone and JSMVC. Definitely prefer backbone. JSMVC is huge, complex, and obtrusive with way too many moving parts to understand it all. Definitely do not recommend it. Backbone is the polar opposite - the bare minimum you need to get a MVC up and running. And it's dependency underscore.js is really nice too - basically a very well thought out core lib extension. I was up and running with backbone in 1 day. The code is really easy - but the hardest part is the way of thinking with it - where a 'view' is always associated with a DOM element and a Collection is basically an array stack of those views, with a bunch of callbacks for adding / removing them. Backbone also has a biggest user base / community of the JS MVCs by a large margin so that's a really good sign IMHO.</div>


<div><br></div><div>I haven't played around with AngularJS at all. How do you like it? I think it's also pretty lightweight? Also, do you have an opinion of JS templating projects that you like / dislike?</div>
<div><br></div><div>Also, I did some quick googling of flask. Check this out: <a href="http://www.mikkolehtinen.com/blog/2012/05/25/rewindy-tech-stack/" target="_blank">http://www.mikkolehtinen.com/blog/2012/05/25/rewindy-tech-stack/</a></div>


<div>Apparently our line of reasoning is not original. Let me know what you think.</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote"><div><div>On Wed, Jan 23, 2013 at 8:36 AM, Dirk Uys <span dir="ltr"><<a href="mailto:dirk@p2pu.org" target="_blank">dirk@p2pu.org</a>></span> wrote:<br>


</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>Hi Jose <br><br><div class="gmail_quote"><div>On Tue, Jan 22, 2013 at 7:28 PM, Jos Flores <span dir="ltr"><<a href="mailto:josmasflores@gmail.com" target="_blank">josmasflores@gmail.com</a>></span> wrote:<br>


<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
If all your business logic is encapsulated in classes, your domain<br>
objects will be usable by both Django and flask, and being plain<br>
objects, can be very testable. But anyway, this is pretty much the<br>
same you are saying! :)<br></blockquote></div><div><br>I tend to agree with you on this. I prefer writing domain logic behind a stateless API that answers questions. Anything behind your API is free to use any data store. Resources should be referenced by URI and you have the possibility of weak references. Exposing an APIs over HTTP follows easily.<br>



<br>Cheers<span><font color="#888888"><br>d<br></font></span></div></div>
<br></div></div><div>_______________________________________________<br>
p2pu-dev mailing list<br>
<a href="mailto:p2pu-dev@lists.p2pu.org" target="_blank">p2pu-dev@lists.p2pu.org</a><br>
<a href="http://lists.p2pu.org/mailman/listinfo/p2pu-dev" target="_blank">http://lists.p2pu.org/mailman/listinfo/p2pu-dev</a><br>
<br></div></blockquote></div><br></div>
<br>_______________________________________________<br>
p2pu-dev mailing list<br>
<a href="mailto:p2pu-dev@lists.p2pu.org" target="_blank">p2pu-dev@lists.p2pu.org</a><br>
<a href="http://lists.p2pu.org/mailman/listinfo/p2pu-dev" target="_blank">http://lists.p2pu.org/mailman/listinfo/p2pu-dev</a><br>
<br></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
p2pu-dev mailing list<br>
<a href="mailto:p2pu-dev@lists.p2pu.org">p2pu-dev@lists.p2pu.org</a><br>
<a href="http://lists.p2pu.org/mailman/listinfo/p2pu-dev" target="_blank">http://lists.p2pu.org/mailman/listinfo/p2pu-dev</a><br>
<br></blockquote></div><br></div>