I have looked at the jpolite for a possible portal. But I notice a odd effect. If you click on a tab to change the view for about 2 seconds the contents seem to 'shake' then lock on. Like the content is trying to sync to a grid. Anybody else notice this?
On Jun 5, 9:42 pm, mdipierro <[email protected]> wrote: > I do not know if you have had time to look into > > http://www.web2py.com/jpolite > > which is a heavily modified version of jpolite adapted to web2py (I am > working with the author of jpolite on this). > > Each web2py action is mapped into a box by the file static/ > modules.js. > If SQLFORM(...,_class='ajaxform1') the forms stay in the box, else the > form reloads the entire page. > > I am also adding the feature for boxes to interact with each other so > that server-side events in one box can trigger client-side events in > another box. This is amost done. As usual, the main problem is > documentation but I will have some time in July to dedicate to this > and hopefully finish it. > > Massimo > > On Jun 5, 7:17 pm, eddie <[email protected]> wrote: > > > Fantastic post, Ted. Much appreciated. > > > Eddie > > > On Jun 6, 2:29 am, Ted G <[email protected]> wrote: > > > > I think while the thread topic asks about handling "rich sites", the > > > discussion loosely associates "rich" with "modular", which may be > > > misleading. > > > > In a modular design under web2py you may have your sidebar defined in > > > a separate html file that you are incorporating as part of your index > > > html file, allowing you to re-use that sidebar html in another > > > controller's page. Although your html is modular, the controller will > > > still need to provide all of the data that the aggregated html files > > > require (in your case default/index. You could go ahead and create a > > > separate sidebar function that your index controller calls to return > > > the data set required for the sidebar so that both the sidebar html > > > and it's data are modular. This would allow other controllers to > > > easily re-use the sidebar html and data. > > > > For example: > > > > # a function declared in a file that can be included in your > > > controller or put it in db.py > > > # that returns the dataset needed by the sidebar > > > def foo(): > > > foo=db(db.footable.id>0).select() > > > return foo > > > > # your controller responsible for the main page > > > def index(): > > > # call function to retrieve the sidebar data set > > > foobar = foobar() > > > > # retrieve data needed for the rest of this page > > > some_db_records=db(db.table1.id>0).select() > > > > # pass sidebar and index page data to index.html > > > return dict(foobar=foobar,some_db_records=some_db_records) > > > > foo.html > > > ====== > > > <!-- html snippet to render the sidebar data as a list --> > > > <ul> > > > {{for foo in foobar}} > > > <li>{{=foo.data}}</li> > > > {{pass}} > > > </ul> > > > > index.html (not complete just relevant divs to this discussion) > > > ============= > > > ... > > > > <div id="sidebar"> > > > {{include 'foo.html'}} > > > </div> > > > > <div id="main_content"> > > > <!-- This is the main content area where may display some_db_records -- > > > > </div> > > > > ... > > > > While the above allows you to create a very modular design with re- > > > useable components, I would not call it "rich" as I understand the use > > > of that term within the web environment. If data in your sidebar > > > changes, you must still retrieve all data at the controller and > > > recreate the entire index page to resend the browser (not very > > > efficient) > > > > To migrate your page to rich from modular would require some minor > > > changes to the controller and html to support ajax functionality. In > > > the above example, you would turn the foo function into it's own > > > controller, allowing it to return just the html required for itself > > > via its already existing foo.html (which doesn't have to change). > > > > def foo(): > > > foo=db(db.footable.id>0).select() > > > return dict(foo=foo) > > > > then simplify your index controller > > > > def index(): > > > # retrieve data needed for the main content area of the page > > > some_db_records=db(db.table1.id>0).select() > > > l > > > return dict(some_db_records=some_db_records) > > > > Your index.html is then modified to incorporate some ajax (in this > > > case using jQuery, which is included in web2py, to load the sidebar as > > > using a separate ajax call). > > > > index.html (not complete just relevant divs to this discussion) > > > ============= > > > ... > > > <script> > > > $(document).ready(function() { > > > $("#sidebar").load({{=URL(r=request,f="foo")}}) > > > } > > > </script> > > > > <div id="sidebar"> > > > <!-- this div will be loaded with content via ajax in document.ready > > > --> > > > </div> > > > > <div id="main_content"> > > > <!-- This is the main content area where may display some_db_records -- > > > > </div> > > > > The above is a very simplified example of a "rich" page. In this case, > > > you would probably have some other ajax functionality that might cause > > > a reload of sidebar, without having to reload the entire index page, > > > which is where the richness would come in. > > > > The nice thing about the above is that if you already have a modular > > > design to your html pages and controllers/data, migrating to an rich > > > ajax implementation is much easier. The benefit is that you can see in > > > the above example how index and foo are now much more loosely coupled > > > and thus more re-useable. In the modular design, index still needed to > > > know about foo at the controller level as it had to retrieve it's data > > > on behalf of foo.html which was included in index.html. > > > > In the ajax design the index controller knows nothing about foo. The > > > only coupling comes in index.html in the javascript which "glues" > > > together foo and index, so we have pushed coupling out to the view > > > layer of our MVC framework. > > > > Ted > > > > On Jun 5, 4:24 am, eddie <[email protected]> wrote: > > > > > And related to this topic, the scenario described here: > > > > >http://groups.google.com/group/web2py/browse_thread/thread/2378eef8fb... > > > > > could be used in solving the "rich site" issue, but relies on the > > > > applets being available as static html, that could be automatically > > > > built in a background process. > > > > > On Jun 5, 8:30 pm, eddie <[email protected]> wrote: > > > > > > I'm just arriving at this point in my first web2py project, and I'm > > > > > still a bit unclear what the result of this discussion is. I would > > > > > just like to clarify what is supported in web2py. > > > > > > The sample scenario is this. > > > > > > In view 'default/index.html': > > > > > > * This might be the 'front page' of a site > > > > > * You include the line {{extend 'foo/bar.html'}} > > > > > > In view 'foo/bar.html': > > > > > > * This might implement a sidebar (or some other common 'applet') > > > > > * You include the line {{=some_db_records}} > > > > > * You have an {{include}} in the file > > > > > > When you hit the URL 'appname/default/index': > > > > > > * It is the responsibility of the function index() in the controller > > > > > file default.py to return an item called 'some_db_records' > > > > > * The function bar() in controller foo.py is not called > > > > > > Is this correct? > > > > > > Thanks guys, I just wanted to be sure I interpreted these posts > > > > > correctly. > > > > > > Eddie > > > > > > On May 7, 2:57 am, Ted G <[email protected]> wrote: > > > > > > > If you do a search onjDivyou will find a few recent threads > > > > > > discussing this topic (related to the example link provided by > > > > > > Massimo). I've been heading down this road myself, creating a site > > > > > > where site pages are simply container based layouts containing re- > > > > > > useable "applets". The pattern I've found that works so far is as > > > > > > follows: > > > > > > > layout.html - contains common style sheets, javascript and layout > > > > > > containers common across all pages (eg. Header, Menu, Body, Footer). > > > > > > Provides an {{include}} in the body area. > > > > > > > mypage.html - contains specific styles, javascript and layout > > > > > > containers for the body area of a specific page that contains a > > > > > > number > > > > > > of applets. Basically the "glue" that coordinates the interaction of > > > > > > the various applets on the page. Within the layout defined in this > > > > > > page are your applets {{=applet1}} , {{=applet2}}, etc. > > > > > > > The controller action for the mypage.html view creates applet1, > > > > > > applet2, etc. asjDiv'sand returns them to the view via dict > > > > > > (applet1=applet1, applet2=applet2, ...) > > > > > > > The individual applets actions/views may be in the same controller > > > > > > as > > > > > > mypage or in different controllers. Ideally, yourapplet'sview would > > > > > > contain only that html specific to thatapplet'slayout so that it is > > > > > > easily re-used. Since theappletwill be able to utilize the > > > > > > javascript and css in layout.html and mypage.html you can rely on > > > > > > those layout pages to provide the CSS styling for theappletso that > > > > > > it is easier to make site wide style changes later. > > > > > > > Making use of a CSS framework can help with consistent site wide > > > > > > layout. I've used the blueprint css framework successfully with > > > > > > web2py. CSS frameworks are not for everyone, but for CSS challenged > > > > > > indviduals like myself, they are a real time saver. > > > > > > > Ted > > > > > > > On May 6, 3:15 am, Joe Barnhart <[email protected]> wrote: > > > > > > > > I've been pondering the best way to create sites with rich pages > > > > > > > that > > > > > > > contain lots of "applets" or "tasklets". It seems limiting to > > > > > > > have > > > > > > > the entire page tied to a single Python function. Maintaining the > > > > > > > site could be problematic if everything funnels through one > > > > > > > "controller" function. > > > > > > > > Then I wondered about the structure of the layout files. I like > > > > > > > the > > > > > > > "extend" and "include" functionality. I imagine I could create a > > > > > > > tree > > > > > > > of html files --- one for eachappletdiv, for example, with > > ... > > read more » --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "web2py Web Framework" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~----------~----~----~----~------~----~------~--~---
