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 > <a.m.m...@gmail.com<javascript:>> > 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.com. For more options, visit https://groups.google.com/groups/opt_out.
