Newbie questions about Pliant

Newbie questions about Pliant

developing website

how can i factor out common style definitions into a separate file?
Message posted by maybe Boris Reitman on 2005/04/23 17:17:07
I have developed a site with bunch of pages, each having the same copy
of style definitions at the top.  I would like to factor this common 
code into one place. I don't want to clone the whole default.style,
I just want to add my tags to the set of known tags.  
Do I incorporate a .style file with my custom tags into a .page, 
with a "module" command ?

I looked at some existing code, particularly forum.pli and forum/display.pli and I see that 
the common code is written in the "method" form.  When doing this way, how do I handle
optional attributes that can be given to tags ?  Is there a way I can factor 
out style deinitions in their tag_prototype form ?  I like that syntax.

Also, if I change a .page file then I can refresh a page and see what changed.
But if I would factor out some code into a common file .pli, 
then I have to restart the server everytime I change something.  
I use /pliant/fullpliant to restart the server -- which makes it compile everything
everytime.  It is very slow.  Is there any way to tell pliant webserver
to clear the cache for just that one .pli file that I am editting, so that I don't 
have to restart the server everytime ?

Also, I noticed that in default.style the definitions of tags are given
in a style_setup block, while in a .page they are given in a style block.
what is the difference between the two.

Basically -- my question is -- how do I develop a modern 
website with more than one page.  How do I organize the common code.
How would I make a common header and footer to all my pages ?
And how would I develop the site incrementally, restarting the webserver
after every change in a .pli file seems not practical.

Thanks,
Boris
Message posted by hubert.tonneau on 2005/04/24 09:04:14
Here is the general answer/introduction. Then there will be a second answer
targerting more specificaly your questions.

When you write a web site, in Pliant or not, there are several ways to deal
with the semantic -> rendering transform. 
By 'semantic' I mean an encoding of the output tighly linked to your application.
You could think as XML.
By 'rendering' I mean an encoding that some rendering engine understands.
You could think as HTML.


LEVEL 0: inline translation

You do manualy the translation in you .page through instructions like:
html "<h1>My title</h1>[lf]"

The problem here is that:
1) Good looking tend to require quite a lot of code, so you will end to cut
   and past many lines so that your final application will be fat and
   very hard to read (to many prensentation related instruction making it
   hard to read application related ones).
2) HTML is not a reliable standard, so you can't assume futur browsers will
   handle properly you code, so you might have to look everywhere for
   changes


LEVEL 1: method

You define a .style with something like

method p title t
  arg_rw HtmlPage p ; arg Str t
  p html "<h1>"+html_encode:t+"</h1>[lf]"

Then in your .page:
module "xxx.style"
title "My title"

Another solution is to use a meta instead of a method:
meta '. title' e
  if e:size>=2 and (e:0 cast HtmlPage) and (e:1 cast Str)
    ...
in order to cope with extra arguments, but the general layout is still the
same.

The problem here is that in the method, you don't receive environment
information.
As an example, in a semantic level sequence such as:
table
  cell header
    text "column title"
it might be necessary for 'text' method to know that it is called from
within a header cell in order to properly translate to rendering language.


LEVEL 1a: indirect method

Same as level 1, but the method which will be called when translating
an instruction can be hooked at run time, so that it makes it easier
to reuse some code (forum or web mail application as an example) and
get a different look from the same .page depending from which web site
it is called.

Also, I call it 1a and not 2 because there are several possible tricks
to get the same result, including compiling the .page several times
or adding some 'if' instructions in the .style module.



LEVEL 2:

The server is storing the set of all parents node of the current
instruction, so that in the translating method of any instruction,
you can check in which environment it is called.
So, in our level 1 sample, you can know if 'text' is called within a
header cell or not.

The problem here is that you still can hardly cope with the case where the
rendering language datas ordering is significantly different from the
semantic datas ordering.
I mean, if your query processes a table, and on the last row, you want to
provide the sum for each column, then it's ok. But if you want to provide
the sum at the top of the column, then you have some trouble.


