Thanks Tom, your answer helped me a lot.
I come to the following conclusion: - Relatively little information, which much GUI interactive changes can best be done in JS. (btw I use PyJamas for that so I can program in pure Python) - Much information, which heavily changes on the base of user interaction can best be done by web2py. - The use of fancy JQuery widgets within web2py had not much meaning (because of the reload of the whole page) - JQuery widgets within web2py should be limited to simple effects (with already available data), like flash objects, pull-down menus, calendars etc. cheers, Stef On 03-02-2011 09:16, Tom Atkins wrote: > This isn't really a direct answer to your question but it might help clarify > some things for you > (it got me thinking anyway)... it's a quote from a user on another mailing > list: > > "There's been a big move toward Javascript-heavy web apps in the last couple > of years, and new > tools & frameworks are springing up to ease JS development -- see > Backbone.js, Knockout.js, etc. > The model here is typically to move almost the entire app to the front end. > After the initial page > load, everything happens in a single page, with no page refresh. A > server-side backend is still > (usually) a necessary component, but it's reduced to a dumb pipe to shuttle > data to/from the > database via JSON. > > This approach makes it possible to create much richer apps with lower > latency, so it's a pretty > clear win for user experience. I'm creating an app right now (in Flask) that > could benefit from > such an approach. > The problem is that you have to write most of your app in JS to do so. It > also appears to increase > the complexity of development quite a bit (beyond just learning a new tool), > and tools in this > space are fairly new and immature. But I think it's clear that this is where > web development is > headed. > > Most server-side frameworks are still firmly rooted in the old way of doing > things. It's possible > to pair them with a JS-centric front end, sure, but you give up most of their > power by doing so. > Do you see frameworks changing in the next couple of years to accommodate > this approach? Are there > big roadblocks to doing so?" > > (link for the source of this quote > is > http://flask.pocoo.org/mailinglist/archive/2011/1/31/flask-and-javascript-centric-front-ends/) > > There are of course still huge uses for web2py and other server centric > frameworks (not least ease > of development) - but if your app is (almost) one page you may find a > javascript option more > suitable. The CoffeScript site is a good example of a single (large) page > Javascript app (and if > you know Python but not Javascript you may fall in love with CoffeScript): > > http://jashkenas.github.com <http://jashkenas.github.com/> > > Have fun! > > > On 3 February 2011 00:43, Stef Mientki <stef.mien...@gmail.com > <mailto:stef.mien...@gmail.com>> wrote: > > hello, > > at the moment I'm totally confused about what should be where .... > > I made a page with 2 columns, > on the left a vertical menu and > on the center and right the contents to show. > > The contents to be shown are paragraphs of a book. > > The left menu shows the chapters of the book, > and the submenus shows the paragraph titles. > > Now I wanted to use a harmonica menu for the left menu, > so I found a JQuery harmonica menu, > which works quit nice, > the chapter on which you click is expanded and all other chapters are > closed. > As long as you don't attach a link to the paragraph menu items, it really > looks very nice. > > This is the main JQuery script > <script src="static/jquery.js"></script> > <script> > $(document).ready(function(){ > $("dd:not(:first)").hide(); > $("dt a").click(function(){ > $("dd:visible").slideUp("slow"); > $(this).parent().next().slideDown("slow"); > return false; > }); > }); > </script> > > But how should that work with web2py, > if the whole page is refreshed each load of a new paragraph. > A load also rebuilds the harmonica menu. > > Now I could think of 2 solutions, and I'm not sure which is the best, or > if they are all bad. > > first solution: > load the new paragraph in an I-frame (or something like that, I'm not an > expert), > but I think that will be destroy a lot of power of web2py. > > second solution: > dont't use the jquery harmonica menu at all, > but let the controller in web2py build a specific menu + (submenus for 1 > menu item) for each > new page. > > Another side effect is that reloading a new chapter gives a lot of > flicker, because although the > major part of the screen is (semi-) static, > each new call the whole page is refreshed. > How in general can you mainitain those static parts with web2py ? > > Sorry for the long story, > but I've the feeling I'm missing something very essential in building > web2py pages. > > thanks, > Stef Mientki > > > > > >
