Re: [web2py] Re: EmberJS is the web2py of the client! :)

[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

-- 

--- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [web2py] Re: EmberJS is the web2py of the client! :)

[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. 

-- 

--- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [web2py] Re: EmberJS is the web2py of the client! :)

[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

On Thursday, April 18, 2013 1:20:57 PM UTC-4, Ramos wrote:
>
> 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 >
>
>> What's the question that it's supposed to answer?
>>
>>
>> On Thursday, April 18, 2013 8:13:55 AM UTC-7, Ramos wrote:
>>
>>> is meteor the answer?
>>>
>>>
>>> 2013/4/18 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). 

 On Tuesday, 16 April 2013 17:12:48 UTC-4, Niphlod wrote:
>
>
>
> 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.
>
>
>  -- 
  
 --- 
 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
 .
  
  

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

-- 

--- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [web2py] Re: EmberJS is the web2py of the client! :)

[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. 

On Thursday, April 18, 2013 7:20:57 PM UTC+2, Ramos wrote:
>
> 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 >
>
>> What's the question that it's supposed to answer?
>>
>>
>> On Thursday, April 18, 2013 8:13:55 AM UTC-7, Ramos wrote:
>>
>>> is meteor the answer?
>>>
>>>
>>> 2013/4/18 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). 

 On Tuesday, 16 April 2013 17:12:48 UTC-4, Niphlod wrote:
>
>
>
> 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.
>
>
>  -- 
  
 --- 
 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
 .
  
  

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

-- 

--- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [web2py] Re: EmberJS is the web2py of the client! :)

[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 

> What's the question that it's supposed to answer?
>
>
> On Thursday, April 18, 2013 8:13:55 AM UTC-7, Ramos wrote:
>
>> is meteor the answer?
>>
>>
>> 2013/4/18 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).
>>>
>>> On Tuesday, 16 April 2013 17:12:48 UTC-4, Niphlod wrote:



 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.


  --
>>>
>>> ---
>>> 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
>>> .
>>>
>>>
>>>
>>
>>  --
>
> ---
> 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+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 

--- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [web2py] Re: EmberJS is the web2py of the client! :)

[Derek]

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

On Thursday, April 18, 2013 8:13:55 AM UTC-7, Ramos wrote:
>
> is meteor the answer?
>
>
> 2013/4/18 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). 
>>
>> On Tuesday, 16 April 2013 17:12:48 UTC-4, Niphlod wrote:
>>>
>>>
>>>
>>> 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.
>>>
>>>
>>>  -- 
>>  
>> --- 
>> 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.
>>  
>>  
>>
>
>

-- 

--- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [web2py] Re: EmberJS is the web2py of the client! :)

[Niphlod]

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

On Thursday, April 18, 2013 5:13:55 PM UTC+2, Ramos wrote:
>
> is meteor the answer?
>
>
> 2013/4/18 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). 
>>
>> On Tuesday, 16 April 2013 17:12:48 UTC-4, Niphlod wrote:
>>>
>>>
>>>
>>> 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.
>>>
>>>
>>>  -- 
>>  
>> --- 
>> 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.
>>  
>>  
>>
>
>

-- 

--- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [web2py] Re: EmberJS is the web2py of the client! :)

[António Ramos]

is meteor the answer?


2013/4/18 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).
>
> On Tuesday, 16 April 2013 17:12:48 UTC-4, Niphlod wrote:
>>
>>
>>
>> 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.
>>
>>
>>  --
>
> ---
> 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+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 

--- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[web2py] Re: EmberJS is the web2py of the client! :)

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

On Tuesday, 16 April 2013 17:12:48 UTC-4, Niphlod wrote:
>
>
>
> 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.
>
>
>

-- 

--- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [web2py] Re: EmberJS is the web2py of the client! :)

[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

On Wed, Apr 17, 2013 at 7:12 AM, Niphlod  wrote:
>
>
> 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.
>
>
> --
>
> ---
> 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+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

-- 

--- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[web2py] Re: EmberJS is the web2py of the client! :)

[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.


-- 

--- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[web2py] Re: EmberJS is the web2py of the client! :)

[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...

-- 

--- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[web2py] Re: EmberJS is the web2py of the client! :)

[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.

Le mardi 16 avril 2013 14:10:23 UTC-4, Niphlod a écrit :
>
> so basically you just need to have a different scaffolding app ? Seems 
> hardly a show-stopper :D
>
> On Tuesday, April 16, 2013 6:45:57 PM UTC+2, Magnitus wrote:
>>
>>
>> Customizing the login form, removing default csses, javascript and 
>> whatnot has always been a bit of a pain in the neck.
>>
>>

-- 

--- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[web2py] Re: EmberJS is the web2py of the client! :)

