Scaffold-Integration-Apps for client-side frameworks

148 views
Skip to first unread message

Arnon Marcus

unread,
Nov 23, 2013, 4:59:50 PM11/23/13
to web...@googlegroups.com
Django, Rails and ASP.Net, all have community-generated 'template' (scaffolding) apps and demo-apps for many of the popular client-side frameworks that had emerged in the last 2-3 years.
The Breeze middle-ware, also has many different front-ends and back-ends integration examples.

Does web2py have a repository that exemplifies specific frameworks-integration?

I know about the plugins repository, and the built-by-web2py website, but It's not exactly what I'm looking for - it's not a substitute, but a complementary kind of repository.
It's one thing to have examples that express different internal capabilities of your framework, and have components that people can use as a starting-point for implementing their own solution using the same mechanism. It's another thing entirely to have different starting-point-apps, each targeting a different client-side framework.

The 'Welcome' app has notoriously been a target for endless debates of weather or not to add this-or-that library-support, but I think we've been going about it in the wrong way - it's not about a 'single-welcome-app-to-rule-hem-all' - it's about variety - it's about options.

If you are, say, an Angular.js developer, looking for a back-end solution, you're going to look for server-side solutions that already have "examples" that integrate-well with your client-side frameworks. It is so prevelant these days, that it has become something to be expected. You are not going to go through the due-diligence of coming-up with an integration yourself, especially when you don't know the server-side framework well enough to do so to begin with....
You are thus going to choose Django, or RoR, or ASP.Net-MVC - just because there are already existing scaffold-apps implementing the integration for that server-side framework (the plumbings). You are NOT going to choose web2py, and NOT because it is a poorer choice (it isn't), and NOT even because it is difficult to implement such an integration (you are not going to know that it isn't...).

Conversely, If you are a web2py all-around-web-developer, waning to write, say, an Ember.js app, you are going to look for a scaffold that already shows how to do that.
And you are not going to find any... At least I haven't...

This is really unfortunate...

I think it is really detrimental to web2py's popularity.

I am in an on-going process of researching SPA frameworks in order to make a decision on weather or not it is worth the effort of converting our existing web2py into using one of those, as our client-side code is in sour need of 'structure' for maintainability and testability.

I have already learned quite a lot about Backbone, Angular, Ember and Durandal (which uses Knockout among others). But I keep coming back to this question of - which one would be most suited for web2py as a back-end? Which could be best integrated with it?

And I can't seem to get an answer to that, as there are no examples to go through to figure it out.

And so, instead of just ranting, I decided to do something about it.
But I will not be able to do that alone - I'm going to need help.

My plan is to start a few projects, that show how these client-side frameworks can interact with web2py, and in the process, generate some 'client-side-framework'-specific code in python using web2py 

I call it " js2py ", which is an umbrella-term describing different 'javascript-framework-target'-projects' for web2py - for example:

"Ember2py" - Would be the name of a project entailing integration-code for Ember.js.
"Angular2py" - Would be the same for Angular.js.
"Durandal2py" - Would be the same for Durandal.js
Etc...

I am going to start with Durandal, but before that, there would have be 2 smaller projects: "Require2py" and "Knockout2py" - As requier.js and knockout.js are pre-requisites of Durandal.js.
 
In a similar manner, for Ember.js, there is going to have to be a pre-project of "Handlebars2py" and/or "Emblem2py" for integrating web2pt's views with Ember's template-technologies.

For Angular2py and Knockout2py, there will be targeted sub-classes for the HTML-Helpers, for adding attributes more conveniently - either in the controller-actions and/or the Python code in the views.

I already toyed with the idea a while back, and got Massimo's blessing... :)

So, It's going to be an interesting, challenging and exciting ride...

Who's with me?

Arnon Marcus

unread,
Nov 23, 2013, 5:32:02 PM11/23/13
to web...@googlegroups.com
The first thing I am going to tackle, is Require.js

I love the idea of compartmentalizing different views/viewModels into separate files, organised in role-oriented directorates.
We 2py already does that, as part of the MVC-RoR-like :convention-over-configuration' approach. Durandal (and Ember) aim for the same thing, generally, each implementing a "modules" mechanism for loading partial-templates and javascript-files.

The first question I have to ask, is wethere or not to re-use the existing we2py folder-structure for that, or have it all in sub-folders in the static folder.

