[p2pu-dev] Tech call notes: 2013-01-17

[Paul Osman]

Just chiming in with a quick FYI re: templates.

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:

http://jinja.pocoo.org/docs/

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.

-P


On Wed, Jan 23, 2013 at 11:24 PM, Chris Ewald <chris at p2pu.org> wrote:

> @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.
>
> 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!
>
> @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.
>
> 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.
>
> 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?
>
> Also, I did some quick googling of flask. Check this out:
> http://www.mikkolehtinen.com/blog/2012/05/25/rewindy-tech-stack/
> Apparently our line of reasoning is not original. Let me know what you
> think.
>
>
>
> On Wed, Jan 23, 2013 at 8:36 AM, Dirk Uys <dirk at p2pu.org> wrote:
>
>> Hi Jose
>>
>> On Tue, Jan 22, 2013 at 7:28 PM, Jos Flores <josmasflores at gmail.com>wrote:
>>
>>>
>>> If all your business logic is encapsulated in classes, your domain
>>> objects will be usable by both Django and flask, and being plain
>>> objects, can be very testable. But anyway, this is pretty much the
>>> same you are saying! :)
>>>
>>
>> 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.
>>
>> Cheers
>> d
>>
>> _______________________________________________
>> p2pu-dev mailing list
>> p2pu-dev at lists.p2pu.org
>> http://lists.p2pu.org/mailman/listinfo/p2pu-dev
>>
>>
>
> _______________________________________________
> p2pu-dev mailing list
> p2pu-dev at lists.p2pu.org
> http://lists.p2pu.org/mailman/listinfo/p2pu-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.p2pu.org/pipermail/p2pu-dev/attachments/20130124/b5e12fdc/attachment.html>