From: Torbjorn T. <to...@to...> - 2007-03-05 13:40:27
|
Filippo Pacini wrote: > Hi all, ...snip... > > Moreover I think a template language like String Template is more > general. You can also use it to generate for example sql code, simple > text emails, or whatever you like. Though maybe then you don't need yaws > :-). Yes, I noticed that when I read your examples and I liked it a lot! Perhaps Yaws could/should define a simple API to make it possible to plug in an 'arbitrary' template engine ? Cheers, Tobbe |
From: Vlad D. <vla...@gm...> - 2007-03-05 13:57:47
|
Hi, On 3/5/07, Torbjorn Tornkvist <to...@to...> wrote: > Perhaps Yaws could/should define a simple API to make it possible to > plug in an 'arbitrary' template engine ? Just a silly question: doesn't yaws already support php? Why is an API needed? I mean, yaws is a web server - isn't the template machinery an orthogonal issue? Or at least, shouldn't it be? regards, Vlad |
From: Filippo P. <pa...@sg...> - 2007-03-05 16:43:42
|
First of all sorry for the long answer :-) Torbjorn Tornkvist wrote: > Filippo Pacini wrote: >> Hi all, > ...snip... >> Moreover I think a template language like String Template is more >> general. You can also use it to generate for example sql code, simple >> text emails, or whatever you like. Though maybe then you don't need yaws >> :-). > > Yes, I noticed that when I read your examples and I liked it a lot! > > Perhaps Yaws could/should define a simple API to make it possible to > plug in an 'arbitrary' template engine ? > This would be a nice feature to have. Maybe you could do something like apache mod_python (www.modpython.org). Don't know if you are familiar with it. It's very similar to appmods. In the apache configuration you have something like this: <Directory /some/directory/htdocs/test> AddHandler mod_python .py PythonHandler mptest </Directory> This tells apache that .py urls in the dir. /some/directory/htdocs/test are managed by the handler mptest. Then mptest must has a function handler (like out in yaws appmods) that manages the request. Till now it's like an appmod. Then on top of these you have an handler called Publisher. What the publisher basically does is map an url like foo.py/bar to the function call bar in the file foo.py In this way urls are conveniently mapped to python modules. Here you don't have templates, but in foo.py you can use the template language you prefer. Don' t know if this can help, but at the moment I'm developing applications like this. This is a basic appmod: out(A) -> %% this matches urls to erlang modules and functions MatchSpec = [{"/", fun login_res:render/1}, {{regexp, "/summary/?"}, fun summary_res:render/1}, ...], case sgweb:resource_matcher(MatchSpec, A#arg.appmoddata) of {no_match, {status, NotFound}} -> %% 404 error page not found error(A, NotFound); Resource -> %% call the function that render the web resource Resource(A) end. Then an example of a resource module to be rendered: I've defined a behaviour because all resources have the same structure -module(summary_res). -behaviour(sgweb_resource). %% behaviour callbacks -export([tmpl/1, render/1, handle_req/1]). %% this returns the file containing the template to be rendered tmpl(Arg) -> TmplDir = Arg#arg.docroot, {file, TmplDir ++ "/summary.html"}. %% This handles a get request and returns the data to be passed to the template handle_req({'GET', Arg}) -> %%here I load all the Data needed, update data in mnesia, etc... {ok, [DataAndCallbacksForTheTemplate]} %% the render of the resource has a default implementation %% it first get the template, then call handle_req to get the data %% and finally calls the render of the template passing data render(Arg) -> sgweb_resource:render(Arg, ?MODULE). With something like this I think switching between different template systems should be easy. You should only need a small wrapper (e.g. I called render in sgte what in Seethrough is called apply_template). filippo |
From: Mikael K. <mik...@cr...> - 2007-03-05 21:30:59
|
m=E5ndag 05 mars 2007 12:03 skrev Filippo Pacini: > Hi all, > > Torbjorn Tornkvist wrote: >> ..... > > Personally, I like the look of Seethrough, but as I understand > > it from reading the paper above it (e.g) breaks an important property > > in that it allows attributes to be injected from the controller/model. > > It is in an early stage though and will/could probably be revised > > many times still. > > I like the look of XML based template systems too, but IMHO they have > some problems. > An example from the Seethrough home page: > <td e:content=3D"address"/> > > If you open the html page on an editor like Dreamweaver, or in some > browser you can't see the column because empty cells aren't rendered. > > You shoud have something like: > <td e:content=3D"address">address</td> > where the cell content is replaced at runtime. > .... I think that XMLC do not have this problem since it uses the id and class= =20 attribute for content replacement.=20 http://www.webreference.com/xml/column23/index.html http://forge.objectweb.org/projects/xmlc /Mikael |
From: Christian S <ch...@gm...> - 2007-03-04 20:11:20
|
I scanned that paper quickly and want to object to something he concludes about "pull" vs "push" templates. He claims that that for pull templates the order matters which creates dependencies and high suckiness. This is of course not true for lazy-evaluation! I went googling to find a lazy-evaluation template language and i find an interesting comment to this blog post about template languages in erlang (!!! :-). 'Anonymous' mentions lazy-evaluation too after having read the same paper. I mostly agree with his position on things so ill let him speak for me: (search for lazy-eval if the comment permalink doesnt work) http://www.bluishcoder.co.nz/2006/06/html-template-languages.html#115036710115336873 I'm imagining something like this: HEAD file: <html> <head> <title>$$Title$$</title> SEARCH file: $$render HEAD$$ $$Title= "Search results for the query %s." % {Query}$$ <body> <table> <caption>You have $$Searchresult.length$$ hits for $$Query$$.</caption> $$Query = args["q"]$$ $$Searchresult = search(Query)$$ $$map Searchresult as Row over {{{ <tr><td>$$Row.title$$ <td> $$Row.summary$$ <td>$$Row.relevance$$ </tr> }}} $$ </table> So invoking the view SEARCH?q=foo+bar would output something like: <html> <head> <title>Search result for the query foo bar.</title> <body> <table> <caption>You have 3 hits for foo bar</caption> <tr><td>Gurka<td>...</tr> <tr><td>Sallad<td>...</tr> <tr><td>Ananas<td>...</tr> </table> Now, the syntax i chosed for this imaginary template language is very open for improvements, it was inspired by pseudo-template-code used in the pdf article. The idea is that all templates have access to a few service objects on which they can invoke arbitrary computations, so all templates are created equal in their ability of what view to present of the model. A push-template will only be able to present a view of the data that has been computated for it, no more, but less (meaning unecessary computation has been done for data that wont be used). In a MVC pattern, the controller would decide what variables to place initially in the environment. If the template calls no methods/functions but only expands variables it is essentially a template of the "push"-kind. Undoubtably a lazy-evaluation "pull"-template would make it possible to put "business logic" in the template, but that is an argument against programmers or deadline demands that do so, and not against a solution that allows it as a cop out. PS. Somewhere someone must have created a template language with lazy-evaluation already? The functional programming purists would have the idea strike them easier than others. On 3/4/07, Torbjorn Tornkvist <to...@to...> wrote: > Yariv Sadan skrev: > > Hi, > > > > I have a couple of suggestions: > > > ....snip... > > > > For supporting new template languages, I think you should consider > > using ErlyWeb because it already provides the plumbing for separating > > the controller logic from the view template logic. (I, personally, > > prefer ErlTL, but I am willing to help with supporting other options.) > > After having read this excellent paper: > > http://www.cs.usfca.edu/~parrt/papers/mvc.templates.pdf > > that 'mikkom' recommended in a comment on the ErlTl blog entry. > I think it is important to carfully consider how a template > system for Yaws should be constructed. > > Personally, I like the look of Seethrough, but as I understand > it from reading the paper above it (e.g) breaks an important property > in that it allows attributes to be injected from the controller/model. > It is in an early stage though and will/could probably be revised > many times still. > > I haven't used any template system yet for doing Erlang-Web development > (appart from SSI which the article immediately does away with) and can't > really state what the requirements on such a system should be. > However, I've become more and more unhappy with the current situation > of mixing EHTML with control logic, etc so the article above was > a really good eye-opener to me. > > It would be interesting to have a discussion about this topic. > For example: > > + What do you people think a template system should support? > + How does ErlTL/Seethrough relate to the definitions in the above article? > > > > > Regarding backend integration with Javascript libraries, I recently > > saw a good quote by one of the Django developers: "Why use an electric > > wheelchair if you can walk?" :) > > I've been doing quite a lot of work with jquery (jquery.com) lately > and I can really recommend it. I think it is especially suited for > functional programmers which may (like my self) have a hard time > with all that OOP. > > Cheers, Tobbe > > |
From: Filippo P. <pa...@sg...> - 2007-03-05 12:37:09
|
Christian S wrote: > I scanned that paper quickly and want to object to something he concludes > about "pull" vs "push" templates. He claims that that for pull > templates the order > matters which creates dependencies and high suckiness. > > This is of course not true for lazy-evaluation! > > I went googling to find a lazy-evaluation template language and i find > an interesting comment to this blog post about template languages in > erlang (!!! :-). 'Anonymous' > mentions lazy-evaluation too after having read the same paper. I mostly agree > with his position on things so ill let him speak for me: (search for > lazy-eval if the > comment permalink doesnt work) > > http://www.bluishcoder.co.nz/2006/06/html-template-languages.html#115036710115336873 > I read the comment and I don't agree very much with the poster. It's true that with lazy evaluation you don't have the problem described in the paper, but if your template can execute code arbitrarily it can also alter the model. In this way you end up again with the model and view entangled together and template languages were born just to avoid this :-) If I have a template language which is a turing complete language or something similar I know in the end I'll use the features mixing view and model (most of the time due to time constraints) and regretting it at the first change I have to do :-). It happened me more than once. > I'm imagining something like this: > ... snip ... > > The idea is that all templates have access to a few service objects on > which they can > invoke arbitrary computations, so all templates are created equal in > their ability of what view > to present of the model. > A push-template will only be able to present a view > of the data that has been computated for it, no more, but less > (meaning unecessary computation has been done for data that wont be > used). Unnecessary computation in a push template can be avoided with lazy evaluation too. For example in an if branch you can have a closure called when the template is rendered. Having push IMHO doesn't mean you can't executed code in the template, only that the code is in the model and it's pushed in the view. I think it's more a problem of who's "responsible" for the code. > > In a MVC pattern, the controller would decide what variables to place initially > in the environment. If the template calls no methods/functions but only expands > variables it is essentially a template of the "push"-kind. > > Undoubtably a lazy-evaluation "pull"-template would make it possible > to put "business logic" in the template, but that is an argument > against programmers or deadline demands that do so, and not against a > solution that allows it as a cop out. Yes it's exactly as I said above. You have to balance the conveniences, executing code arbitrarily, gives you and the drawback you have when you mix model and view keeping in mind you need a template language and not a programming language. Cheers, filippo |
From: Yariv S. <ya...@gm...> - 2007-03-07 02:38:30
|
> Undoubtably a lazy-evaluation "pull"-template would make it possible > to put "business logic" in the template, but that is an argument > against programmers or deadline demands that do so, and not against a > solution that allows it as a cop out. > > PS. Somewhere someone must have created a template language with > lazy-evaluation already? The functional programming purists would have > the idea strike them easier > than others. One of my favorite aspects of ErlTL templates is that the controller can pass them closures, which the view uses to "lazily" evaluate its data. I wrote a whole tutorial about this here: http://yarivsblog.com/articles/2007/02/23/erlyweb-tutorial-life-in-the-intersection-of-fp-and-dynamic-html/. This feature is so great that I would have to use a template language that doesn't let me use closures. Best, Yariv |
From: Christian S <ch...@gm...> - 2007-03-05 14:23:54
|
On 3/5/07, Torbjorn Tornkvist <to...@to...> wrote: > Yes, I noticed that when I read your examples and I liked it a lot! > > Perhaps Yaws could/should define a simple API to make it possible to > plug in an 'arbitrary' template engine ? Probably. Giving up on .yaws page support is not an alternative. I have been pondering scanning the docroot file tree at startup for all the files in it and placing it in an ets table. Then looking up all http requests against this ets table to find which filesystem name (or other) to access. I would be able to remove all .yaws-suffixed names in the ets table and store the names without the suffix. Appmod references from the configuration could be stored in this ets table. Index files such as index.html and index.yaws could be removed from the ets table and only be accessible from a single name, the trailing-slash-on-a-dir, reversely, a http request path that ends with a trailing / could always be mapped to /index instead. If my docroot has a /st/style.css and /st/style.css.gz then i could first map up /st/style as a single exposed name for the resource, and for those clients that accept a gzip content encoding i can serve the pre-compressed version. The downside is for directories under docroot that change. I mostly write database-driven sites so it is not really my concern. The solution would be to install an appmod that solves that. PS Yes, I have a perverted quest for clean urls. |
From: Christopher C. <cov...@gm...> - 2007-03-05 15:20:48
|
> PS > Yes, I have a perverted quest for clean urls. I too would love to see easy, non-external, url rewriting. I tried to write a redirecting module that would redirect people from www.domain.tld to domain.tld (to obtain no-www.org's class B status). Not every having hacked around with YAWS, I fell flat on my face and gave up. Chris |
From: Christian S <ch...@gm...> - 2007-03-05 15:27:57
|
That is pretty easy though. <server example.com> main conf here </server> <server www.example.com> port, listen and docroot conf still required <redirect> / = example.com </redirect> </server> Or does it not suffice? On 3/5/07, Christopher Covington <cov...@gm...> wrote: > > PS > > Yes, I have a perverted quest for clean urls. > > I too would love to see easy, non-external, url rewriting. I tried to > write a redirecting module that would redirect people from > www.domain.tld to domain.tld (to obtain no-www.org's class B status). > Not every having hacked around with YAWS, I fell flat on my face and > gave up. > > Chris > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Erlyaws-list mailing list > Erl...@li... > https://lists.sourceforge.net/lists/listinfo/erlyaws-list > |
From: Christopher C. <cov...@gm...> - 2007-03-05 16:45:53
|
Thanks a bunch. That's exactly what I wanted. I might have been reading an old (1.58) version of the yaws.conf manual when I tried to figure out how to do that before. I guess Yaws already has easy, non-external redirection implemented :). Chris On 3/5/07, Christian S <ch...@gm...> wrote: > That is pretty easy though. > > <server example.com> > main conf here > </server> > > <server www.example.com> > port, listen and docroot conf still required > <redirect> > / = example.com > </redirect> > </server> > > Or does it not suffice? > > On 3/5/07, Christopher Covington <cov...@gm...> wrote: > > > PS > > > Yes, I have a perverted quest for clean urls. > > > > I too would love to see easy, non-external, url rewriting. I tried to > > write a redirecting module that would redirect people from > > www.domain.tld to domain.tld (to obtain no-www.org's class B status). > > Not every having hacked around with YAWS, I fell flat on my face and > > gave up. > > > > Chris > > > > ------------------------------------------------------------------------- > > Take Surveys. Earn Cash. Influence the Future of IT > > Join SourceForge.net's Techsay panel and you'll get the chance to share your > > opinions on IT & business topics through brief surveys-and earn cash > > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > > _______________________________________________ > > Erlyaws-list mailing list > > Erl...@li... > > https://lists.sourceforge.net/lists/listinfo/erlyaws-list > > > |