LEVEL 3: unrestricted translation

Your application stores it's output in an XML like format, then another piece
of your code translate it to HTML.
It has maximum flexibility because the translation code can scan the all code
to check for some properties and translate accordingly.

The problem is with performances. First, you have to store the intermediate
semantic encoding, and it can take quite a lot of room on some large queries.
Second and most important: you will not be abble to start sending the answer
to the client until the server finished to process the query, so latency will
be worse.


SO WHAT ?

Dirty programmers will tend to use level 0, but it just shows how poor they
are.

Now, if HTML/CSS was working great, the recommended level would be 1.
So, if I say it the other way round: if your 'good looking' needs can cope
with HTML/CSS constrains, the recommended level is 1.

So, why is Pliant providing level 2 ?
One of the huge problem with HTML/CSS is that it lacks remote fonts.
Most sites will provide server side rendering for titles in order to get
unresticted fonts access, and if you want et go behond HTML/CCS, knowing
the environment makes it much easier.

CSS is what I call level 2. So, either you use level 1 on the server side
and rely on level 2 on the browser side, or use level 2 on the server side.
In orther words, Pliant level 2 is just server side CSS.

Now, Why is Pliant not providing level 3 ?
You can implement a .style that would store the all ouput, and process it
at end, but since it has serious impact on performances, I tend to prefer
restricting good looking capabilities of my web sites to what level 2
can handle.

As a sumary, Pliant HTTP server is providing the most flexible level
with low impact on performances so it should be ok right out of the box
for most applications. Anyway, keep in mind that if you have some non standard
constrains (either requires benchmark class performances or crazy looking)
then all of this may not apply anymore since the tool you need must have
been designed facing you constrain right from the beginning.


HOW IS ALL OF THIS IMPLEMENTED IN PLIANT ?

In order to use level 1, you just use plain 'method' or 'meta' Pliant
instructions.

In order to use level 2, you use 'tag_prototype' and 'tag_html' 'tag_html_open'
and 'tag_html_close' instructions.

Message posted by hubert.tonneau on 2005/04/24 09:45:50
> I just want to add my tags to the set of known tags.

Define a .style with you extra tags:

public

  tag_prototype mytag1
    ...

  tag_prototype mytag2
    body


style_setup
  
  tag_html mytag1
    ....
 
  tag_html_open mytag2
    ....
  tag_html_close mytag2
    ....

Then at the head of each of your .page use something like:

style "mystyle.style" # use 'style', not 'module' instruction

> I looked at some existing code, particularly forum.pli and forum/display.pli and I see that 
> the common code is written in the "method" form.

The fact that some of the code I provide such as the forum be implemented
as 'method' in .pli modules instead of plain .page is to enable to have
a single /pliant/browser/virtual_tree.page easy to customize or replace
dispatcher.
Don't do that for your application.

> When doing this way, how do I handle optional attributes that can be given to tags ?

You are talking of two different notions.
In the forum application, I use 'method' as a way to export some functions
that will later be called from a real .page, and as I stated, it is not
recommended unless you have special reason for doing so.

Now, about passing extra arguments to your own tags, this is one reason I
designed level 2 (see previous long answer) so that it is possible to have
these without dealing with 'meta' instruction.

> Is there a way I can factor out style deinitions in their tag_prototype form ?

I don't understand what you mean by 'factor'

> Also, if I change a .page file then I can refresh a page and see what changed.
> But if I would factor out some code into a common file .pli, 
> then I have to restart the server everytime I change something.

Yes you do.
I could allow some .style to be recompiled on the fly ... provided they only
do only basic things from the Pliant compiler engine point of view. Most of
them tend not to satisfy this constrain, so at some point you would start to
notice that Pliant gets unreliable until you restart it.
In very fiew words, this is behond what Pliant compiler engine can do.

> I use /pliant/fullpliant to restart the server -- which makes it compile everything
> everytime.  It is very slow.

