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 <eddie.sh...@gmail.com> wrote:
> Fantastic post, Ted. Much appreciated.
>
> Eddie
>
> On Jun 6, 2:29 am, Ted G <tedg...@gmail.com> 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 <eddie.sh...@gmail.com> 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 <eddie.sh...@gmail.com> 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 <tedg...@gmail.com> 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 <joe.barnh...@gmail.com> 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 web2py@googlegroups.com
To unsubscribe from this group, send email to
web2py+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en
-~----------~----~----~----~------~----~------~--~---