[Niphlod]

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

On Tuesday, April 16, 2013 6:45:57 PM UTC+2, Magnitus wrote:
>
>
> Customizing the login form, removing default csses, javascript and whatnot 
> has always been a bit of a pain in the neck.
>
>

-- 

--- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[web2py] Re: EmberJS is the web2py of the client! :)

[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()
>
> 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 ("{{}}").
>
> 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:
>
> ...
>
> ...
>
> ...
>
> {{include}}
>
> ...
>
> ...
>
> ...
>
> In ember it would be:
>
> ...
>
> ...
>
> ...
>
> {{outlet}}
>
> ...
>
> ...
>
> ...
>
> Essentially meaning "everything else inside this template, put here"...
>
>  
>
> Similarly, where in web2py you would write:
>
> ...
>
> {{if someBoolean}}
>
> {{someBoolean}}
>
> {{pass}}
>
> ...
>
> 
>
> {{for a in someArray}}
>
> {{a}}
>
> {{pass}}
>
> 
>
> ...
>
> In EmberJS it would look something like this:
>
> ...
>
> {{#if someBoolean}}
>
> {{someBoolean}}
>
> {{/if}}
>
> ...
>
> 
>
> {{#each a in someArray}}
>
> {{a}}
>
> {{/each}}
>
> 
>
> ...
>
> 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", whi

[web2py] Re: EmberJS is the web2py of the client! :)

[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.

On Wednesday, April 3, 2013 10:51:52 AM UTC-7, Derek wrote:
>
> 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. 
>
> On Wednesday, April 3, 2013 10:12:52 AM UTC-7, Andrew W wrote:
>>
>> Would you use ember with web2py? Why?
>> Is having two mvc frameworks at the same time too many?
>
>

-- 

--- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [web2py] Re: EmberJS is the web2py of the client! :)

[Niphlod]

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

On Thursday, April 4, 2013 11:27:02 PM UTC+2, Niphlod wrote:
>
> 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. 
>  
> 
>
> 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/
>
>
>

-- 

--- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [web2py] Re: EmberJS is the web2py of the client! :)

[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. 
 


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/


-- 

--- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [web2py] Re: EmberJS is the web2py of the client! :)

[Derek]

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

On Wednesday, April 3, 2013 10:31:36 PM UTC-7, Alec Taylor wrote:
>
> On Thu, Apr 4, 2013 at 7:05 AM, Arnon Marcus 
> > 
> wrote: 
> > 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. 
>
> 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. 
>
> H

Re: [web2py] Re: EmberJS is the web2py of the client! :)

[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


On Thu, Apr 4, 2013 at 1:31 AM, Alec Taylor  wrote:

> On Thu, Apr 4, 2013 at 7:05 AM, Arnon Marcus  wrote:
> > 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.
>
> Not a bad argument Arnon, but you shouldn't d

Re: [web2py] Re: EmberJS is the web2py of the client! :)

[Alec Taylor]

On Thu, Apr 4, 2013 at 7:05 AM, Arnon Marcus  wrote:
> 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.

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.

-- 

--- 
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+unsubscr...@googlegroups

[web2py] Re: EmberJS is the web2py of the client! :)

[Arnon Marcus]

Just found another interesting talk on the subject :

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

-- 

--- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[web2py] Re: EmberJS is the web2py of the client! :)

[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.

-- 

--- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[web2py] Re: EmberJS is the web2py of the client! :)

[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.


On Wednesday, April 3, 2013 7:51:52 PM UTC+2, Derek wrote:
>
> 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. 
>
> On Wednesday, April 3, 2013 10:12:52 AM UTC-7, Andrew W wrote:
>>
>> Would you use ember with web2py? Why?
>> Is having two mvc frameworks at the same time too many?
>
>

-- 

--- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[web2py] Re: EmberJS is the web2py of the client! :)

[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. 

On Wednesday, April 3, 2013 10:12:52 AM UTC-7, Andrew W wrote:
>
> Would you use ember with web2py? Why?
> Is having two mvc frameworks at the same time too many?

-- 

--- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[web2py] Re: EmberJS is the web2py of the client! :)

[Andrew W]

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

-- 

--- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [web2py] Re: EmberJS is the web2py of the client! :)

