[jifty-devel] trimclient branch: toward client side templating

Chia-liang Kao clkao at bestpractical.com
Fri Jul 6 19:42:01 EDT 2007

Hi list,

Some of you might have noticed the trimclient branch on the jifty tree.

Here's a brief description of what it does, the current plan, and
current status.  Please let me know if you are interested in helping.

The branch is about compiling the "rendering parts of server side code"
into js and let them run on client side.  For example, a td template h1
{ "foo" }, which is a closure on server side, can be compiled to a
closure in js that constructs such dom node.  The rest of the logic
making use the fragment remains unchanged, as in update() / fragments
replcae/append, except the client now knows how to construct the
fragment, from either no input, current action values+action results, or
from a model retrieved with the REST api.  This would eventually leave
only the real action logic on server side, a step toward make use of
offline libraries such as google gears.

There are three milestones for this project:

milestone I - simple static template or with action	
  - minimum translation of action client side logic	
  - basic op tree translation
  - client side TD (workaround or avoid katamari deferring evaluation
for h1 { "foo"} h2 { "bar" }

milestone II - View::CRUD client side support
  - refactor jifty::web::{form,field}* to make it easy to keep in sync
with js implementation
    - bonus - compile js implementation from perl one.
  - client side continuation handling (creation and representation)
  - testing facility (selenium?)

milestone III - wrapper, nested template support
  - api to retrieve compiled template other than <fragment> in
webservices.xml request
  - handle _() and scalar defer stuff
  - bundle compiled template downloading in js init.

We are pretty much done with M1.  example/Yada in the trimclient branch
has the latest working application that makes use the facility.  If you
run Yada, click FAQ and you should notice the fragment is only loaded
once, and then it's all client-side.  Likewise, on the /signup page, if
you make the action fail twice (by not filling email for example), you
should notice that the second time the server is not returning the full
fragment, but the client is able to render the fragment from the result
of the action.

Now the scary bit.  How does the TD->js compilation work?  I cleaned up
B::Deparse's internal, and it's now possible to subclass it and change
the way it emits code based on the semantic meaning of the optree.  The
patch has been accepted in perl blead, but more cleanups for B::Deparse
is needed, and that's one of the things I am likely to need help from.


More information about the jifty-devel mailing list