www/ssi.yaws


<erl>


box(Str) ->
    {'div',[{class,"box"}],
     {pre,[],yaws_api:htmlize(Str)}}.

tbox(T) ->
    box(lists:flatten(io_lib:format("~p",[T]))).


ssi(File) ->
    {'div',[{class,"box"}],
     {pre,[],
      {ssi, File,[],[]}}}.


out(A) -> 
    [{ssi, "TAB.inc", "%%",[{"ssi", "choosen"}]},
     {ehtml,
      {'div', [{id, "entry"}],        
      [        
      {h1, [], "Server side includes (with variable expansion)"},
       
        {p, [],
        "This feature is useful when we are writing applications where "
        "basically the entire page is dynamically generated but we also "
        "want to include snippets of either html or, even more typically,"
        " javascript which is almost static, but not quite."},

       {p, [], "In particular the case with dynamically generated javascript "
        "can get syntactically ugly. So instead of generating strings in "
        "the erlang code for the javascripts and returning them as "
        "{pre_html, Data} tuples, it is more beautiful to keep the "
        "javascript functions in separate files and include them with "
        "the {ssi ...} return value."},

       {p, [], "The format of the ssi statement is:"},
       {br,[],[]},
       box("{ssi, File, Delimiter, Bindings}"),
       
       {p, [],"The ssi structure can occur in two radically different places"
        " but with identical semantics. It can be a return value in the "
        " out/1 function and it is a specially treated return value "
        "in ehtml output, here is an example of an odd return value "
        "from out/1"},
       
       tbox([{ssi, "ssi_ex1", "%", [{"a", "gazzonk"}]},
             {ehtml,
              [
               {h1, "a Header"},
               {ssi, "ssi_ex1", "%", [{"a", "zippo"}]}]}]),

       {p,[], "The file ssi_ex1 contains the following text:"},
       ssi("ssi_ex1"),
       {p, [], "And the following ehtml output:"},
       tbox({ehtml,[{ssi, "ssi_ex1", "%", [{"a", "Godzilla"}]}]}),
       {p,[], "Generates the following output"},
       {'div',[{class,"box"}],
        {pre,[],
         {ssi, "ssi_ex1", "%", [{"a", "Godzilla"}]}}},
       {p, [], "And so does the following out/1 function"},
       box("out(A) -> [{ssi, \"ssi_ex1\", \"%\", [{\"a\", \"Godzilla\"}]}]."),
       {p,[], "So this is the way to do when we want to embed dynamic content"
        " deep inside an ehtml structure, but the content isn't representable"
        " as ehtml. This is typically the case for dynamically generated "
        " javascript as well as dynamically generated java applets."},
       
       {p, [], "In the above example, \"a\" can be seen as the Variable "
        "name whereas \"Godzilla\" can be vieved upon as the value "
        "of variable \"a\". It is also possible to have the variable "
        " value be a complete ehtml structure, not just plain ascii "
        "strings. Here is an example"},

       box("out(A) -> 
              E = {ehtml, {h1, [], \"Godzillas baby\"}},
              [{ssi, \"ssi_ex1\", \"%\", [{\"a\", E}]}]."),


       {h1, [], "yssi, Yaws Server Side Includes"},

       {p, [], "We have a special version of server side includes that we "
        " call yssi, yaws server side includes. The syntax for this is: "},
       box("{yssi, YawsFile}"),
       {p, [], "Yssi can only be used as a return value from the out/1 "
        " function, never nested into a deep ehtml structure."
        " Yssi, will perform full yaws expansion on the file named "
        "YawsFile, i.e (possibly on the fly) compile it, execute it and"
        " subsequently inject the generated output from the YawsFile."
        " yssi statements can be arbitrarily deeply recursively nested, that "
        " is a .yaws file which has been included through an 'yssi' "
        " statement, may itself contain 'yssi' return values in its "
        " out/1 function(s) "}

      ]
      }
     }
    ].

</erl>


<erl>
out(A) -> {ssi, "END2",[],[]}.
</erl>