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 <alec.tayl...@gmail.com> wrote: > On Thu, Apr 4, 2013 at 7:05 AM, Arnon Marcus <a.m.mar...@gmail.com> 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. > > > -- --- 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.
