EmberJS is the web2py of the client! :)

[Arnon Marcus]

EmberJS is one of the most comprehensive MVC frameworks of the day - it's "batteries included" (like web2py).

It is inspired by Ruby-on-Rails, in terms of preferring "convention-over-configuration" (like web2py).

It has "sane defaults" for the high-level architecture, so it could require minimal code for standard stuff (like web2py).

The MVC naming-structure is somewhat different, but essentially the same components exist as in web2py.

 

The Router:

 

Like in web2py, there is a convention for mapping controllers to views, but unlike web2py, routing (the mapping of URLs to code) is done explicitly.

It is analogous to web2py's "routs.py" file.

The router is doing client-side routing, translating code to URL and vice-versa.

 

The Model:

 

Firstly, there is an extension called EmberData that works holistically with EmberJS (but can be used without it) that does all the front-end/back-end synchronization.

It is analogues to web2py's database-abstraction-layer (DAL) architecture, for supporting multiple optional back-ends, and converting data to an ORM (object-relation-model).

As in RoR (ruby-on-rails), the conversion is done via "Adapters" which are like web2py's DAL-drivers.

In RoR it outputs what's known as "Active-Records" - essentially, objects that map to the back-end, and "know" how to save/update data back.

In EmberData you would write:

                model  = DS.Store.create()

Where in web2py you would write:

                db = DAL(<connection-string>)

The data received from the backend, after being converted to ORM objects, is known as "Records".

What is called "Record" in EmberData is essentially like a "Row" object in web2py, and similarly a "RecordArray" in EmberData is analogous to a "Rows" object in web2py.

 

 The View:

 

In EmberJS, a "view" is somewhat different from what a "view" in web2py, as it deals with user-interaction event-handeling.

However, EmberJS uses "Templates" which are essentially what web2py's "views" are. It even uses very similar templating  language with a squirrely-brackets ("{{<somthing>}}").

It has similar uses, so where in web2py, a controller "passes" data to the view, in EmberJS a controller "binds" data to a template.

The difference here is that because it is all client-side, EmberJS can do data-binding - whenever a controller's bound-data changes, the template automatically updates itself in the UI.

Additionally, in EmberJS there are special names that do special things inside a template.

For example:

Where in web2py, the "layout" may have something like:

                ...

                <header>...</header>

                ...           

                {{include}}

                ...

                <footer>...</footer>

                ...

In ember it would be:

                ...

                <header>...</header>

                ...           

                {{outlet}}

                ...

                <footer>...</footer>

                ...

Essentially meaning "everything else inside this template, put here"...

 

Similarly, where in web2py you would write:

                ...

                {{if someBoolean}}

                <div>{{someBoolean}}</div>

                {{pass}}

                ...

                <ol>

                                {{for a in someArray}}

                                <li>{{a}}</li>

                                {{pass}}

                </ol>

                ...