[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


On Wed, Apr 3, 2013 at 11:13 AM, Richard Vézina  wrote:

> Arnon,
>
> I really appreciate your work, I think it helps a lot all of us to get
> your input about all those frameworks...
>
> Richard
>
>
> On Wed, Apr 3, 2013 at 10:50 AM, Alec Taylor wrote:
>
>> 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.
>>
>> On Thu, Apr 4, 2013 at 1:28 AM, Arnon Marcus 
>> wrote:
>> > 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... :)
>> >
>> > --
>> >
>> > ---
>> > 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+unsubscr...@googlegroups.com.
>> > For more options, visit https://groups.google.com/groups/opt_out.
>> >
>> >
>>
>> --
>>
>> ---
>> 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+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>>
>

-- 

--- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [web2py] Re: EmberJS is the web2py of the client! :)

[Massimo Di Pierro]

+1

On Wednesday, 3 April 2013 10:13:23 UTC-5, Richard wrote:
>
> Arnon,
>
> I really appreciate your work, I think it helps a lot all of us to get 
> your input about all those frameworks...
>
> Richard
>
>
> On Wed, Apr 3, 2013 at 10:50 AM, Alec Taylor 
> > wrote:
>
>> 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.
>>
>> On Thu, Apr 4, 2013 at 1:28 AM, Arnon Marcus 
>> > 
>> wrote:
>> > 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... :)
>> >
>> > --
>> >
>> > ---
>> > 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.
>> >
>> >
>>
>> --
>>
>> ---
>> 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.
>>
>>
>>
>

-- 

--- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [web2py] Re: EmberJS is the web2py of the client! :)

[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


On Wed, Apr 3, 2013 at 10:50 AM, Alec Taylor  wrote:

> 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.
>
> On Thu, Apr 4, 2013 at 1:28 AM, Arnon Marcus  wrote:
> > 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... :)
> >
> > --
> >
> > ---
> > 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+unsubscr...@googlegroups.com.
> > For more options, visit https://groups.google.com/groups/opt_out.
> >
> >
>
> --
>
> ---
> 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+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 

--- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [web2py] Re: EmberJS is the web2py of the client! :)

[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.

On Thu, Apr 4, 2013 at 1:28 AM, Arnon Marcus  wrote:
> 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... :)
>
> --
>
> ---
> 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+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

-- 

--- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [web2py] Re: EmberJS is the web2py of the client! :)

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

-- 

--- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [web2py] Re: EmberJS is the web2py of the client! :)

[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... 

-- 

--- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [web2py] Re: EmberJS is the web2py of the client! :)

[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  wrote:
> Meteor is different beast as it is also serverside platform based on node.js 
> ... But development of this framework is quite slow ...
>
> --
>
> ---
> 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+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

-- 

--- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [web2py] Re: EmberJS is the web2py of the client! :)

[David Marko]

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

-- 

--- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [web2py] Re: EmberJS is the web2py of the client! :)

[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 

> Another vote for AngularJS
>
> On Wed, Apr 3, 2013 at 8:58 PM, David Marko  wrote:
> > 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/
> > ...
> >
> > --
> >
> > ---
> > 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+unsubscr...@googlegroups.com.
> > For more options, visit https://groups.google.com/groups/opt_out.
> >
> >
>
> --
>
> ---
> 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+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 

--- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [web2py] Re: EmberJS is the web2py of the client! :)

[Alec Taylor]

Another vote for AngularJS

On Wed, Apr 3, 2013 at 8:58 PM, David Marko  wrote:
> 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/
> ...
>
> --
>
> ---
> 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+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

-- 

--- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [web2py] Re: EmberJS is the web2py of the client! :)

[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/ ... 

-- 

--- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [web2py] Re: EmberJS is the web2py of the client! :)

[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

-- 

--- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [web2py] Re: EmberJS is the web2py of the client! :)

[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. 

On Tuesday, April 2, 2013 12:41:10 PM UTC-7, Arnon Marcus wrote:
>
> 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 Sloowww 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...
>

-- 

--- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [web2py] Re: EmberJS is the web2py of the client! :)

[Arnon Marcus]

Backbone is not comparable to any full-stack MVC - it's a mere, well. 
"backbone" of an MVC framework... It's perfidiously 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 Sloowww 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...

-- 

--- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [web2py] Re: EmberJS is the web2py of the client! :)

[David Marko]

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

