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
-~----------~----~----~----~------~----~------~--~---