In EmberJS it would look something like this:

                ...

                {{#if someBoolean}}

                <div>{{someBoolean}}</div>

                {{/if}}

                ...

                <ol>

                                {{#each a in someArray}}

                                <li>{{a}}</li>

                                {{/each}}

                </ol>

                ...

Also, where in web2py the mapping of views to controllers is done via folder-structure + file-naming,

in EmberJS it is done via name-mapping of controller-object-name and template-object-name.

 

 The Controller:

 

In web2py a controller automatically maps to a sub-set of the URL, and may have many functions called "Actions", which each is mapped to a view.

In EmberJS this is further generalized in the "Router", which can contain many nested "Routs", each mapped to a single "controller" via the router and/or naming-convention.

So an EmberJS "Rout" is analogous to a web2py "Controller", and an EmberJS "Controller" is analogous to a web2py "Controller-Action".

This is offers a more flexible hierarchy for the application, as a router can "nest" routs as deeply as you want.

 

 

Here are some great (and funny) videos about Ember (watching in order is advisable):

 

EmberData

 

EmberJS (you can skip the live-demo part in the middle, it's not very clear here..)

 

Live Demo (This one is very clear.)

[Massimo Di Pierro]

Thanks for the good writing. We should make an example of integrating the two.

[António Ramos]

Backbone anyone?

2013/4/2 Massimo Di Pierro <massimo....@gmail.com>

--
 
---
You received this message because you are subscribed to the Google Groups "web2py-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to web2py+un...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[David Marko]

AngularJS is well designed ... and usefull ...

Dne úterý, 2. dubna 2013 19:13:20 UTC+2 Ramos napsal(a):

[Arnon Marcus]

Backbone is not comparable to any full-stack MVC - it's a mere, well. "backbone" of an MVC framework... It's hideously verbose in boilerplate, and by itself doesn't do much... "You" are doing most of the work with backbone (which would be, again, mostly boilerplate...). For any sane deployment, you have to gather a bunch of plugins (from variant degrees of maturity/documentation/communities, and that don't necessarily play together).

Marionette/Chaplin/Gepeto might be better, but I haven't researched them very much... Knockback also seems interesting, but kind of an weird abomination....

Angular is "SUPER"... It is genius... And has everything one might need, but it's somewhat of a mystery... Learning it is like solving an enigma...

Directives? HTML-Compiler? Dirty-checking? On the client? Are you serious? Wouldn't that be Sloooooowww in a big project?

And DOM templating? Is that wise? Given that the DOM is the most broken API in the web stack?

It might be a glimpse of the future, but I'd rather wait for the real thing (Shadow-DOM, Composable-Elements, HTML6...)

I think that for most web2py users, Ember would feel more "natural" that basically any other framework out there...

[Derek]

Eh, I don't see much of a need for a client side framework. Just client side templates. jQote2 works great for that. Submitting data via ajax is as simple as calling ajax('url',[data to be saved], ':eval'). Templates are the slowest part of a webserver (usually), and since pages can take a long time to load from template compilation, it makes sense to offload that to the client. As far as database access is concerned, you're going to be waiting on the server no matter what database you have, so no need to abstract that out, just make it async, which is what ajax is good at. Every client side MVC framework seem to be overkill anyway. 

[Arnon Marcus]

"Eh, I don't see much of a need for a client side framework"

That may be, but others do. It depends on the needs of a project. You may find you can benefit from such thing at some point, when an appropriately fitting project presents itself to you.

It is an matter of managing complexity. For projects that don't require a grate degree of complexity, well, you might be right - those projects don't need a client-side framework.

It is also a matter of culture and expectations - Do you want a full single-page-application? If so, then 9 out of 10 times you are dealing with a state-full-scenario. The client-side code needs more then just the ability to render templates and talk to the server asynchronously - it also needs structure - and more often than not, that means some kind of a state-machine, at least conceptually. If there are multiple pages, and sub-pages, you also need some kind of routing-mechanism on the client (again, when aiming for a SAP). So, you need to manage the hierarchy and flow of the screens that exist in your application, and have that linked to a changing URL and a working client-side-history (the back/forward buttons on the browser). Then there is the whole story of how do you  manage the data in the client, being synchronized with the server, so you need some kind of an ORM on the client, at the very least. Then there's the whole issue of "having a single source of truth" for the UI and the client-side data, and this means "getting the truth out of the DOM" - this requires a javascript-object-model holding the data (which would be the ORM), and so you need to deal with synchronizing that object-model with the UI, so now you need to write tons of event-handlers, and manually move data back and forth from the UI to your data-model, and refreshing the UI - this is where data-binding libraries come in - you declaratively define the relationships between a UI-segment and a data-model (usually within a template), and the library takes care of the rest for you. Then there's the whole issue of reusing components - being "DRY" (don't-repeat-yourself) - this requires some kind of an object/class-inheritance story - preferably with all relevant capabilities encapsulated. All this is "structure", and lots of code, so some kind of convention for where do you place your files, or how to separate concerns between them - some kind of way to reason about all these architectural-components. You can use disparate libraries on a need-basis, but you often don't anticipate correctly what capabilities would be required in the future. Additionally, you would rather not have to deal with library-incompatibilities, and have a holistic perspective of the entire architecture - you may not need all components at first, but it is ready for you, if and when the need arises - and is guaranteed to work well with whatever you already have. In some frameworks (like YUI), you can pick and choose architectural components in advance, and have a loader that compiles just the parts you need - and in future scenarios, it would be only a matter of re-configuring the loader. Also, preferably, your application architecture should be modular, so it is easy to maintain, reason about, and most importantly "test".

And all this without even going into cross-platform and cross-browser issues...

These are all very common problems, that many people have to deal with every day, and they are all solving the same problems, and that is a duplication-of-efforts - so a community-based library/framework makes sense - few people solve a given recurring problem, and all the rest benefit from not having to re-inventing the wheel - like it is in web2py for the server.

And so you have to write less code - that makes your application more scaleable, as you can make bigger projects with less code to maintain.

Here is another good lecture about some of the aspects:

http://www.youtube.com/watch?v=hod-KX81i7s

[David Marko]

This scenario of one-page application is quite important for mobile hybrid applications. In this case you need standalone app running in device and consuming data from server. The server provides JSON coomunication with app. We have a great experience with  http://trigger.io  & http://angularjs.org/ ... 

[Alec Taylor]

Another vote for AngularJS

[António Ramos]

Top of tops

http://www.meteor.com

Because life is too short to learn all the things

2013/4/3 Alec Taylor <alec.t...@gmail.com>

[David Marko]

Meteor is different beast as it is also serverside platform based on node.js ... But development of this framework is quite slow ...

[Alec Taylor]

Just went through a couple of the examples with Meteor

It's certainly interesting; but is quite verbose to write and manage.

Most impressive was how completely self-contained those examples are.

Other frameworks documentation definitely need to pickup their game.

For example, when I was testing Ember.js many months ago it had such
horrible documentation that I started looking at competitors.

On Wed, Apr 3, 2013 at 10:58 PM, David Marko <dma...@tiscali.cz> wrote:
> Meteor is different beast as it is also serverside platform based on node.js ... But development of this framework is quite slow ...
>

[Arnon Marcus]

Ember.JS was actually the last framework I researched.

I went through Backbone, Knockout, Angular, Batman, Enyo, JavascriptMVC, and some others...

Meteor, Derby, SocketStream and the like, are the forward-looking "Next-Gen" hipsters, but they are not comparable to EmberJS, for many reasons.

For one, they are all in the "Node.js" family, in that they "require" it as the back-end - so it has no relevance in a discussion on potential web2py front-ends.

Meteor, from what I hear, accesses the database from the client "exclusively", and only supports MongoDB (which is not a relational database...).

And all these are based exclusively on bi-directional communication channels - with an emphasis on WebSockets.

I think Meteor runs exclusively on WebSockets, so it requires it's support, which is still problematic for the open-web, nowadays.

SocketStream has fall-backs, I think Derby might have it as well - but relying on real-rime channels exclusively is a mistake (at leas for now...) - The fall-backs incur additional latencies and complexities - and WebSockets deployment is more difficult, even when it works.

I think even for the future, WebSockets will not replace HTTP entirely - it is an added-feature of the web, used only when it's really needed.

Here is a good talk about it:

http://www.infoq.com/presentations/Introduction-WebSocket

Also, none of the above frameworks have nearly as full of a full-stack feature-set as Ember.js

As for Angular, I totally get the enthusiasm, I was enthusiastic as hell about it for a while - it is a glimpse of the future of HTML.

The documentation for it, is probably better then for Ember - for now - But I predict that will change in the very near future.

But I still think that Ember is the better-deal, especially for web2py users, because it is so familiar in it's structure and feature-set.

I'm not sure how Angular does against EmberData, if it has anything remotely like that...

And I'm curious how Angular's Router compares with Ember's one - I predict that they are pretty similar, but that Ember's is better.  

I am also not sure how Angular would behave on a Mobile... Both frameworks are relatively comparable in terms of size (I think Ember might be "fatter"), but this is not what worries me - I think the loading-time is less important than performance in general usage - and there, I would wonder how an a phone would deal with complex HTML-compilation and all that constant object-model-traversal for dirty-checking... I predict that it would be slower in complex apps in Angulat on a phone then in Ember on the same phone - but it's just a hunch at the moment...

Also, as Ember's templates can be compiled on a server, this could have a benefit over Angular's templates, when it comes to Mobile... 

[Arnon Marcus]

As for real-time / WebSockets stuff, the Ember guys are working on an adapter for EmberData that is going to do just that - so once you implement the relevant modifications for your server, you could start using Web-Sockets in Ember with the same app you already developed with it (!) - no code would have to be changes, as all the data-related code will have already been using EmberData, ans do it's just a matter of switching a back-end-adapter in EmberData, and the rest will stay as it is, and everything will fly ! Easy-peasy... :)

[Alec Taylor]

I hear what you're saying, but ember/data seems far too young to be a
feature point; and everything else you mentioned was mere speculation.

Not to discount you entirely, what you mentioned about prerendering
templates server-side is a very good point. This has been a feature
request with AngularJS for a while now.

Hopefully we'll have it in the Angular world soon.

[Richard Vézina]

Arnon,

I really appreciate your work, I think it helps a lot all of us to get your input about all those frameworks...

Richard

[Massimo Di Pierro]

+1

[Richard Vézina]

Also, I am curious to know your opinion about Sencha Ext Js : http://www.sencha.com/products/extjs/examples/

Not sure how it compares to the others though

Richard

[Andrew W]

Would you use ember with web2py? Why?
Is having two mvc frameworks at the same time too many?

[Derek]

And that's my whole issue with it, is you'd have two MVC frameworks that you'd have to work through, or you have static pages and your controller would just be a link back into the data access layer (DAL).  Now, for Web3py that's maybe all that is needed - create a DAL, authentication, caching of static content and database calls, and no controllers (you'd have routes, but that's it). That way your controllers would be javascript (your javascript framework of choice or just plain javascript) and your views would be the static html (which would essentialy become templates for your controllers). However, if that's all Web3py is going to be, then I could just write my own server using gevent, which would just have different functions for accessing the database and jsonifying / de-jsonifying the data. 

[Niphlod]

yep. when all the logic is pushed client-side, you need just a backend to (eventually) store data, a full-blown MVC server-side framework is not needed anymore.

Anyway, when you start to blob out large chunks of javascript client-side just to do, e.g., an email address validation, you need to choose where the right balance is.

[Arnon Marcus]

I agree that it does seem right now, that the current trend in the web-development world, in general, is moving in the direction of transferring more and more tasks to the client, as those become more and more capable.

But I wouldn't bury web2py just yet... (nor any other server-side framework for that matter)

As in the WebSockets story, the current temporary "Hype" is exaggerating the perception of the long-term eventual-effect. I think server-side frameworks are here to stay - at least for the foreseeable future - it's not gonna be an "all or nothing" transference in all cases, not even in most. It is still much harder on the client, even with things like Ember - especially considering the whole cross-browser/platform story. The whole "Google" thing about - "everything going to the web"... I don't buy it - not yet. Google-Docs is an amazing idea "in theory" - in practice, it's a buggy mess of crap... (and in Google's own chrome, for f#ck sake...)

Most simple applications, websites, etc. are not as complex as, say, an Intranet business applications (such as the one I've been working on for the past 3 years) - which is a market still dominated by desktop applications. But yes, the expectations are changing... Slowly...

I think it's going to be a long and "hybrid-ridden" transition.

For now, I've seen talks about how to maximize loading time, template-rendering can be done on the server, even for desktop usage - and that's rendering to plain HTML, not a JavaScript Object-Tree - so it can still be done in web2py. Once the static HTML loads, the framework then kicks-in, and starts climbing and crawling over the DOM, attaching itself and building it's JavaScript-Object-Tree and injecting dependencies into the DOM and such... There are frameworks that go that rout - don't know to what degree Angular or Ember are in this category, though...

The main incentive here, other than speeding-up loading time, is the whole SEO story... (search-engine-optimization) Search-engine crawlers/spiders need static HTML to search in - if the entire thing is Javascript-generated, it is virtually unsearchable... And no web-site owner wants that... Only Intranet applications don't care about such things...

Then there's this thing about resources, RESTfull'ness and ORMs...

I think that web2py's models and controllers will remain relevant, as there is a difference between the model of the data in it's view's usage, and the model of the data in the database. Most of what the controllers are doing in web2py, in my experience, apart from querying the DAL, is data-manipulation - translating one data-model into another, to meet the needs of the views for optimal and elegant usage. This role can stay in the server, as in some cases, much less information has to go through the wire this way. Can this be done in the client's controllers? Maybe. But I'm not sure it should - not in all cases. I think it might actually be easier for a client to deal with a data-model that is already structured in a manner that most fits the need at hand - and have that be CRUD'ed in that form. A client's MVC component shouldn't care how the data is actually stored on the database - it can request it's resources in a form that is already pre-transformed and structured especially for it's needs.

So what you can do, is have the starting-point server-side portion of the URL of each screen, still be of a web2py controller, which would then either be transferred via a web2py view if it's a full-refresh/first-time-load, or as a JSON resource in an AJAX manner is all other cases.

In both scenarios, the web2py's controller's role would be to query the DAL and optimally translate the data for the client's screen - for the GET method, and do a reverse-translation for the POST one...

So here's what I see:

I see a diverse web-development world, with varying degrees of server-side logic usage, in some cases dynamically switching from server to client and back, based on needs, requirements, trade-offs criteria, and target-platforms.

[Arnon Marcus]

Just found another interesting talk on the subject :

http://www.infoq.com/interviews/tilkov-rest-hypermedia

[Alec Taylor]

Not a bad argument Arnon, but you shouldn't discount search scrapers so easily.

I think Google's Search Bot has support AJAX for a good 5 years now.

Translating between web2py DAL and (for example) AngularJS forms is
not completely straightforward.

However, with the help of metawidget it is very possible.

What would be best is if we had an SQLFORM() style generator in
JavaScript; which is completely decoupled from the server side. This
appears to be what metawidget is. Now we just need the generator on
the Python end and we'll be home free.

[Richard Vézina]

Alec, 

I think you are on a rigth spot about "javascript web2py validator" that something that are missing when someone want to transfert some stuff to client side... Now it requires that we reinvent the wheel... If there were a way we could reuse the web2py validators definition and use them in a client side form that kind of auto-submit trougth ajax it could be much more appealing to brake the web2py workflow (I mean server-side processing/validation of form)...

Richard

[Derek]

I read that metawidget thing and it seems interesting, can you write more about how to get metawidget working with web2py?

[Niphlod]

just to clarify on the

Not a bad argument Arnon, but you shouldn't discount search scrapers so easily.

I think Google's Search Bot has support AJAX for a good 5 years now.

part ..... have you actually tried it ??????

search bots (google included) have "some" ajax support in the sense that if you plan it, it works.
Basically if you planned you site to output the data as if it was without javascript, it works.
That's FAR from "they have ajax support".

They DON'T execute any javascript at all.

There's a "preview app" of what google bot will see in your page, try it ^_^

They just follow links that you prepared carefully. The most notable example is that if you have e.g.
 
<a href="/shomethefragment.html" onclick='window.location="http://mysite/app/showmethefragment2.html"'>

they'll request showmethefragment.html, while they **should** fetch  "http://mysite/app/showmethefragment2.html"

@all: plan carefully if SEO is important for you. More info at https://developers.google.com/webmasters/ajax-crawling/

[Niphlod]

PS: ajax is not quite the same as javascript, but the underlying "core concept" of the previous post is valid for both.

[Derek]

After writing this, I realized that it's not beyond my grasp to write my own wsgi web app, so I'm going that route. 

I've been at it a few days, and I do miss the automatic CSRF and double submit that W2P provides. It's also very easy to just add plugins. Still, I am having fun writing my own "framework". Perhaps one day I'll release it. As of now, it just connects via ldap, authorizes users, does sql queries (from sql written by hand) and outputs to json. WSGI is a nice PEP and makes writing your web apps or frameworks easier.

[Magnitus]

I'm gravitating between Angular and Ember as well, though my mind is not yet set on a particular one.

I've started with Ember, but I'll probably end up knowing both just for completeness.

For me, web2py relying less on generating client-side logic would be good as I've never used it much, except for URL and includes.

Customizing the login form, removing default csses, javascript and whatnot has always been a bit of a pain in the neck.

On Tuesday, 2 April 2013 06:01:10 UTC-4, Arnon Marcus wrote:

EmberJS is one of the most comprehensive MVC frameworks of the day - it's "batteries included" (like web2py).

It is inspired by Ruby-on-Rails, in terms of preferring "convention-over-configuration" (like web2py).

It has "sane defaults" for the high-level architecture, so it could require minimal code for standard stuff (like web2py).

The MVC naming-structure is somewhat different, but essentially the same components exist as in web2py.

 

The Router:

 

Like in web2py, there is a convention for mapping controllers to views, but unlike web2py, routing (the mapping of URLs to code) is done explicitly.

It is analogous to web2py's "routs.py" file.

The router is doing client-side routing, translating code to URL and vice-versa.

 

The Model:

 

Firstly, there is an extension called EmberData that works holistically with EmberJS (but can be used without it) that does all the front-end/back-end synchronization.

It is analogues to web2py's database-abstraction-layer (DAL) architecture, for supporting multiple optional back-ends, and converting data to an ORM (object-relation-model).

As in RoR (ruby-on-rails), the conversion is done via "Adapters" which are like web2py's DAL-drivers.

In RoR it outputs what's known as "Active-Records" - essentially, objects that map to the back-end, and "know" how to save/update data back.

In EmberData you would write:

                model  = DS.Store.create()

Where in web2py you would write:

                db = DAL(<connection-string>)

The data received from the backend, after being converted to ORM objects, is known as "Records".

What is called "Record" in EmberData is essentially like a "Row" object in web2py, and similarly a "RecordArray" in EmberData is analogous to a "Rows" object in web2py.

 

 The View:

 

In EmberJS, a "view" is somewhat different from what a "view" in web2py, as it deals with user-interaction event-handeling.

However, EmberJS uses "Templates" which are essentially what web2py's "views" are. It even uses very similar templating  language with a squirrely-brackets ("{{<somthing>}}").

It has similar uses, so where in web2py, a controller "passes" data to the view, in EmberJS a controller "binds" data to a template.

The difference here is that because it is all client-side, EmberJS can do data-binding - whenever a controller's bound-data changes, the template automatically updates itself in the UI.

Additionally, in EmberJS there are special names that do special things inside a template.

For example:

Where in web2py, the "layout" may have something like:

                ...

                <header>...</header>

                ...           

                {{include}}

                ...

                <footer>...</footer>

                ...

In ember it would be:

                ...

                <header>...</header>

                ...           

                {{outlet}}

                ...

                <footer>...</footer>

                ...

Essentially meaning "everything else inside this template, put here"...

 

Similarly, where in web2py you would write:

                ...

                {{if someBoolean}}

                <div>{{someBoolean}}</div>

                {{pass}}

                ...

                <ol>

                                {{for a in someArray}}

                                <li>{{a}}</li>

                                {{pass}}

                </ol>

                ...

In EmberJS it would look something like this:

                ...

                {{#if someBoolean}}

                <div>{{someBoolean}}</div>

                {{/if}}

                ...

                <ol>

                                {{#each a in someArray}}

                                <li>{{a}}</li>

                                {{/each}}

                </ol>

                ...

Also, where in web2py the mapping of views to controllers is done via folder-structure + file-naming,

in EmberJS it is done via name-mapping of controller-object-name and template-object-name.

 

 The Controller:

 

In web2py a controller automatically maps to a sub-set of the URL, and may have many functions called "Actions", which each is mapped to a view.

In EmberJS this is further generalized in the "Router", which can contain many nested "Routs", each mapped to a single "controller" via the router and/or naming-convention.

So an EmberJS "Rout" is analogous to a web2py "Controller", and an EmberJS "Controller" is analogous to a web2py "Controller-Action".

This is offers a more flexible hierarchy for the application, as a router can "nest" routs as deeply as you want.

 

 

Here are some great (and funny) videos about Ember (watching in order is advisable):

 

EmberData

 

EmberJS (you can skip the live-demo part in the middle, it's not very clear here..)

 

Live Demo (This one is very clear.)

[Niphlod]

so basically you just need to have a different scaffolding app ? Seems hardly a show-stopper :D

[Magnitus]

Well, basically, it limited the usefulness of the form facilities and the tight default integration between authentication and the rendered pages took some time to bypass and then there was stripping the layout.html file to it's bare essentials.

Overall, I've always been much happier to use web2py for it's server-side features and let it be a flexible interface with which 100% custom-made client-side code could interact.

[Arnon Marcus]

On Tuesday, April 16, 2013 1:38:11 PM UTC-7, Magnitus wrote:

Well, basically, it limited the usefulness of the form facilities and the tight default integration between authentication and the rendered pages took some time to bypass

I wrote a while back, about an idea I had for integrating knockout/Angular templating into the HTML helper classes. I see no reason why this idea can-not be extended to refactor the FORM/SQLFOM classes to do the same...

The way I approach SAP implementation (in my head...) with web2py, is that you use the web2py views to construct the parts of the pages, as they should be loaded for first-time component-loads and for full-page-refreshes/redirects. This way, if you integrate support for all of web2py's magnificent helper-classes so that they generate SAP-client-side framework templates, you can get the best of both worlds.

Granted, for Ember and every other framework using Handlebars, you might have to switch the delimiter-definition of either web2py or handlebars in order to avoid collisions...

[Niphlod]

On Tuesday, April 16, 2013 10:38:11 PM UTC+2, Magnitus wrote:

Well, basically, it limited the usefulness of the form facilities and the tight default integration between authentication and the rendered pages took some time to bypass and then there was stripping the layout.html file to it's bare essentials.

Overall, I've always been much happier to use web2py for it's server-side features and let it be a flexible interface with which 100% custom-made client-side code could interact.

 

yeah. the real problem is that no-one working on angularjs is making public its own widgets.
All that it takes is overloading SQLFORM.widgets and given that we ship web2py with a formstyle parameter that can be a callable from some time, all that is needed is something that generates angular templates out of models (and someone that is willing to do it).
Once stable, that formstyle can be included in standard web2py and the "newwidgets.py" module shipped in gluon/contrib.
then SQLFORM(thetable, formstyle='angularjs') will be all what's needed

Right now I don't have any interest in angularjs so I call myself out of the competition, but feel free to pack a starter app and I'll be more than glad to review the code.

[Alec Taylor]

FYI: The presenter/author has published his examples using metawidget
and AngularJS to generate forms:
http://files.meetup.com/4966012/Metawidget%20AngularJS%20Examples.zip

[Magnitus]

I'm not even sure I'll go with Angular myself at this point. I'll delve more deeply into that framework once I feel I have a sufficient grasp of Ember.

For the whole server-side dynamically generating client-side, I'm afraid it's not my vision.

The direction things are moving toward is to move away from the server dynamically generating client-side and rather have the client-side generate itself using data it gets from the server.

I've done both and I find that having the client-side generate itself is the cleaner approach in the end (though it probably has a steeper learning curve, unfortunately). In essence, it makes the "V" part of MVC more trivial for the server and moves more of that logic on the client-side where I think it belongs.

The way I'd see web2py supporting "widgets" is simply to provide some protocol (currently via ajax) that the client-side expects from the server to update itself. Maybe also javascript files for different frameworks (vanilla jQuery, Ember, Angular) if you want some pre-made solutions so that web2py can be as interoperable on the client side as it is on the backend (where you can choose from many different servers and databases).

[António Ramos]

is meteor the answer?

2013/4/18 Magnitus <fbunn...@hotmail.com>

[Niphlod]

it's definitely not for a lot of reasons, but if you like to dwelve with *buzzword*, give it a spin.

[Derek]

What's the question that it's supposed to answer?

[António Ramos]

as i understood , the discussion seems to be the around single page apps that have its code in the client and then just push/pull data from the server.

meteor takes care of this problem and we just have to subscribe to changes in reactive data sources.

Its less code to worry about. No ajax! Just works! The client keeps a local copy of the mongo database that gets sync with server.

The way i see it, its "AWSOME". 

Now you try to convinve me otherwise. :)

Best regards

António

2013/4/18 Derek <sp1...@gmail.com>

[Niphlod]

for starters, not all sites can be converted into the "single page app" paradigm.
On the brigther note, if you need just that, then meteor is built with that agenda in mind: try to diverge just a little and you won't leverage its potential.

[Anthony]

Another similar (though somewhat less mature) option is Derby (also built on Node.js). Advantages over Meteor are two-way data binding and the ability to render on the server as well as the client (for search engine crawling and faster initial page loads).

Anthony

[Arnon Marcus]

Well, there is no "one-size-fit's-all", and there is never gonna be...

Currently, expecting a direct-connection with the database from the client side, still raises many eye-brows, and (IMHO) rightfully so...

But that is exactly the expectation that frameworks like meteor are having.

Iy is not going to work in the foreseeable future, for many web-apps to hold their entire database on the client side... There are way too many things to consider when wanting to do that (security, privacy, authorization, resource-use, etc.).

I also thing it's a mistake to assume the client-side even "needs" that, for most cases.

As I said, the data-model that the client needs, is almost "always" very different to the data-model in the database. For simple and small web-sites, that may work out, but once you get pass a certain level of complexity, and have hundreds of inter-linking tables, then in most of these cases it would make no sense having an identical data model in the client - it would be horobly wastefull and inefficient to the point of being unusable.

Also, the client-side is still very lacking in terms of options of handling and handling relational data-models. Web2py's DAL is a god-sent - it is an ORM that is second-to-none afaik.

In short, it would fit a very, well, (ahm..) "boring" target-audience... (no offence...)

Not for complex web-apps.

I think you could achieve all the benefits of meteor/derby with a hybrid-solution.

Generally, there is no problem with the idea of auto-synching data-models across clients - it is actually a very exciting prospect - it should just not be assumed to be applicable for the whole database, is an "all-or-nothing" kind of way.

I see a better vision - a web-app that has compartmentalized views, each within it's own little MVC world, and it's own data-model which represent a small portion of the database, structured specifically for that view's needs. Each of these components can have streaming communication with other instances of that save view in other browsers of other users, as well as with n instance of that same data-model on a server somewhere, which will take care of eventual-consistency in the background with the back-end database.

I predict that this would be the model that would emergent to be the dominant one - you already see glimpses of it - Google Wave was an example - even long before web-sockets and data-store on the client. The entire google-gear architecture was an attempt at making something like this. 

[Anthony]

Iy is not going to work in the foreseeable future, for many web-apps to hold their entire database on the client side...

Are you talking about the model definitions, or the actual data? They certainly don't move all the data in the entire database to the client.

 

For simple and small web-sites, that may work out, but once you get pass a certain level of complexity, and have hundreds of inter-linking tables, then in most of these cases it would make no sense having an identical data model in the client - it would be horobly wastefull and inefficient to the point of being unusable.

At least Derby allows for server-only routes and models, in addition to whatever is on the client.

 

Also, the client-side is still very lacking in terms of options of handling and handling relational data-models.

I've noticed these frameworks tend to be geared toward document-based datastores, like MongoDB, rather than RDBMS's.

 

In short, it would fit a very, well, (ahm..) "boring" target-audience... (no offence...)

Not for complex web-apps.

Not sure how complex these are, but they don't seem trivial, and certainly not "boring":

https://unroll.me/

https://www.habitrpg.com/static/front

I predict that this would be the model that would emergent to be the dominant one - you already see glimpses of it - Google Wave was an example - even long before web-sockets and data-store on the client.

Interestingly, one of the Google Wave developers went on to create ShareJS and now works on Derby (which is incorporating ShareJS).

Anthony

[António Ramos]

 Nice comment but a minor correction. 

In meteor the client only has in his local database the documents he is allowed to read.

That solves the security issues on the client.

What I like most in meteor is

Not having to refresh the browser on every change i make in code.

Not having to code web sockets to deal with data change. Here we save a lot of code.

Having all clients update automatically on every data change made by some client.

For specific real time web apps I don't know  a better option.but that's just me. 

--

[Arnon Marcus]

Well, as for the database, there are obvious security issues and performance issues - I mean, having an open connection from all clients to a single back-end database is a pretty nutty prospect for most serious programmers...

Just think about connection-count,you can't even do connection pooling on this... You basically need to have an extremely wide eventually-consistent replication-cluster in the cloud, with like thousands of instances... That's horribly inefficient. And in terms of security? Lot's of people are still reluctant to trust the browser for even simple things like client-side validation, you think that an open-connection to a back-end database is gonna fly with these kind of folks?

And as for No-SQL vs RDBM, well, again, it is a question of target-audience - it depends on the level of complexity of inter-relation in your use-case's data model, so as I said - complex data-model benefit way too much from RDBMs and gain so little from No-SQL that it is simply un-fit for them... But that's a different topic altogether.

As for real-time synchronization, again, it may be implemented really well in derby/meteor today, but I forsee that there are going to be many such implementations for general use-cases.

I think there is an extension/version of web-sockets that is aimed at p2p, so you can basically do it without any server at all, eventually.

As for no-refresh updates of the web-browser, it has nothing to do with meteor/derby or even any kind of real-time app - it is a browser-extension, coupled with a client/server library, that monitors your file-savings of your code, and pushes updates to your development browser. There are many such solutions today for many kinds of browsers and serves - it was just easy to implement in node.js because it's all javascript on both ends... There is nothing fundamentally restricting from doing this with web2py - you can run an instance of node.js that basically only does "that" for you, and still use web2py for all other stuff... It can even be implemented inside web2py itself, with like a worker-thread or something... You can even write something like this yourself - basically poll on file-changes of your javascript code, and stream them over an open web-socket, and parse them on your clien-side code to update your existing page...

In the p2p-web-socket future world, people could theoretically do crazy stuff with that between each-other... :) Pretty diabolical shit...

--
 
---
You received this message because you are subscribed to a topic in the Google Groups "web2py-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/web2py/kXXr9xo_2tM/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to web2py+un...@googlegroups.com.

[Anthony]

On Thursday, April 18, 2013 7:00:48 PM UTC-4, Arnon Marcus wrote:

Well, as for the database, there are obvious security issues and performance issues - I mean, having an open connection from all clients to a single back-end database is a pretty nutty prospect for most serious programmers...

I don't know all the details, but I don't think that's how it works. And from what I can tell, both the Derby and the Meteor folks are "serious programmers". 

 

And as for No-SQL vs RDBM, well, again, it is a question of target-audience - it depends on the level of complexity of inter-relation in your use-case's data model, so as I said - complex data-model benefit way too much from RDBMs and gain so little from No-SQL that it is simply un-fit for them... But that's a different topic altogether.

https://unroll.me/ uses MySQL.

 

As for no-refresh updates of the web-browser, it has nothing to do with meteor/derby or even any kind of real-time app - it is a browser-extension, coupled with a client/server library, that monitors your file-savings of your code, and pushes updates to your development browser. There are many such solutions today for many kinds of browsers and serves - it was just easy to implement in node.js because it's all javascript on both ends... There is nothing fundamentally restricting from doing this with web2py - you can run an instance of node.js that basically only does "that" for you, and still use web2py for all other stuff... It can even be implemented inside web2py itself, with like a worker-thread or something... You can even write something like this yourself - basically poll on file-changes of your javascript code, and stream them over an open web-socket, and parse them on your clien-side code to update your existing page...

I don't think Meteor or Derby are fully worked out yet, but neither is your hypothetical web2py variant that does all this. At the moment, Meteor and Derby at least have the advantage of existing. I think that's the point Ramos was making -- Meteor is doing some cool stuff now, not that such things couldn't in theory be implemented in another language/platform. Actually, in the Python world, there is (was?) the Planet framework, though it is proprietary and was quite expensive (looks like it's no longer active or available).

Anthony