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

Fri Jan 25 01:14:23 UTC 2013

Thanks for tip Paul. Jinja2 does look a bunch nicer than the defaults.

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. :-)

Cheers

On Thu, Jan 24, 2013 at 5:17 PM, Paul Osman <paul at eval.ca> wrote:

> 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
>>
>>
>
> _______________________________________________
> 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/90a25f07/attachment-0001.html>