Dne úterý, 2. dubna 2013 19:13:20 UTC+2 Ramos napsal(a):
>
> Backbone anyone?
>
>
> 2013/4/2 Massimo Di Pierro >
>
>> Thanks for the good writing. We should make an example of integrating the 
>> two.
>>
>>
>> On Tuesday, 2 April 2013 05:01:10 UTC-5, 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()
>>>
>>> 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 ("{{}}").
>>>
>>> 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:
>>>
>>> ...
>>>
>>> ...
>>>
>>> ...
>>>
>>> {{include}}
>>>
>>> ...
>>>
>>> ...
>>>
>>> ...
>>>
>>> In ember it would be:
>>>
>>> ...
>>>
>>> ...
>>>
>>> ...
>>>
>>> {{outlet}}
>>>
>>> ...
>>>
>>> ...
>>>
>>> ...
>>>
>>> Essentially meaning "everything else inside this template, put here"...
>>>
>>>  
>>>
>>> Similarly, where in web2py you would write:
>>>
>>> ...
>>>
>>> {{if someBoolean}}
>>>
>>> {{someBoolean}}
>>>
>>> {{pass}}
>>>
>>> ...
>>>
>>> 
>>>
>>> {{for a in someArray}}
>>>
>>> {{a}}
>>>
>>>   **  {{pass}}
>>>
>>> 
>>>
>>> ...
>>>
>>> In EmberJS it would look something like this:
>>>
>>> ...
>>>
>>> {{#if someBoolean}}
>>>
>>> {{someBoolean}}
>>>
>>> {{/if}}
>>>
>>> ...
>>>
>>> 
>>>
>>> {{#each a in someArray}}
>>>
>>> {{a}}
>>>
>>>   **  {{/each}}
>>>
>>> 
>>>
>>> ...
>>>
>>> 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 aut

Re: [web2py] Re: EmberJS is the web2py of the client! :)

[António Ramos]

Backbone anyone?


2013/4/2 Massimo Di Pierro 

> Thanks for the good writing. We should make an example of integrating the
> two.
>
>
> On Tuesday, 2 April 2013 05:01:10 UTC-5, 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()
>>
>> 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 ("{{}}").
>>
>> 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:
>>
>> ...
>>
>> ...
>>
>> ...
>>
>> {{include}}
>>
>> ...
>>
>> ...
>>
>> ...
>>
>> In ember it would be:
>>
>> ...
>>
>> ...
>>
>> ...
>>
>> {{outlet}}
>>
>> ...
>>
>> ...
>>
>> ...
>>
>> Essentially meaning "everything else inside this template, put here"...
>>
>>
>>
>> Similarly, where in web2py you would write:
>>
>> ...
>>
>> {{if someBoolean}}
>>
>> {{someBoolean}}
>>
>> {{pass}}
>>
>> ...
>>
>> 
>>
>> {{for a in someArray}}
>>
>> {{a}}
>>
>>   **  {{pass}}
>>
>> 
>>
>> ...
>>
>> In EmberJS it would look something like this:
>>
>> ...
>>
>> {{#if someBoolean}}
>>
>> {{someBoolean}}
>>
>> {{/if}}
>>
>> ...
>>
>> 
>>
>> {{#each a in someArray}}
>>
>> {{a}}
>>
>>   **  {{/each}}
>>
>> 
>>
>> ...
>>
>> 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 "Control

[web2py] Re: EmberJS is the web2py of the client! :)

[Massimo Di Pierro]

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

On Tuesday, 2 April 2013 05:01:10 UTC-5, 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()
>
> 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 ("{{}}").
>
> 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:
>
> ...
>
> ...
>
> ...
>
> {{include}}
>
> ...
>
> ...
>
> ...
>
> In ember it would be:
>
> ...
>
> ...
>
> ...
>
> {{outlet}}
>
> ...
>
> ...
>
> ...
>
> Essentially meaning "everything else inside this template, put here"...
>
>  
>
> Similarly, where in web2py you would write:
>
> ...
>
> {{if someBoolean}}
>
> {{someBoolean}}
>
> {{pass}}
>
> ...
>
> 
>
> {{for a in someArray}}
>
> {{a}}
>
> {{pass}}
>
> 
>
> ...
>
> In EmberJS it would look something like this:
>
> ...
>
> {{#if someBoolean}}
>
> {{someBoolean}}
>
> {{/if}}
>
> ...
>
> 
>
> {{#each a in someArray}}
>
> {{a}}
>
> {{/each}}
>
> 
>
> ...
>
> 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 deep