From: Roberto S. <rs...@gm...> - 2006-06-17 03:06:40
|
my webapp has (beside of dynamic ones) several static pages with a common layout. What is the best was to share this common layout as HTML template ? Currently I split those pages into a SSI-shared top part, the content-part and and a SSI-shared bottom part. But I would like to have the shared template in ONE file. With SSI this seems not to be posssible (to me) regards -- Roberto Saccon |
From: Yariv S. <ya...@gm...> - 2006-06-17 03:14:33
|
On 6/16/06, Roberto Saccon <rs...@gm...> wrote: > my webapp has (beside of dynamic ones) several static pages with a > common layout. What is the best was to share this common layout as > HTML template ? > > Currently I split those pages into a SSI-shared top part, the > content-part and and a SSI-shared bottom part. But I would like to > have the shared template in ONE file. With SSI this seems not to be > posssible (to me) I admit I'm not an expert on this one, but I'll make a suggestion: Have a single Yaws page as the "controller" for your application. This controller will have all the common parts: header, footer, etc. When you want to display another page, make a call such as http://www.foo.com/myapp/main.yaws?page=mypage. If your controller is called "main.yaws", it will have a function such as out(A) -> .... in which you will parse the request parameters, and based on the "page" parameter, you would pick the sub-page you want to include via SSI. I've never done this, so no guarantees! :) Best Yariv |
From: Roberto S. <rs...@gm...> - 2006-06-17 03:43:01
|
Yariv, thanks. But the URL looks ugly ! I was used to RubyOnRails URLs which look nice (e.g.: http://www.foo.com/mypage1) so I started with a directory-structure (below doc-root) - /index.yaws (main page and entrypoint for dynamic, AJAX content) - /mypage1/index,yaws (first static page) - ... /mypageN/index.yaws (static page N) With your suggestion I could probably use the rewrite module to get nice URLs, but there is still a problem left: The layout is tied to main yaws. How can I easily change it ? (e.g. HTML-template provided by user or customer) regards Roberto On 6/17/06, Yariv Sadan <ya...@gm...> wrote: > On 6/16/06, Roberto Saccon <rs...@gm...> wrote: > > my webapp has (beside of dynamic ones) several static pages with a > > common layout. What is the best was to share this common layout as > > HTML template ? > > > > Currently I split those pages into a SSI-shared top part, the > > content-part and and a SSI-shared bottom part. But I would like to > > have the shared template in ONE file. With SSI this seems not to be > > posssible (to me) > > I admit I'm not an expert on this one, but I'll make a suggestion: > > Have a single Yaws page as the "controller" for your application. This > controller will have all the common parts: header, footer, etc. When > you want to display another page, make a call such as > http://www.foo.com/myapp/main.yaws?page=mypage. If your controller is > called "main.yaws", it will have a function such as > > out(A) -> .... > > in which you will parse the request parameters, and based on the > "page" parameter, you would pick the sub-page you want to include via > SSI. > > I've never done this, so no guarantees! :) > > Best > Yariv > -- Roberto Saccon |
From: Yariv S. <ya...@gm...> - 2006-06-17 03:54:16
|
On 6/16/06, Roberto Saccon <rs...@gm...> wrote: > Yariv, thanks. But the URL looks ugly ! I was used to RubyOnRails URLs > which look nice (e.g.: http://www.foo.com/mypage1) so I started with a > directory-structure (below doc-root) Yes, I know... Yaws needs to borrow a few good ideas from RoR -- especially as far as making it easy to just get started quickly and easily the "right way." Depending on how deep I get involved with Yaws, I make try to hack a simple MVC framework like RoR for Yaws. At this point, I'm still waiting to see if other people come up with one (it sounds like a few people are working of various aspects of such a framework, but I don't know how mature their efforts are). > > - /index.yaws (main page and entrypoint for dynamic, AJAX content) > - /mypage1/index,yaws (first static page) > - ... > /mypageN/index.yaws (static page N) > > > With your suggestion I could probably use the rewrite module to get > nice URLs, but there is still a problem left: The layout is tied to > main yaws. How can I easily change it ? (e.g. HTML-template provided > by user or customer) The only solution I can find from the documentation is described here: http://yaws.hyber.org/appmods.yaws. I suppose you could have a different appmod for each layout, but I haven't tried it myself. Good luck! Yariv (I'm actually learning a lot from your questions, because you've gone farther than I have -- probably than most people have -- in Erlang web development :) ) |
From: Bruce F. <Bruce@Fitzsimons.org> - 2006-06-17 04:30:56
|
Yariv Sadan wrote: >> With your suggestion I could probably use the rewrite module to get >> nice URLs, but there is still a problem left: The layout is tied to >> main yaws. How can I easily change it ? (e.g. HTML-template provided >> by user or customer) >> > > The only solution I can find from the documentation is described here: > http://yaws.hyber.org/appmods.yaws. I suppose you could have a > different appmod for each layout, but I haven't tried it myself. > > Just FYI (and you'll need to tidy this up yourself) but someone was asking about modifying the yaws wiki to do this the other day. I've done this in a hacky way as I had to alter all the url-generation, but the "nice url" side is easy to fix... (apologies for not piping up sooner, I've been distracted by snow) <code snippet> out(Arg) -> {abs_path, P} = (Arg#arg.req)#http_request.path, Path = yaws_api:url_decode(P), Prefix = wiki_yaws:get_path_prefix(Path), wiki:showPage([{node,basename(Arg#arg.appmoddata)}], "/www/wiki", "/www/wiki"). </code snippet> As you can see, since you get the http_request_path into yaws you can pretty much have any url scheme you want; you just need to build it. I'm busy building my own apps at the moment, and a framework would make it easier, but I'm coping :-) I think a lack of "this is the best way to do form processing" type tutorial has been my biggest barrier, I'm still evolving my approach to this. Cheers, Bruce |
From: Yariv S. <ya...@gm...> - 2006-06-17 04:59:42
|
> As you can see, since you get the http_request_path into yaws you can > pretty much have any url scheme you want; you just need to build it. > > I'm busy building my own apps at the moment, and a framework would make > it easier, but I'm coping :-) I think a lack of "this is the best way to > do form processing" type tutorial has been my biggest barrier, I'm still > evolving my approach to this. > I think that a *simple* MVC framework shouldn't be too hard to hack... basically, it would need to consume a URL such as http://www.foo.org/myapp/people/edit?id=1 where 'myapp' is the app name, 'people is the controller name, 'edit' is the function name in the controller as well as the template file name for displaying the controller's output, and 'id' is the param(s). Under 'myapp', there would be the following directory structure (shamelessly copied from RoR): myapp/models model.erl model2.erl... myapp/controllers app_c.erl (default controller) people_c.erl other_c.erl myapp/views app.view people/ new.vew edit.view so everything is organized and easy to find. The template language can just be Erlang for now, where instead of the usual out(Arg), the argument would be the output from the controller's function. I'm actually not sure about the "model" part because things are very different whether you use Mnesia or another RDMBS. Ideally, other RDMBS would be irrelevent, but Mnesia has disc storage issues that I prefer to not have to deal with. I've been pestering the erlang-questions list about this for a while, but so far I haven't gotten an indication that they will be resolved, so with a heavy heart I have to choose with MySQL for my app and figure out how to bridge the semantic gap :( Regards, Yariv |
From: Roberto S. <rs...@gm...> - 2006-06-17 05:28:36
|
Yariv, can you briefly summarize why mnesia cannot be used for a typical webapp. I tried to follow the thread at the Erlang mailing list, but I didn't get the main points of the limitations. On 6/17/06, Yariv Sadan <ya...@gm...> wrote: > > As you can see, since you get the http_request_path into yaws you can > > pretty much have any url scheme you want; you just need to build it. > > > > I'm busy building my own apps at the moment, and a framework would make > > it easier, but I'm coping :-) I think a lack of "this is the best way to > > do form processing" type tutorial has been my biggest barrier, I'm still > > evolving my approach to this. > > > > I think that a *simple* MVC framework shouldn't be too hard to hack... > basically, it would need to consume a URL such as > > http://www.foo.org/myapp/people/edit?id=1 > > where 'myapp' is the app name, 'people is the controller name, 'edit' > is the function name in the controller as well as the template file > name for displaying the controller's output, and 'id' is the param(s). > > Under 'myapp', there would be the following directory structure > (shamelessly copied from RoR): > > myapp/models > model.erl > model2.erl... > myapp/controllers > app_c.erl (default controller) > people_c.erl > other_c.erl > myapp/views > app.view > people/ > new.vew > edit.view > > > so everything is organized and easy to find. The template language can > just be Erlang for now, where instead of the usual out(Arg), the > argument would be the output from the controller's function. > > I'm actually not sure about the "model" part because things are very > different whether you use Mnesia or another RDMBS. Ideally, other > RDMBS would be irrelevent, but Mnesia has disc storage issues that I > prefer to not have to deal with. I've been pestering the > erlang-questions list about this for a while, but so far I haven't > gotten an indication that they will be resolved, so with a heavy heart > I have to choose with MySQL for my app and figure out how to bridge > the semantic gap :( > > Regards, > Yariv > -- Roberto Saccon |
From: Yariv S. <ya...@gm...> - 2006-06-17 06:03:04
|
On 6/17/06, Roberto Saccon <rs...@gm...> wrote: > Yariv, can you briefly summarize why mnesia cannot be used for a > typical webapp. I tried to follow the thread at the Erlang mailing > list, but I didn't get the main points of the limitations. > Well, Mnesia *can* be used for many webapps. However, there are a couple of things to keep in mind: 1) If your server crashes, disc_only (dets) tables get corrupted and they need to be rebuilt. Depending on the size of the table, it can take up to half an hour. The exact time is not clear. 2) Dets keeps a free-list, i.e. a linked list of free space, for each table in RAM. As your table becomes fragmented (this happens when old data is deleted and new data is stored), the free-list grows. There are ways of measuring the RAM consumption, but in order to reduce it, your only options are to take the database offline and restart it with a force_repair flag IIRC, which can take a while (the time is unclear), or to make a fresh copy the table, so the table's copy is not fragmented. If the table is big, this can be prohibitively expensive. 3) You need to fragment tables over 2GB. This process is documented, and it's not that bad, but a bit annoying. Depending on the size of your data sets, these may not be serious issues. If you can keep your data in RAM, these issues are less meaningfull, but you have to be careful not to let your dataset will grow too much, or at least be aware that you may have to fall back on MySQL or Postgres. Regards, Yariv |
From: Roberto S. <rs...@gm...> - 2006-06-17 06:40:27
|
Great summmary. Well, I will give mnesia a try, but probably also setup postgresql , so I can test with both. Yarif, if I understand propperly, you refer to mensia running inside the same process as mnesia. Would it help (or is it possible / making sense) to run mnesia as seperate process just to prevent that a yaws creash brings down the db ? On 6/17/06, Yariv Sadan <ya...@gm...> wrote: > On 6/17/06, Roberto Saccon <rs...@gm...> wrote: > > Yariv, can you briefly summarize why mnesia cannot be used for a > > typical webapp. I tried to follow the thread at the Erlang mailing > > list, but I didn't get the main points of the limitations. > > > > Well, Mnesia *can* be used for many webapps. However, there are a > couple of things to keep in mind: > > 1) If your server crashes, disc_only (dets) tables get corrupted and > they need to be rebuilt. Depending on the size of the table, it can > take up to half an hour. The exact time is not clear. > > 2) Dets keeps a free-list, i.e. a linked list of free space, for each > table in RAM. As your table becomes fragmented (this happens when old > data is deleted and new data is stored), the free-list grows. There > are ways of measuring the RAM consumption, but in order to reduce it, > your only options are to take the database offline and restart it with > a force_repair flag IIRC, which can take a while (the time is > unclear), or to make a fresh copy the table, so the table's copy is > not fragmented. If the table is big, this can be prohibitively > expensive. > > 3) You need to fragment tables over 2GB. This process is documented, > and it's not that bad, but a bit annoying. > > Depending on the size of your data sets, these may not be serious > issues. If you can keep your data in RAM, these issues are less > meaningfull, but you have to be careful not to let your dataset will > grow too much, or at least be aware that you may have to fall back on > MySQL or Postgres. > > Regards, > Yariv > -- Roberto Saccon |
From: Yariv S. <ya...@gm...> - 2006-06-17 06:46:04
|
On 6/17/06, Roberto Saccon <rs...@gm...> wrote: > Great summmary. Well, I will give mnesia a try, but probably also > setup postgresql , so I can test with both. Mnesia is *much* nicer to use from Erlang because you can store any Erlang term in it and you access it from very intuitive Erlang functions. > > Yarif, if I understand propperly, you refer to mensia running inside > the same process as mnesia. Would it help (or is it possible / making > sense) to run mnesia as seperate process just to prevent that a yaws > creash brings down the db ? Well, I meant the DB server crashing could take your app offline for a while... depending on your data set, this may not be too long. It's less about Yaws and more about Mnesia. I hope the OTP team makes Mnesia disc storage behave more like MySQL/InnoDB and Postgres... Until then, either you take the risks associated with dets or you have to use another database. Best, Yariv |
From: Mikael K. <mik...@cr...> - 2006-06-17 11:31:55
Attachments:
yapp.tar.gz
|
Sat 17 June 2006 06:59 Yariv Sadan wrote: > I think that a *simple* MVC framework shouldn't be too hard to hack... > basically, it would need to consume a URL such as > > http://www.foo.org/myapp/people/edit?id=1 > > where 'myapp' is the app name, 'people is the controller name, 'edit' > is the function name in the controller as well as the template file > name for displaying the controller's output, and 'id' is the param(s). > > Under 'myapp', there would be the following directory structure > (shamelessly copied from RoR): > > myapp/models > model.erl > model2.erl... > myapp/controllers > app_c.erl (default controller) > people_c.erl > other_c.erl > myapp/views > app.view > people/ > new.vew > edit.view > > > so everything is organized and easy to find. The template language can > just be Erlang for now, where instead of the usual out(Arg), the > argument would be the output from the controller's function. > .. Hi Yariv, I have been working with great support from our Yaws maintainer Klacke on an application to easily deploy Yaws applications (which I call Yapps) independently from each other, in a kind of java servlet fashion. Altough I originally tried to solve another problem than yours I had to address a solution for adding a controller as a friend of mine implemented a Yapp with an MVC pattern. A Yapp is actually an Erlang/OTP application with some optional extra information in the .app file and the docroot in the priv/docroot directory (default). So the basic directory layout looks like myapp/src /ebin /priv/docroot/*.{html,yaws} The Yapp handler takes care of adding and removing Yapps to the Yaws virtual server you want. The yapp handlers application callback module (yapp.erl) is installed as a runmod as well as an arg_rewrite_mod in yaws.conf A prerequisite in order to deploy a Yapp is that it is already unpacked and in the Erlang path (which may be solved by other applications like erlmerge, the Erlang/OTP release handler or "manually"). Example: (yaws has been started with: yaws --daemon -sname hej ) (huj@myhost)1>yapp_handler:add({yapp_handler,'hej@myhost'}, "myvirtserverid", myapp). where "myvirtserverid" is the the "server id" set in the opaque variable yapp_server_id in yaws.conf: <opaque> yapp_server_id = myvirtserverid </opaque> This will add myapp to the URL http://myhost.foo.org/myapp You can optionally give another URL path than the application name. When yaws encounters the ../myapp URL the docroot will be temporarily switched to the Yapp docroot. You can also add appmods that are only active when the Yapp is active by adding to the myapp applications .app file: {env, [ {yapp_appmods,[{"/people",people_c}]} ]}, which will activate the controller appmod people_c in my_app for the URL http://myhost.foo.org/myapp/people My plan is to add the yapp handler to the other Yaws applications if others like it, but I wan't add a Web interface for deploying applications, so you do not have to start another erlang shell to deploy yapps, and some more documentation, examples, clean up code etc. Meanwhile I attach the yapp handler as is with som edoc documentation (it is only 12k zipped) so that you can check it out if you like. You will need the very latest version of Yaws too. Regards Mikael PS I will be on vacation (really off-line) for the next week so unfortunately I will not be able to answer any questions on the application during this time. (Sorry :) DS |
From: Yariv S. <ya...@gm...> - 2006-06-17 12:18:42
|
Hi Mikael, Very interesting... I am actually going to be gone all weekend but I'll take a close look when I get back. On another topic, my haXe remoting adapter for Yaws is close to completion... Should be done next week. Best, Yariv On 6/17/06, Mikael Karlsson <mik...@cr...> wrote: > Sat 17 June 2006 06:59 Yariv Sadan wrote: > > I think that a *simple* MVC framework shouldn't be too hard to hack... > > basically, it would need to consume a URL such as > > > > http://www.foo.org/myapp/people/edit?id=1 > > > > where 'myapp' is the app name, 'people is the controller name, 'edit' > > is the function name in the controller as well as the template file > > name for displaying the controller's output, and 'id' is the param(s). > > > > Under 'myapp', there would be the following directory structure > > (shamelessly copied from RoR): > > > > myapp/models > > model.erl > > model2.erl... > > myapp/controllers > > app_c.erl (default controller) > > people_c.erl > > other_c.erl > > myapp/views > > app.view > > people/ > > new.vew > > edit.view > > > > > > so everything is organized and easy to find. The template language can > > just be Erlang for now, where instead of the usual out(Arg), the > > argument would be the output from the controller's function. > > .. > > Hi Yariv, > > I have been working with great support from our Yaws maintainer Klacke on an > application to easily deploy Yaws applications (which I call Yapps) > independently from each other, in a kind of java servlet fashion. > Altough I originally tried to solve another problem than yours I had to > address a solution for adding a controller as a friend of mine implemented a > Yapp with an MVC pattern. > > A Yapp is actually an Erlang/OTP application with some optional extra > information in the .app file and the docroot in the priv/docroot directory > (default). So the basic directory layout looks like > myapp/src > /ebin > /priv/docroot/*.{html,yaws} > > The Yapp handler takes care of adding and removing Yapps to the Yaws virtual > server you want. The yapp handlers application callback module (yapp.erl) is > installed as a runmod as well as an arg_rewrite_mod in yaws.conf > > A prerequisite in order to deploy a Yapp is that it is already unpacked and in > the Erlang path (which may be solved by other applications like erlmerge, the > Erlang/OTP release handler or "manually"). > > Example: (yaws has been started with: yaws --daemon -sname hej ) > > (huj@myhost)1>yapp_handler:add({yapp_handler,'hej@myhost'}, "myvirtserverid", > myapp). > > where "myvirtserverid" is the the "server id" set in the opaque variable > yapp_server_id in yaws.conf: > <opaque> > yapp_server_id = myvirtserverid > </opaque> > > This will add myapp to the URL http://myhost.foo.org/myapp > You can optionally give another URL path than the application name. > > When yaws encounters the ../myapp URL the docroot will be temporarily switched > to the Yapp docroot. > > You can also add appmods that are only active when the Yapp is active by > adding to the myapp applications .app file: > {env, [ > {yapp_appmods,[{"/people",people_c}]} > ]}, > > which will activate the controller appmod people_c in my_app for the URL > http://myhost.foo.org/myapp/people > > My plan is to add the yapp handler to the other Yaws applications if others > like it, but I wan't add a Web interface for deploying applications, so you > do not have to start another erlang shell to deploy yapps, and some more > documentation, examples, clean up code etc. > > Meanwhile I attach the yapp handler as is with som edoc documentation (it is > only 12k zipped) so that you can check it out if you like. You will need the > very latest version of Yaws too. > > Regards > Mikael > > PS > I will be on vacation (really off-line) for the next week so unfortunately I > will not be able to answer any questions on the application during this time. > (Sorry :) > DS > > > > |
From: Christian S <ch...@gm...> - 2006-06-17 12:50:33
|
There is a feature in yaws that allow you to pass additional arguments to a yaws page through the path-part of an url. Say you have example.yaws in your docroot. http://example.com/example.yaws/foobar will then put "/foobar" in A#arg.pathinfo You can then construct your example.yaws page as <html> <erl> out(A) -> mycontent:body(A#arg.pathinfo).</erl> </html> where mycontent:body/1 could be a function of yours that outputs some information based on the rest of the path. I use this method myself as a quick way to get a few pages up. It is quite nice and the urls arent too bad. An alternative is to create an url rewriter module that rewrites http://example.com/descriptivename/subpage into into a request for /example.yaws?page=subpage See more about arg_rewrite_mod in the yaws doc. This method is something php+apache people are more familiar with, they seem to have some kind of mod_rewrite regexp solution that does something similar. It is just that in yaws youre not restricted to a regexp language, but the full competent erlang. On 6/17/06, Roberto Saccon <rs...@gm...> wrote: > my webapp has (beside of dynamic ones) several static pages with a > common layout. What is the best was to share this common layout as > HTML template ? > > Currently I split those pages into a SSI-shared top part, the > content-part and and a SSI-shared bottom part. But I would like to > have the shared template in ONE file. With SSI this seems not to be > posssible (to me) > > regards > -- > Roberto Saccon > > > _______________________________________________ > Erlyaws-list mailing list > Erl...@li... > https://lists.sourceforge.net/lists/listinfo/erlyaws-list > |