XAO::DO::Web::Page - core object of XAO::Web rendering system
Outside web environment:
my $page=XAO::Objects->new(objname => 'Page'); my $date=$page->expand(template => '<%Date%>');
Inside XAO::Web template:
<%Page path="/bits/some-path" ARG={<%SomeObject/f%>}%>
As XAO::DO::Web::Page object (from now on just Page displayable object) is the core object for XAO::Web web rendering engine we will start with basics of how it works.
The goal of XAO::Web rendering engine is to produce HTML data file that can be understood by browser and displayed to a user. It will usually use database tables, templates and various displayable objects to achieve that.
Every time a page is requested in someone's web browser a XAO::Web handler gets executed, prepares site configuration, opens database connection, determines what would be start object and/or start path and does a lot of other useful things. If you have not read about it yet it is suggested to do so -- see XAO::Web::Intro and XAO::Web.
Although XAO::Web handler can call arbitrary object with arbitrary arguments to produce an HTML page we will assume the simplest scenario of calling Page object with just one argument -- path to an HTML file template for simplicity (another way to pass some template to a Page object is to pass argument named "template" with the template text as the value). This is the default behavior of XAO::Web handler if you do not override it in configuration.
Let's say user asked for http://oursite.com/ and XAO::Web translated that into the call to Page's display method with "path" argument set to "/index.html". All template paths are treated relative to "templates" directory in site directory or to system-wide "templates" directory if site-specific template does not exist. Suppose templates/index.html file in our site's home directory contains the following:
Hello, World!
As there are no special symbols in that template Page's display method will return exactly that text without any changes (it will also cache pre-parsed template for re-use under mod_perl, but this is irrelevant for now).
Now let's move to a more complex example -- suppose we want some kind of header and footer around our text:
<%Page path="/bits/header-template"%> Hello, World! <%Page path="/bits/footer-template"%>
Now, Page's parser sees reference to other items in that template - these things, surrounded by <% %> signs. What it does is the following.
First it checks if there is an argument given to original Page's display() method named 'Page' (case sensitive). In our case there is no such argument present.
Then, as nor such static argument is found, it attempts to load an object named 'Page' and pass whatever arguments given to that object's display method.
NOTE: it is recommended to name static arguments in all-lowercase (for standard parameters accepted by an object) or all-uppercase (for parameters that are to be included into template literally) letters to distinguish them from object names where only the first letter of every word is capitalized.
In our case Page's parser will create yet another instance of Page displayable object and pass argument "path" with value "/bits/header-template". That will include the content of templates/bits/header-template file into the output. So, if the content of /bits/header-template file is:
<HTML><BODY BGCOLOR="#FFFFFF">
And the content of /bits/footer-template is:
</BODY></HTML>
Then the output produced by the original Page's display would be:
<HTML><BODY BGCOLOR="#FFFFFF"> Hello, World! </BODY></HTML>
For actual site you might opt to use specific objects for header and footer (see XAO::DO::Web::Header and XAO::DO::Web::Footer):
<%Header title="My first XAO::Web page"%> Hello, World! <%Footer%>
Page's parser is not limited to only these simple cases, you can embed references to variables and objects almost everywhere. In the following example Utility object (see XAO::DO::Web::Utility) is used to build complete link to a specific page:
<A HREF="<%Utility mode="base-url"%>/somepage.html">blah blah blah</A>
If current (configured or guessed) site URL is "http://demosite.com/" this template would be translated into:
<A HREF="http://demosite.com/somepage.html">blah blah blah</A>
Even more interesting is that you can use embedding to construct arguments for embedded objects:
<%Date gmtime={<%CgiParam param="shippingtime" default="0"%>}%>
If your page was called with "shippingtime=984695182" argument in the query then this code would expand to (in PST timezone):
Thu Mar 15 14:26:22 2001
As you probably noticed, in the above example argument value was in curly brackets instead of quotes. Here are the options for passing values for objects' arguments:
You can surround value with double quotes: name="value". This is recommended for short strings that do not include any " characters.
You can surround value with matching curly brackets. Curly brackets inside are allowed and counted so that these expansions would work:
name={Some text with " symbols} name={Multiple Lines} name={something <%Foo bar={test}%> alsdj}
The interim brackets in the last example would be left untouched by the parser. Although this example won't work because of unmatched brackets:
name={single { inside}
See below for various ways to include special symbols inside of arguments.
Just like for HTML files if the value does not include any spaces or special symbols quotes can be left out:
number=123
But it is not recommended to use that method and it is not guaranteed that this will remain legal in future versions. Kept mostly for compatibility with already deployed code.
Sometimes it is necessary to include various special symbols into argument values. This can be done in the same way you would embed special symbols into HTML tags arguments:
By using &tag; construct, where tag could be "quot", "lt", "gt" and "amp" for double quote, left angle bracket, right angle bracket and ampersand respectfully.
By using &#NNN; construct where NNN is the decimal code for the corresponding symbol. For example left curly bracket could be encoded as { and right curly bracket as }. The above example should be re-written as follows to make it legal:
name={single { inside}
Arguments can include as many level of embedding as you like, but you must remember:
That all embedded arguments are expanded from the deepest level up to the top before executing main object.
That undefined references to either non-existing object or non-existing variable produce a run-time error and the page is not shown.
All embedded arguments are processed in the same arguments space that the template one level up from them.
As a test of how you understood everything above please attempt to predict what would be printed by the following example (after reading XAO::DO::Web::SetArg or guessing its meaning). The answer is about one page down, at the end of description chapter.
<%SetArg name="V1" value="{}"%> <%SetArg name="V2" value={""}%> <%Page template={<%V1%><%V2%> <%Page template={<%SetArg name="V2" value="[]" override%><%V2%>}%> <%V2%><%V1%>} %>
In most cases it is not recommended to make complex inline templates though, it is usually better to move sub-templates into a separate file and include it by passing path into Page. Usually it is also more time efficient because templates with known paths are cached in parsed state first time they used while inlined templates are parsed every time.
It is usually good idea to make templates as simple as possible and move most of the logic inside of objects. To comment what you're doing in various parts of template you can use normal HTML-style comments. They are removed from the output completely, so you can include any amounts of text inside of comments -- it won't impact the size of final HTML file. Here is an example:
<!-- Header section --> <%Header title="demosite.com"%> <%Page path="/bits/menu"%> <!-- Main part --> <%Page path="/bits/body"%> <!-- Footer --> <%Footer%>
One exception is JavaScript code which is usually put into comments. The parser would NOT remove comments if open comment is <!--//. Here is an example of JavaScript code:
<SCRIPT LANGUAGE="JAVASCRIPT"><!--// function foo () { alert("bar"); } //--> </SCRIPT>
If you do not like something in the parser behavior you can define site-specific Page object and refine or replace any methods of system Page object. Your new object would then be used by all system and site-specific objects for your site and won't impact any other sites installed on the same host. But this is mentioned here merely as a theoretical possibility, not as a good thing to do.
The output of the test above would be:
{}"" [] ""{}
In fact first two SetArg's would add two empty lines in front because they have carriage returns after them, but this is only significant if your HTML code is space-sensitive.
Publicly accessible methods of Page (and therefor of all objects derived from Page unless overwritten) are:
Displays given template to the current output buffer. The system uses buffers to collect all text displayed by various objects in a rather optimal way using XAO::PageSupport (see XAO::PageSupport) module. In XAO::Web handler the global buffer is initialized and after all displayable objects have worked their way it retrieves whatever was accumulated in that buffer and displays it.
This way you do not have to think about where your output goes as long as you do not "print" anything by yourself - you should always call either display() or textout() to print any piece of text.
Display() accepts the following arguments:
Gives Page a path to the template that should be processed and displayed.
Provides Page with the actual template text.
If set it does not parse template, just displays it literally.
Any other argument given is passed into template unmodified as a variable. Remember that it is recommended to pass variables using all-capital names for better visual recognition.
Example:
$obj->display(path => "/bits/left-menu", ITEM => "main");
For security reasons is also recommended to put all sub-templates into /bits/ directory under templates tree or into "bits" subdirectory of some tree inside of templates (like /admin/bits/admin-menu). Such templates cannot be displayed from XAO::Web handler by passing their path in URL.
Returns a string corresponding to the expanded template. Accepts exactly the same arguments as display(). Here is an example:
my $str=$obj->expand(template => '<%Date%>');
Creates new displayable object correctly tied to the current one. You should always get a reference to a displayable object by calling this method, not by using XAO::Objects' new() method. Currently most of the objects would work fine even if you do not, but this is not guaranteed.
Possible arguments are (the same as for XAO::Objects' new method):
The name of an object you want to have an instance of. Default is 'Page'. All objects are assumed to be in XAO::DO::Web namespace, prepending them with 'Web::' is optional.
If present then site specific object is ignored and system object is loaded.
Example of getting Page object:
sub display ($%) { my $self=shift; my $obj=$self->object; $obj->display(template => '<%Date%>'); }
Getting FilloutForm object:
sub display ($%) { my $self=shift; my $ff=$self->object(objname => 'FilloutForm'); $ff->setup(...); ... }
Object() method always returns object reference or throws an exception -- meaning that under normal circumstances you do not need to worry about returned object correctness. If you get past the call to object() method then you have valid object reference on hands.
Displays a piece of text literally, without any changes.
It used to be called as textout(text => "text") which is still supported for compatibility, but is not recommended any more. Call it with single argument -- text to be displayed.
$obj->textout("Text to be displayed");
This method is the only place where text is actually gets displayed. You can override it if you really need some other output strategy for you object. Although it is not recommended to do so.
Displays some text and stops processing templates on all levels. No more objects should be called in this session and no more text should be printed.
Used in Redirect object to break execution immediately for example.
Accepts the same arguments as textout() method.
Returns current database handler or throws an error if it is not available.
sub display ($%) my $self=shift; my $dbh=$self->dbh; # if you got this far - you have valid DB handler on hands }
Returns current object database handler or throws an error if it is not available.
sub display ($%) { my $self=shift; my $odb=$self->odb; # ... if you got this far - you have valid DB handler on hands }
Returns CGI object reference (see CGI) or throws an error if it is not available.
Returns clipboard object, which inherets XAO::SimpleHash methods. Use this object to pass data between various objects that work together to produce a page. Clipboard is cleaned before starting every new session.
Returns site configuration reference. Be careful with your changes to configuration, try not to change configuration -- use clipboard to pass data between objects. See XAO::Projects for more details.
Returns base_url for secure or normal connection. Depends on parameter "secure" if it is set, or current state if it is not.
Examples:
# Returns secure url in secure mode and normal # url in normal mode. # my $url=$self->base_url; # Return secure url no matter what # my $url=$self->base_url(secure => 1); # Return normal url no matter what # my $url=$self->base_url(secure => 0);
Returns 1 if the current the current connection is a secure one or 0 otherwise.
Returns full URL of current page without parameters. Accepts the same arguments as base_url() method.
This is an utility method that joins together arguments from `newargs' hash with `oldargs' hash (newargs override objargs). Useful to pass arguments to sub-objects.
Does not modify any argument hashes, creates new one instead and returns reference to it.
Example -- setting new path and leaving all other arguments untouched:
sub display ($%) { my $self=shift; my $args=get_args(\@_); my $obj=$self->object; $obj->display($self->merge_args(oldargs => $args, newargs => { path => '/bits/new-path' } )); }
Creates or retrieves a cache for use in various Page based objects. Arguments are directly passed to XAO::Cache's new() method (see XAO::Cache) except for 'name' argument which is used to identify the requested cache.
If a cache with that name was already initialized before it is not re-created, but previously created version is returned instead.
my $cache=$self->cache( name => 'fubar', retrieve => \&real_retrieve, coords => ['foo','bar'], expire => 60 );
Nothing.
Copyright (c) 2000-2002 XAO, Inc.
Andrew Maltsev <am@xao.com>.
Recommended reading: XAO::Web, XAO::Objects, XAO::Projects, XAO::Templates.
To install XAO::Web, copy and paste the appropriate command in to your terminal.
cpanm
cpanm XAO::Web
CPAN shell
perl -MCPAN -e shell install XAO::Web
For more information on module installation, please visit the detailed CPAN module installation guide.