I think it would be awesome if the existing folder-structure could be reused.
The views folder, already contains what would become the templates of the client-side SPA framework(s). There is only the issue of how to have the syntax not collide with web2py's template language(s).

I think there is still room for both to exist, though as serving different roles - i.e:
Web2py templating would/could be used for SEO-related stuff, and/or in combination of client-side templating, each fulfilling different roles.
For example, static data, can be done using web2py's templating (i.e: Titles of pages, injection of reusable components such as "Forms", etc.), while client-side templating would be reserved for dynamic content, bound to javascript-observable-objects.
But there could be dual-roles for the same data - like in the case of Forms:
There could still be usage of web2py-generated forms, but using a different sub-class of the regular one - that generates the same structure of Form tags, only each tag with additional properties for data-binding to a specific framework. The generated Form-object, would then be injected into the template in the usual web2py-templating-kind-of-way.

Javascript 'controllers', could just be located in the existing controllers folder.
Same for models. 
As for javascript 'modelViews', they can either be located in the 'views' folder (alongside their templates), or a new "viewModels" folder.
As for 'routs', there should probably be a special new folder for them.

This would be very convenient for development, and can be easily configured using requier.js, or any other framework's modules mechanism.

The only question is weather there is going to have to be changes to web2py to enable it to serve these javascript files from these locations...
I hope these wouldn't be a problem there...

If all fails, the static folder can always be falled-back to. 

rppowell

unread,
Nov 24, 2013, 12:42:34 AM11/24/13
to web...@googlegroups.com
I've done a bit of playing with Ember.js and web2py a while back and posted up notes here:

This was a starting attempt to play and learn Ember.js.  Please note that I am not proficient in Ember/javascript frameworks.

The big thing that impacted what I was doing (besides asset/js/css organization) was dealing with the handlebars mark-up in web2py.
My work-around is as follows:

Edit the applications/ember2py/models/db.py and add the following HTML helper HB() ('HB' for Handlebars. See also https://groups.google.com/d/topic/web2py/-CrviALMVy8/discussion ):

# added to applicatons/embertest/models/db.py
 
class HB(DIV):
    tag = ''
    def xml(self):
        return '{{%s}}' % super(HB, self).xml()


Now, in the controller, whenever using the Handlebars markup, change from:

<script type="text/x-handlebars">
    <h2>Welcome to Ember.js</h2>
    {{outlet}
</script>


To:

<script type="text/x-handlebars">

    <h2>Welcome to Ember.js</h2>
    {{=HB('outlet')}}
</script>


I have recently started playing with AngularJS, and I am tempted to post something similar.
Would people be interested/should I continue & share?

-Rob Powell

Arnon Marcus

unread,
Nov 24, 2013, 4:05:47 AM11/24/13
to web...@googlegroups.com
Hi Rob,

I had seen your solution when I ran a search for ember in this group. It's ok that you are new to ember - so am I - we are all learning here as we go.
The reason that there are no 'ember folks' in the web2py community, is that there isn't a solution for it in web2py. And the reason for that is that there are no web2py users who are also ember developers.
It's a chicken-and-egg problem, and is very common in volontary communities.
Someone has to bite the bullete and feel the pain necessary in making that first step for others to follow, and nobody wants to be that someone...

I think I'll open new discussion-groups for us crazy folks who want to take the plunge, and we'll talk more there. I'd love to have you on-board! :)

Arnon Marcus

unread,
Nov 24, 2013, 4:35:40 AM11/24/13
to web...@googlegroups.com
BTW, there are muliple ways of overcomming the syntax collision with handlebars. You could:
1. Change web2py's delimiter syntax to somethimg other than double-curly-braces.
2. Change handlebars's delimiter syntax.
3. Have separate files for the handlebars templates.
4. Have custom web2py html-helpers (similar to what you did)
5. In case of ember, use emblem: http://emblemjs.com

Arnon Marcus

unread,
Nov 24, 2013, 1:08:41 PM11/24/13
to web...@googlegroups.com

Arnon Marcus

unread,
Nov 24, 2013, 1:19:53 PM11/24/13
to web...@googlegroups.com
I have launched my initiative with a few new google-groups - check it out:
https://groups.google.com/forum/#!forum/js2py-dev
Reply all
Reply to author
Forward
0 new messages