First of all, you don't need to start the HTTP server in order to test that
your .style is basically ok (compiles).
Use the command line for that.

If you have a slow machine, you can use the 'precompile' option in order to
make the part you are not modifying not be recompile each time:

pliant 'precompile /binary/http.dump module /pliant/install/minimal.pli module /pliant/protocol/http/style/default.style' module /pliant/protocol/http/server.pli command http_server

> Also, I noticed that in default.style the definitions of tags are given
> in a style_setup block, while in a .page they are given in a style block.
> what is the difference between the two.

A .page is compiled to a Pliant function,
the 'style' instruction enables to provide a second function that will be
executed earlier than the main one, so that it can changes some parameters
before the Pliant machinery starts to output the header of the HTML page.

The 'style_setup' bloc provides the initialisation code for the style.

So, with a bit of over simplification, they are the same, but they work
on different Pliant objects (a .page is a function, a .style is a module)

> How do I organize the common code.

It depends.
If it is some styling code, then you use a .style
If it is some application code, the you create some .pli and use some 'method'
just as in the sample forum application.

> How would I make a common header and footer to all my pages ?

In the 'style_setup' section of your .style, use
  tag_html page_header
    write "<-- my header -->[lf]"
    ...
  tag_html page_footer
    write "<-- my footer -->[lf]"
    ...
Message posted by michel on 2005/04/24 14:45:44
You can see an example of modest customization on :
http://pliant.gassendi.asso.fr/
you can look at all .page files

Michel
Message posted by maybe Boris Reitman on 2005/05/03 03:36:51
Thanks! The website on which I am working is 
http://sendflowers.tv

How can I enable to view the source on select pages ? 
Message posted by michel on 2005/05/03 06:28:24
It depends on what file source you want to show and what you don't.
If a great part of .page can be seen you just have to give in anonymous definition
"browse_source" right, and to place the forbiden datas in .pli files, in the data base 
or in the tree out of Pliant tree (and don't give the rights "browse_data" and
"browse_system_file" to anonymous).

With this organisation everybody can see the .page source, with syntaxic coloration,
 by replacing "mypage.html" by "mypage.page"
  
Message posted by michel on 2005/05/03 13:10:48
If you are interested by the organisation of my site, you can first have a look at
http://pliant.gassendi.asso.fr/home/essais/aspic.pdf which was presented in ASPIC 2004
and try to be in english or 
http://pliant.gassendi.asso.fr/home/essais/saintry.pdf
which is more accurate but is in french.

If you want to have a look at the sources of all the files in the pliant tree and at
the settings of the servers, please confirm your e-mail; I'll open an account for you
and send by mail a login and a pwd.
Message posted by maybe Boris Reitman on 2006/06/07 22:36:03
I am running two different sites within the same instance of a http server.
Each website uses a custom style.  Each style implements a tag of the same name,
with different arguments or in a different way. Should I expect to have an error ?
I believe thats what I am observing now.
Message posted by maybe Boris Reitman on 2006/07/31 08:09:04
I have a virtual_tree.page which emulates some pages on my website.
I would like it to use a certain custom style.  The trouble is that if I load
style declarations in the top of the virtual_tree file, it is applied for /common/ 
urls too.  My custom style adds headers and footers to html pages, so when this is added 
to images in /common/ it breaks the image.

In other words, my custom style does this:
------------8<----------------
style_setup
  var Str a b
  a := slurp_text_file "/sites/roses4you.com/head.html"
  b := "<META NAME=[dq]keywords[dq] CONTENT=[dq]" + get_keywords:"/sites/roses4y
ou.com/keywords.txt" + "[dq]>[lf]"
  push common head a+b
------------->8----------------

and if I include it in virtual_tree.page, it breaks all /common/ 
urls (images and javascript).  Can I modify, perhaps, my common style 
to not to do "push common head a+b" if the context is /common/ urls ?

Thanks,
Boris
Message posted by hubert.tonneau on 2006/07/31 13:10:05
In you 'style_setup' code, you can check 'http_request:path'