Perrin Harkins <[EMAIL PROTECTED]> writes:
> WARNING! LONG ANSWER AHEAD!
Thank you for the answer.
Hare is an even longer answer. Short version is:
Your answer made me think. Let me expand on this so that we can
explore strategies for generating data for the response.
I think that you are right that preparing data is data for the
template is a good thing in many cases.
I'm using callbacks for many widgets. Among other things for building
links with query parameters, like
[% jump('Link text', 'path/file', arg=value arg2=value2 ) %]
I have functions for retrieving objects, formatting dates, displaying
form elements (with preselected values dependent on situation) and
other things.
It wouldnt be much better to just have one sub per page. I would
still want to let diffrent parts do diffrent things. I have for a
long time now separated actions from requests. (First make DB updates
based on form data and then let a template display requested
information.)
Authentication handling is a separate part, run before actions and
before template parsing. But I put the authorization requirement in
the template header.
The headers are built based on action result. But it would be nice to
be able to have finer control of caching and even page redirection,
based on the requested page/information.
It would be great to be able to lift page metadata out from the
template. My mod_perl handler maps the URL to the corresponding
template using apaches url to filename translation. But before
parsing the tempalte it does a lot of tings. Authentication,
initialization, setting up DB object, action result object, user
object, session object, picking the best availible language and more.
The mod_perl handler is now application independant. We can have
multipple websites using the same framework without risk of
contaminatiing someone elses namespace.
I have already put in a choice to select a renderer, selected by
.htaccess directives or from the application initialization code.
Instead of TT, the selected renderer will be called for displaying a
result. That would be used for binary data, like images.
Based on your explanation, I'm thinking of expand with yet a few more
things.
- Give the application the choice to override the default methods for
doing everyting it does (finding action handler, URL
transformation, language selection, template selection, header
construction and more)
- Add a default way for preparing data based on requested page, along
with the choice to use another method for this mapping.
- The default data preparateion would look for a pm file in the same
dir and with the same name as the corresponding resolved template
name (except template variations, such as language suffix)
- This page data preparation module could override the application or
framework defaults for data initialization, header construction,
exception handling, authorization and everything else. It could do
custom preparation or just point to another method for handling
that type of template.
- Setup handlers could stack. I'm already have a method for adding
data to be sent to a template, letting diffrent parts adding their
parts. I also let diffrent parts add things to hooks that will be
run later.
Since a page is built up from diffrent parts (boxes or areas on the
page) each part could have it's own setup code. In my thinking, it's
at least in some degree a design and presentation issue if you want to
display some specific box on a page. That box would not be specific
for the requested information but rather somthing that comes along
anyway, like a menu or banner or infobox or anything else.
What part is responsible for deciding on which boxes to present?
I'm thinking of a page like this:
> +-------------------+
> | A ////////////////|
> |//+----------------+
> |//| +---------+ +--+
> |//| | C | |//|
> |//| | +-----+ | |//|
> |//| | | D | | |//|
> |//| | +-----+ | |//|
> |//| | +-----+ | |//|
> |//| | | E | | |//|
> |//| | +-----+ | |//|
> |//| +---------+ |//|
> |//| +-----------+//|
> |//| |/////////// B |
> +--+ +--------------+
A and B is the header / footer part that should be combined to one
component AB. C is the requested information that is presented, in
part by including boxes D and E.
My thinking is that "GET url" is a *request* for a specific *object*.
The presentation of that object is a view. The decision of what view
to return can be decided upon parts from the URL, content negotiation
headers, cookies, session data, user preferences, object, page,
application or system defaults.
In addition of the requsted object, the response also return other
implicitly requested objects. This includes action result notices
("your submitted information has been processed and stored"),
navigation widgets, and other boxes (news box, search box, featured
info, bookmarks, ...).
These indirectly requested objects comes from the site, page, user
prefs, action results, or some combination of this and maby the
primary requested object.
Every part of the response has to be laied out. Should the page have
a contact information box and should it be located in the header,
footer or other place?
The layout of the navigation widgets, page theme and selection of
boxes is often based on site section in the form of box in box in box:
> Site global layout
> +-------------------------+
> | Section layout |
> | +---------------------+ |
> | | Subsection layout | |
> | | +-----------------+ | |
> | | | Page layout | | |
> | | | +-------------+ | | |
> | | | | | | | |
> | | | | | | | |
> | | | | | | | |
> | | | +-------------+ | | |
> | | +-----------------+ | |
> | +---------------------+ |
> +-------------------------+
The site global layout would include boxes to be displayed on all
pages, like a common footer, banner space and a toplevel navigation
for jumping from one site section to another.
The section layout includes section navigation and maby some infoboxes
that should be displayed on all section pages.
Subsection is set by the page and section by subsection. The section
for the page could be mapped to from the page URL or from the page /
object metadata.
Each part will primarly decide on it's own layout. But each part can
also influence the layout, choices of boxes, box content and themes of
other parts.
Example : Let's say that the requested object, primarly displayed in
box C "Page layout", also want to display some extra
information (like a extra menu for accessing diffrent views
or parts of that object). With a simple box in box layout,
this information could only be placed in the inner box. But
maby you rather would want it to dislay in a space formatted
by the section layout (like A, the header).
User preferences, (framework) system, site, section, session, page and
widgets has input for boxes, layout, content and theme to use.
I recently created a web based website creation system aimed for
simple and automised creation of small websites using framing,
navigation and box in box construction. Each inner part inherits the
teme and colours of the outer part. You can specify coulours globaly,
by page or box. Boxes in the box will inherit everything not
overrided. (This was implemented by a combination of heiarcical
datastructure, html tables and automaticly generated stylesheets.)
This is the part there I thougt I would get to a conclusion. I'll
give it a try.. :-)
Steps in cintent generation
---------------------------
Each step vill complement or override any of every configurable part
of the system.
1. System init
2. Request init
3. Application init
4. Session init
5. Handle actions
6. Resolve URL
7. Object (page) init
8. Sections (supersection) init
9. Object boxes
10. Session boxes
11. Section boxes
12. Site boxes
13. Site properties
14. Section properties
15. Page properties
16. Object properties
17. Boxes properties
18. Catch untraped errors
19. Build header
20. Build page (from tree)
21. Cleanup
Something like that... This will get a little bit more complicated
with frames and partly cached or pregenerated pages.
--
/ Jonas - http://jonas.liljegren.org/myself/en/index.html
