Newbie questions about Pliant

Newbie questions about Pliant

need advice for plan of attack

Need to make changes on my pliant-based site,
but don't know which way is faster.
Message posted by maybe Boris Reitman on 2007/10/29 14:59:02
I'd like to implement the following feature:

User types /x/y/z.html
and based on the path he gets a particular generated page.  The page is an HTML 
template with certain variables replaced. (Simple header-footer is not sufficient).

Example:  /flowers/birthday/page_2.html

I currently do it with apache url_rewrite to send user to pliant page:
 
   landing.html?arg1=x&arg2=y&arg3=z

I am not using pliant's virtual page because it doesn't work in a "proxy" mode,
(see my post in the talk forum: http://old.fullpliant.org/pliant/browse/forum/pliant.talk/07BM39411/)

But the apache way only works if pages have no pliant buttons, because after
the button is pressed, user is sent to url landing.html?button....
instead of /x/y/z.html?button....

Also, because I'm not using a simple header-footer, but a template, only "reload_page"
action can be used at the end of button handler (instead of a call to any other
HtmlPage method.).

With the new pliant UI design there will be no problem with button handling,
but it is not clear how I can apply an HTML template to the output 
(discussed in separate thread: http://old.fullpliant.org/pliant/browse/forum/pliant.talk/07DZMPP11/).

The feature needs to be launched ASAP on a live production system.
I am now at a cross-roads, what to do to get where I want faster. 

- Get the new UI to work and integrate it with my website. This would involve:
  - arranging /x/y/z.html to be a virtual url 
    that maps to a pliant page (either by apache url_rewrite or all in pliant)

    if done all in pliant, then ui_path needs to be flexible to allow using 
    regexes,    ui_path /regex/regex/regex.html declaration,
    because the pages represent content in database which change and can't be 
    hardcoded. 
   
  - rendering html template with some tags substituted 
   
or use old http server with reload_page and:

  - Fix old http server by either somehow passing /x/y/z.html to button handler,
    so that after button is pressed i get url /x/y/z.html?button...
  or
  - Fix virtual_page on the old http_server to behave like a proxy.
  or,
  - For every possible /x/y/z.html make a symlink to point to landing.html
    and get apache to url_rewrite to tell pliant access that symlink 
    (no code changes are needed).  This will require *a lot* of symlinks.

My question is: which way should I go to get things working asap, except the symlink method ?
Boris
Message posted by maybe Hubert Tonneau on 2007/11/04 10:08:01
You are just entering programming real life: who to make an existing application
evolve nicely.

I cannot give you usable advises about your perticular case because often the
answer is in the details and I don't have studied the details of your
application.

Now, on the general design, my point of view is: with the new UI, we are
exected to be more on the XML word.
The server SHOULD NOT DO ANY REWRITE, and the reason is that we don't want to
do tricks on the server,
so the application on the server should be abble to freely create a new keyword,
let's say 'foo' which is not known by the UI client, and just tel to the UI
client: if you don't know how to handle a subtree starting with a 'foo' node,
ask aserver.adomain.org
Now the UI client should connect to the specified server OR ANY OTHER ONE THAT
IS KNOWN FOR UNDERSTANDING 'foo', provide it the subtree and get back the
translated result.

The only LITTLE problem about this design is that I have not implemented it yet
in the UI client because I had no need for it yet.

The key advantage of the proposed design is that it truely means server side
plugins. Through moving to another server than the specified one, you just
increase the bandwidth and reduce the latency.

Last point is: the UI client is the HTTP proxy, so when I say rewrites should
be handled on UI client it means rewrites should be handled on HTTP proxy,
not on application server. The design change is transparent for a standard
web browser.