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 Have fun! On 3 February 2011 00:43, Stef Mientki <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 > > > > > >
