On Nov 19, 2005, at 6:12 PM, Shalabh Chaturvedi wrote:

> Your scheme looks intersting. I'd like to see an example of how a page
> is defined, for example what would go inside the method for a page:
>
> def somepage [html] ():
>     "what goes here"
>
> Or would you construct the page_info object somehow and then call a
> render() method?
>
> I think it would be useful to keep the usage simple and close to
> standard Quixote as possible. I can also see utility in collecting the
> js and css references at the top and I'm all for standardization of
> this mechanism.

I'd like to clarify what is meant by a "somepage template" here, as in
practice this is not always cut and dry... what I mean is that a
"quixote export", i.e. a published URL, is essentially independent of
the one or the many "quixote views" that may be employed to serve a
request to such a URL. There may be many factors at play here... that
may be application specific, e.g. is the user logged in? If so, maybe I
wish to not redirect the URL, but just render it as a login page. Or,
the user may well be logged in but for this particular URL he may
anyway not have access rights (maybe requires additional paid
subscription) and we may in this case wish to present this information
plus means of how to make the payment. Or, an error occurred during the
execution, and we want to return some friendly info, again without
redirecting, as automatically changing URLs can be disorienting for the
user...

So, maybe it boils down to how you draw your mvc dividing lines... but
often those lines are very arbitrary, and I think it is helpful to
think of the URL handler as independent of the view(s). As an aside, I
like to think of multiple controllers, one that is UI-agnostic, i.e.
knows nothing of the rendering context (this encroaches therefore on
the model), and a rendering controller that therefore implements the
logic necessary for a particular rendering without necessarily being
responsible for the visualizing part in any way.

So, to answer your question, I will rename "somepage" to "someexport",
and add a "render" dispatcher.... these may of course be defined on the
same Directory instance, but not necessarily. Anyhow, let's assume they
are just simple functions.

def someexport ():
     # select appropriate view... if not logged in, no access privilege,
     # unpaid, etc, then just call (or raise a specific exception) the
     # appropriate view
     # Assuming all is OK, we then proceed with the normal case:
     view_info = { ... } # get an "initialized" copy....
     contents = []
     # go thru specific page logic, maybe adjusting view_info,
     # appending content pieces to contents list, other app-specific
args,
     # as necessary, then returned the filled out template
     return render (view_info, *contents)

def render(view_info, *contents, **kwargs):
     if view_info['category'] == 'std':
         return render_std(view_info, *contents, **kwargs):
     # etc...
     # this is only one simple way to select the appropriate renderer

def render_std [html] (view_info, *contents, **kwargs):
     std_header(view_info, *contents, **kwargs)
     std_content(view_info, contents, kwargs)
     std_footer(view_info, contents, kwargs)


Moving out the rendering functionality will give some interesting
advantages, such as possibility to dynamically select a skin... or to
return the one most appropriate fro a given device, and so on. This is
of course in addition to the advantage of maximizing the amount of
repetitive plumbing that can be factored out, as well as the systematic
placing of all js/css in the head. (Note that I changed the name of
page_info, that I previously used, to view_info, as it seems more
appropriate.)

Handling the rendering in this way also opens up an easy way to
integrate complex sub-page components, that need to interact (js+css)
between themselves on the page... as these will also participate in
building up the view_info and contents objects.

As I mentioned earlier, pasting my current code is not a good idea, as
it is too intertwined with app-specific stuff. But, I'll be very happy
to participate in the evolution of a add-on module that meets common
requirements.

mario