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 > > > > > layout.html at the root. Perhaps a "news" area and a "calandar" area > > > > > in addition to the main body, for example. > > > > > > Each functional block could be represented by a file such as > > > > > "news.html" and "calandar.html" included into layout.html. The > > > > > controller for each would then extend its own html file instead of the > > > > > top-level "layout.html" file. > > > > > > Is there a still better way to organize a busy site? > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
