cppcms-users Mailing List for CppCMS C++ Web Framework (Page 99)
Brought to you by:
artyom-beilis
You can subscribe to this list here.
2009 |
Jan
|
Feb
(22) |
Mar
|
Apr
(3) |
May
|
Jun
(4) |
Jul
|
Aug
|
Sep
|
Oct
(15) |
Nov
(16) |
Dec
(13) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2010 |
Jan
(4) |
Feb
|
Mar
(8) |
Apr
(8) |
May
(8) |
Jun
(36) |
Jul
(63) |
Aug
(126) |
Sep
(47) |
Oct
(66) |
Nov
(46) |
Dec
(42) |
2011 |
Jan
(87) |
Feb
(24) |
Mar
(54) |
Apr
(21) |
May
(22) |
Jun
(18) |
Jul
(22) |
Aug
(101) |
Sep
(57) |
Oct
(33) |
Nov
(34) |
Dec
(66) |
2012 |
Jan
(64) |
Feb
(76) |
Mar
(73) |
Apr
(105) |
May
(93) |
Jun
(83) |
Jul
(84) |
Aug
(88) |
Sep
(57) |
Oct
(59) |
Nov
(35) |
Dec
(49) |
2013 |
Jan
(67) |
Feb
(17) |
Mar
(49) |
Apr
(64) |
May
(87) |
Jun
(64) |
Jul
(93) |
Aug
(23) |
Sep
(15) |
Oct
(16) |
Nov
(62) |
Dec
(73) |
2014 |
Jan
(5) |
Feb
(23) |
Mar
(21) |
Apr
(11) |
May
(1) |
Jun
(19) |
Jul
(27) |
Aug
(16) |
Sep
(5) |
Oct
(37) |
Nov
(12) |
Dec
(9) |
2015 |
Jan
(7) |
Feb
(7) |
Mar
(44) |
Apr
(28) |
May
(5) |
Jun
(12) |
Jul
(8) |
Aug
|
Sep
(39) |
Oct
(34) |
Nov
(30) |
Dec
(34) |
2016 |
Jan
(66) |
Feb
(23) |
Mar
(33) |
Apr
(15) |
May
(11) |
Jun
(15) |
Jul
(26) |
Aug
(4) |
Sep
(1) |
Oct
(30) |
Nov
(10) |
Dec
|
2017 |
Jan
(52) |
Feb
(9) |
Mar
(24) |
Apr
(16) |
May
(9) |
Jun
(12) |
Jul
(33) |
Aug
(8) |
Sep
|
Oct
(1) |
Nov
(2) |
Dec
(6) |
2018 |
Jan
(5) |
Feb
|
Mar
|
Apr
|
May
(14) |
Jun
(1) |
Jul
(9) |
Aug
(1) |
Sep
(13) |
Oct
(8) |
Nov
(2) |
Dec
(2) |
2019 |
Jan
(1) |
Feb
(1) |
Mar
(3) |
Apr
(3) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
|
2020 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
(9) |
Jul
(6) |
Aug
(25) |
Sep
(10) |
Oct
(10) |
Nov
(6) |
Dec
|
2021 |
Jan
|
Feb
|
Mar
(7) |
Apr
(1) |
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
(9) |
Oct
(1) |
Nov
|
Dec
|
2022 |
Jan
|
Feb
|
Mar
|
Apr
(3) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Alexey U. <um...@gm...> - 2012-01-16 08:57:12
|
Hello! After running my test app behind the web back-end I've encountered a problem with URL dispatching. I have a virtual host on my machine "app.net" and appropriate record has been putted to /etc/hosts: "app.net 127.0.0.1". I'm running my app externally. My lighttp configuration related to subject is as follows: $HTTP["host"] == "app.net" { server.document-root = "/opt/sites/app/" alias.url += ("/scripts" => "/opt/sites/app/scripts" ) } # here I expect all address strings which contain "app.net" are delivered to my app fastcgi.server = ( "/" => (( "socket" => "/tmp/app-fcgi-socket", "max-procs" => 1, "check-local" => "disable" )) ) My CppCMS config: { "service" : { "api" : "fastcgi", "socket" : "/tmp/app-fcgi-socket" } } I manage URLs in following way: MyApp::MyApp(cppcms::service& srv) : cppcms::application(srv) { dispatcher().assign("", &MyApp::main, this); dispatcher().assign("/home", &MyApp::main, this); dispatcher().assign("/page1", &MyApp::page1, this); dispatcher().assign("/page2", &MyApp::page2, this); } void MyApp::main() { content::Home home; home.text = "Welcome home!"; render("Home", home); } void MyApp::page1() { content::Page1 page; page.text = "Page 1"; render("Page", page); } void MyApp::page2() { content::Page2 page; page.text = "Page"; render("Page2", page2); } I expected the following behavior: http://app.net -> "Welcome home!" http://app.net/page1 -> "Page 1" http://app.net/page2 -> "Page 2" but I'm getting the following: http://app.net -> "Welcome home!" http://app.net/page1 -> "Welcome home!" http://app.net/page2 -> "Welcome home!" And I've noticed that http://app.net -> "Welcome home!" http://app.net/asd/page1 -> "Page 1" http://app.net/asd/page2 -> "Page 2" (I can use any string in place of "asd" above and it's OK) Seems like there are lighttp configuration problem but I don't know how to cope with it. Any ideas about how to achieve what I expect? Thank you! |
From: 逆. <luy...@qq...> - 2012-01-16 01:37:55
|
How to start cppcms? </:includetail> These errors occur when I run cppcms_run :</:includetail> # /usr/local/bin/cppcms_run -e -S nginx -p 1111 -h 192.168.68.131 -r /home/niliu/hello_world Usage cppcms_run [-e] [ -S server ] [-p port] [-h host] \ [-r /document/root ] [-s /script ] program -c config.txt [ additional parameters ] -c configuration file of cppcms executable -p port to start the server on, default 8080 -s fastcgi script name, default '/'+your program name -h host to bind, default 127.0.0.1 -r document root (default .) -S (lighttpd|nginx|apache2) - web server you want to run -e Do not start application, started externaly (for debugging)</:includetail> ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d _______________________________________________ Cppcms-users mailing list Cpp...@li... https://lists.sourceforge.net/lists/listinfo/cppcms-users </:includetail> |
From: Artyom B. <art...@ya...> - 2012-01-12 10:15:28
|
> >T hank you for your answers! > > Suppose I am using the person class in the json sample, can I do the following? > > void method(const person &p) {} > bind("method",cppcms::rpc::json_method(&json_service::method,this)); > Yes > Another question is that what classes should I use if I want to use > cppcms as a jsonrpc client? > CppCMS is server side if you want JavaScript json-rpc client you have plenty tool-kits like Dojo or JQuery. You can also find under contrib/clinet_side/jsonrpc simple implementation of JavaScript jronrpc client. that is used in some examples I liked to. Artyom |
From: Leon <le...@wl...> - 2012-01-12 10:05:58
|
Thank you for your answers! Suppose I am using the person class in the json sample, can I do the following? void method(const person &p) {} bind("method",cppcms::rpc::json_method(&json_service::method,this)); Another question is that what classes should I use if I want to use cppcms as a jsonrpc client? Best regards, On Thu, Jan 12, 2012 at 5:25 PM, Artyom Beilis <art...@ya...> wrote: > > > > Artyom Beilis > -------------- > CppCMS - C++ Web Framework: http://cppcms.sf.net/ > CppDB - C++ SQL Connectivity: http://cppcms.sf.net/sql/cppdb/ > > > ----- Original Message ----- >> From: Leon <le...@wl...> >> To: cpp...@li... >> Cc: >> Sent: Thursday, January 12, 2012 10:10 AM >> Subject: [Cppcms-users] jsonrpc web service >> >> Hi, >> >> Thank you for the great framework! >> >> I have some questions regarding jsonrpc. >> 1. How can I upload files using client side javascript (and how to >> handle it on server side)? > > First of all there are plenty if examples > > http://art-blog.no-ip.info/cppcms_ref_v0_99/examples_page.html > > Including file upload > > http://art-blog.no-ip.info/cppcms_ref_v0_99/ex_uploads.html > > > However, you should not upload files via JSON-RPC for several reasons: > > 1. JSON does not support binary format, only textual UTF-8 so in order > to upload the file via JSON you'll have to encode it for example > in base64 format and then decode it on server side. > > 2. It is much better to upload files via native POST interface and forms. > > >> 2. The sample jsonrpc server functions all take built-in types as >> parameters. Can structures or classes be used as parameters? > > Yes, two options: > > a) Use JSON value as is and as full json it can be a json object > > b) Define conversion from JSON to C++ object. See example > > http://art-blog.no-ip.info/cppcms_ref_v0_99/ex_json____json__cpp.html > > > >> 3. How can I generate api reference for my jsonrpc service? > > You mean simple method description (SMD)? > > Because it is not fully standardized it is not generated automatically. > > You can write your own SMD the way you want and set it using smd or smd_raw > member functions of json_rpc_service: > > http://art-blog.no-ip.info/cppcms_ref_v0_99/classcppcms_1_1rpc_1_1json__rpc__server.html > > >> 4. Is there any recommended way for authentication/security? >> > > 1. CppCMS has session management that can be used for authentication. > > 2. For Ajax POST calls you may want to use CSRF tokens as well. > > There is a wide guide about it: > > http://art-blog.no-ip.info/wikipp/en/page/secure_programming > >> Thanks, >> Lirong >> > > Artyom > > ------------------------------------------------------------------------------ > RSA(R) Conference 2012 > Mar 27 - Feb 2 > Save $400 by Jan. 27 > Register now! > http://p.sf.net/sfu/rsa-sfdev2dev2 > _______________________________________________ > Cppcms-users mailing list > Cpp...@li... > https://lists.sourceforge.net/lists/listinfo/cppcms-users |
From: Artyom B. <art...@ya...> - 2012-01-12 09:26:17
|
Artyom Beilis -------------- CppCMS - C++ Web Framework: http://cppcms.sf.net/ CppDB - C++ SQL Connectivity: http://cppcms.sf.net/sql/cppdb/ ----- Original Message ----- > From: Leon <le...@wl...> > To: cpp...@li... > Cc: > Sent: Thursday, January 12, 2012 10:10 AM > Subject: [Cppcms-users] jsonrpc web service > > Hi, > > Thank you for the great framework! > > I have some questions regarding jsonrpc. > 1. How can I upload files using client side javascript (and how to > handle it on server side)? First of all there are plenty if examples http://art-blog.no-ip.info/cppcms_ref_v0_99/examples_page.html Including file upload http://art-blog.no-ip.info/cppcms_ref_v0_99/ex_uploads.html However, you should not upload files via JSON-RPC for several reasons: 1. JSON does not support binary format, only textual UTF-8 so in order to upload the file via JSON you'll have to encode it for example in base64 format and then decode it on server side. 2. It is much better to upload files via native POST interface and forms. > 2. The sample jsonrpc server functions all take built-in types as > parameters. Can structures or classes be used as parameters? Yes, two options: a) Use JSON value as is and as full json it can be a json object b) Define conversion from JSON to C++ object. See example http://art-blog.no-ip.info/cppcms_ref_v0_99/ex_json____json__cpp.html > 3. How can I generate api reference for my jsonrpc service? You mean simple method description (SMD)? Because it is not fully standardized it is not generated automatically. You can write your own SMD the way you want and set it using smd or smd_raw member functions of json_rpc_service: http://art-blog.no-ip.info/cppcms_ref_v0_99/classcppcms_1_1rpc_1_1json__rpc__server.html > 4. Is there any recommended way for authentication/security? > 1. CppCMS has session management that can be used for authentication. 2. For Ajax POST calls you may want to use CSRF tokens as well. There is a wide guide about it: http://art-blog.no-ip.info/wikipp/en/page/secure_programming > Thanks, > Lirong > Artyom |
From: Leon <le...@wl...> - 2012-01-12 08:27:53
|
Hi Augustin, Thank you for your reply! I tried to register with the wiki but failed. On Thu, Jan 12, 2012 at 4:18 PM, augustin <aug...@ov...> wrote: > On Thursday, January 12, 2012 04:10:37 PM Leon wrote: >> 1. How can I upload files using client side javascript (and how to >> handle it on server side)? > > Hi Leon, > > I am sorry, I don't have any answers for you. Artyom will certainly be able to > help you more ;) > > However, file upload is a topic that regularly comes up on the mailing list. > Unfortunately, previous askers didn't bother documenting the answers and the > solutions they got. Could you log into the wiki and prepare a placeholder wiki > page about file upload? I don't think one exists already, but you can check. > You and others will be able to document tips and tricks about file upload. > > You can search the mailing list, because as I said, the question came up > before... > > Thanks in advance for your contributions. > > Good luck, > > Augustin. > > -- > Friends: http://www.reuniting.info/ > My projects: > http://astralcity.org/ http://3enjeux.overshoot.tv/ http://linux.overshoot.tv/ > http://overshoot.tv/ http://charityware.info/ http://masquilier.org/ > http://openteacher.info/ http://minguo.info/ > http://www.wechange.org/ http://searching911.info/ > > > > > > > > > > > > > . > > ------------------------------------------------------------------------------ > RSA(R) Conference 2012 > Mar 27 - Feb 2 > Save $400 by Jan. 27 > Register now! > http://p.sf.net/sfu/rsa-sfdev2dev2 > _______________________________________________ > Cppcms-users mailing list > Cpp...@li... > https://lists.sourceforge.net/lists/listinfo/cppcms-users |
From: augustin <aug...@ov...> - 2012-01-12 08:19:12
|
On Thursday, January 12, 2012 04:10:37 PM Leon wrote: > 1. How can I upload files using client side javascript (and how to > handle it on server side)? Hi Leon, I am sorry, I don't have any answers for you. Artyom will certainly be able to help you more ;) However, file upload is a topic that regularly comes up on the mailing list. Unfortunately, previous askers didn't bother documenting the answers and the solutions they got. Could you log into the wiki and prepare a placeholder wiki page about file upload? I don't think one exists already, but you can check. You and others will be able to document tips and tricks about file upload. You can search the mailing list, because as I said, the question came up before... Thanks in advance for your contributions. Good luck, Augustin. -- Friends: http://www.reuniting.info/ My projects: http://astralcity.org/ http://3enjeux.overshoot.tv/ http://linux.overshoot.tv/ http://overshoot.tv/ http://charityware.info/ http://masquilier.org/ http://openteacher.info/ http://minguo.info/ http://www.wechange.org/ http://searching911.info/ . |
From: Leon <le...@wl...> - 2012-01-12 08:10:55
|
Hi, Thank you for the great framework! I have some questions regarding jsonrpc. 1. How can I upload files using client side javascript (and how to handle it on server side)? 2. The sample jsonrpc server functions all take built-in types as parameters. Can structures or classes be used as parameters? 3. How can I generate api reference for my jsonrpc service? 4. Is there any recommended way for authentication/security? Thanks, Lirong |
From: chenshu <csf...@gm...> - 2012-01-08 14:20:55
|
My web page is complex.And I believe this problem is nothing to do with CppCMS framework after debugging my application.The home page's html codes have been sent to browser but the Chromium finds some "Uncaught Invalid JSON" error. So thank you and sorry to waste your time. :) On 01/08/2012 10:02 PM, Artyom Beilis wrote: > I can't see what is going on in this HTML mess. > > I can't understand if you have header: > > Location: http://localhost:8081/kaimei/user_home > > And according to the log it is redirected to > > GET http://localhost:8081/kaimei/user_home > > So what is the problem? > > Once again give me an output of Wget's log in "TEXT" not HTML. > > Also according to the log it should work. > > Also setting high debug level for CppCMS web server will help to > see incoming URLs. > > > > Artyom Beilis > -------------- > CppCMS - C++ Web Framework: http://cppcms.sf.net/ > CppDB - C++ SQL Connectivity: http://cppcms.sf.net/sql/cppdb/ > > ------------------------------------------------------------------------ > *From:* ?? <csf...@gm...> > *To:* Artyom Beilis <art...@ya...>; > cpp...@li... > *Sent:* Sunday, January 8, 2012 3:49 PM > *Subject:* Re: [Cppcms-users] Can't jump to another page from > server side > > Hello,Artyom: > It's easy to retrieve detail via Chromium debug mode. > > 1. > > > Request URL: > http://localhost:8081/kaimei/create_account > 2. > > > Request Method: > POST > 3. > > > Status Code: > [302 Found] > > > 302 Found > 4. Request Headersview parsed > 1. POST /kaimei/create_account HTTP/1.1 > Host: localhost:8081 > Connection: keep-alive > Content-Length: 33 > Origin: http://localhost:8081 > X-Requested-With: XMLHttpRequest > User-Agent: Mozilla/5.0 (X11; Linux i686) > AppleWebKit/535.2 (KHTML, like Gecko) Ubuntu/11.10 > Chromium/15.0.874.106 Chrome/15.0.874.106 Safari/535.2 > Content-Type: application/x-www-form-urlencoded > Accept: */* > Referer: http://localhost:8081/kaimei/register > Accept-Encoding > <http://localhost:8081/kaimei/register%0AAccept-Encoding>: > gzip,deflate,sdch > Accept-Language: en-US,en;q=0.8 > Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3 > Cookie: cppcms_session=Id308630366b70e1e8950182a3389874a > 5. Form Dataview URL encoded > 1. > > > email: > cd...@gm... <mailto:cd...@gm...> > 2. > > > pwd: > 123456 > 6. Response Headersview source > 1. > > > Connection: > close > 2. > Content-Encoding: > > > gzip > 3. > > > Content-Type: > text/html; charset=utf-8 > 4. > > > Location: > http://localhost:8081/kaimei/user_home > 5. > > > Server: > CppCMS-Embedded/0.99.11 > 6. > > > Set-Cookie: > cppcms_session=Id308630366b70e1e8950182a3389874a; > Max-Age=600; Path=/; Version=1 > 7. > > > Status: > 302 Found > 8. > X-Powered-By: > > > CppCMS/0.99.11 > > > > > > > > 1. > > > Request URL: > http://localhost:8081/kaimei/user_home > 2. > > > Request Method: > GET > 3. > > > Status Code: > [200 Ok] > > > 200 Ok > 4. Request Headersview source > 1. > > > Accept: > */* > 2. > Accept-Charset: > > > ISO-8859-1,utf-8;q=0.7,*;q=0.3 > 3. > > > Accept-Encoding: > gzip,deflate,sdch > 4. > > > Accept-Language: > en-US,en;q=0.8 > 5. > > > Connection: > keep-alive > 6. > > > Cookie: > cppcms_session=Id308630366b70e1e8950182a3389874a > 7. > > > Host: > localhost:8081 > 8. > > > Referer: > http://localhost:8081/kaimei/register > 9. > > > User-Agent: > Mozilla/5.0 (X11; Linux i686) AppleWebKit/535.2 (KHTML, > like Gecko) Ubuntu/11.10 Chromium/15.0.874.106 > Chrome/15.0.874.106 Safari/535.2 > 10. > > > X-Requested-With: > XMLHttpRequest > 5. Response Headersview source > 1. > > > Connection: > close > 2. > Content-Encoding: > > > gzip > 3. > > > Content-Type: > text/html; charset=utf-8 > 4. > > > Server: > CppCMS-Embedded/0.99.11 > 5. > > > X-Powered-By: > CppCMS/0.99.11 > > > > ?? > Best regards > http://blog.csdn.net/sheismylife > > > On Sun, Jan 8, 2012 at 5:11 PM, Artyom Beilis <art...@ya... > <mailto:art...@ya...>> wrote: > > Can you send a headers that are returned by the web server, > for example > simulate the request with wget > > wget -d http://some/url > > And provide output (-d debug - prints all headers) > > So we can see what is send by the server. > > > Artyom Beilis > -------------- > CppCMS - C++ Web Framework: http://cppcms.sf.net/ > CppDB - C++ SQL Connectivity: http://cppcms.sf.net/sql/cppdb/ > > ------------------------------------------------------------------------ > *From:* ?? <csf...@gm... > <mailto:csf...@gm...>> > *To:* Artyom Beilis <art...@ya... > <mailto:art...@ya...>>; > cpp...@li... > <mailto:cpp...@li...> > *Sent:* Sunday, January 8, 2012 10:38 AM > *Subject:* Re: [Cppcms-users] Can't jump to another page > from server side > > Hello,Artyom: > Please see my comments below. > > ?? > Best regards > http://blog.csdn.net/sheismylife > > > On Sun, Jan 8, 2012 at 3:48 PM, Artyom Beilis > <art...@ya... <mailto:art...@ya...>> wrote: > > 1. Are you sure you call > response().set_redirect_header(...) beforeyou call > response().out()? Because this is likely the reason it > may not work. > > >> yes. > > > 2. Show me the code :-) > > My codes looks like so: > > kaimei_web_site::kaimei_web_site(cppcms::service > &srv):cppcms::application(srv){ > //web page > dispatcher().assign("/welcome" , > &kaimei_web_site::welcome , this , 1); //first page > dispatcher().assign("/register" , > &kaimei_web_site::register_client , this , 2); //register > a new account on this page > .... > //restful web method called by Javascript form client-side > dispatcher().assign("/send_email" , > &kaimei_web_site::save_email , this , 7); > dispatcher().assign("/create_account?(.+)" , > &kaimei_web_site::create_account , this , 8); > .... > > } > > //render the register html page for user > void kaimei_web_site::register_client(std::string url){ > BOOSTER_INFO("kaimei_web_site") << "enter > register_client function"; > init_session(); > > string language = this->session().get("language"); > language_cache& cache = > app_singleton_holder::Instance().cache(); > content::welcome_content content = > cache.get(language).clone_welcome_content(); > configuration& config = > app_singleton_holder::Instance().config(); > content.base_uri=config.base_uri; > content.jsonp= config.jsonp; > render("create_account","create_account_view",content); > } > > > void kaimei_web_site::create_account(std::string str){ > try{ > init_session(); > string email = request().post().find("email")->second; > string pwd = request().post().find("pwd")->second; > user_manager::create_account(email,pwd); > string language = this->session().get("language"); > > shared_ptr<web_user> user = user_manager::login(email,pwd); > if(user){ > BOOSTER_INFO("kaimei_web_site") << "login succeeded"; > this->session()["email"]=user->email; > this->session()["user_id"]=user->oid; > configuration& config = > app_singleton_holder::Instance().config(); > response().set_redirect_header(config.jsonp + > "/user_home"); //I try to redirect to new page but failed > }else{ > kaimei::response res; > res.message="Login failed!"; > res.status=kaimei::response::LOGIN_ERROR; > response().out()<<cppcms::json::value(res); > } > }catch(std::exception &ex){ > kaimei::response res; > res.message=ex.what(); > res.status=kaimei::response::CREATE_ACCOUNT_ERROR; > response().out()<<cppcms::json::value(res); > } > } > > the real value of config.jsonp > (gdb) p config.jsonp > $1 = {static npos = <optimized out>, _M_dataplus = > {<std::allocator<char>> = > {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, > <No data fields>}, _M_p = 0x80c6e24 > "http://localhost:8081/kaimei"}} > > > 3. Small example that reproduces the problem. > > >>I can create it if necessary,but need some hours. > > 4. What is the web server you are using, what protocol? > (some web servers like nginx, do not handle Status > header properly over SCGI protocol). > > > >> In my development environment,I just use cppcms and > HTTP protocol. > > Artyom Beilis > -------------- > CppCMS - C++ Web Framework: http://cppcms.sf.net/ > CppDB - C++ SQL Connectivity: > http://cppcms.sf.net/sql/cppdb/ > > ------------------------------------------------------------------------ > *From:* ?? <csf...@gm... > <mailto:csf...@gm...>> > *To:* cpp...@li... > <mailto:cpp...@li...> > *Sent:* Sunday, January 8, 2012 9:30 AM > *Subject:* [Cppcms-users] Can't jump to another > page from server side > > Hello, > I tried response().set_redirect_header(...) > function ,but it doesn't work. > If one user registers his/her account into my > web site successfully,the page will jump to user's > home page automatically. > > ?? > Best regards > http://blog.csdn.net/sheismylife > > ------------------------------------------------------------------------------ > Ridiculously easy VDI. With Citrix VDI-in-a-Box, > you don't need a complex > infrastructure or vast IT resources to deliver > seamless, secure access to > virtual desktops. With this all-in-one solution, > easily deploy virtual > desktops for less than the cost of PCs and save > 60% on VDI infrastructure > costs. Try it free! > http://p.sf.net/sfu/Citrix-VDIinabox > _______________________________________________ > Cppcms-users mailing list > Cpp...@li... > <mailto:Cpp...@li...> > https://lists.sourceforge.net/lists/listinfo/cppcms-users > > > > ------------------------------------------------------------------------------ > Ridiculously easy VDI. With Citrix VDI-in-a-Box, you > don't need a complex > infrastructure or vast IT resources to deliver > seamless, secure access to > virtual desktops. With this all-in-one solution, > easily deploy virtual > desktops for less than the cost of PCs and save 60% on > VDI infrastructure > costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox > _______________________________________________ > Cppcms-users mailing list > Cpp...@li... > <mailto:Cpp...@li...> > https://lists.sourceforge.net/lists/listinfo/cppcms-users > > > > ------------------------------------------------------------------------------ > Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't > need a complex > infrastructure or vast IT resources to deliver seamless, > secure access to > virtual desktops. With this all-in-one solution, easily > deploy virtual > desktops for less than the cost of PCs and save 60% on VDI > infrastructure > costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox > _______________________________________________ > Cppcms-users mailing list > Cpp...@li... > <mailto:Cpp...@li...> > https://lists.sourceforge.net/lists/listinfo/cppcms-users > > > > ------------------------------------------------------------------------------ > Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't > need a complex > infrastructure or vast IT resources to deliver seamless, > secure access to > virtual desktops. With this all-in-one solution, easily deploy > virtual > desktops for less than the cost of PCs and save 60% on VDI > infrastructure > costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox > _______________________________________________ > Cppcms-users mailing list > Cpp...@li... > <mailto:Cpp...@li...> > https://lists.sourceforge.net/lists/listinfo/cppcms-users > > > > > > > ------------------------------------------------------------------------------ > Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex > infrastructure or vast IT resources to deliver seamless, secure access to > virtual desktops. With this all-in-one solution, easily deploy virtual > desktops for less than the cost of PCs and save 60% on VDI infrastructure > costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox > > > _______________________________________________ > Cppcms-users mailing list > Cpp...@li... > https://lists.sourceforge.net/lists/listinfo/cppcms-users |
From: Artyom B. <art...@ya...> - 2012-01-08 14:03:08
|
I can't see what is going on in this HTML mess. I can't understand if you have header: Location: http://localhost:8081/kaimei/user_home And according to the log it is redirected to GET http://localhost:8081/kaimei/user_home So what is the problem? Once again give me an output of Wget's log in "TEXT" not HTML. Also according to the log it should work. Also setting high debug level for CppCMS web server will help to see incoming URLs. Artyom Beilis -------------- CppCMS - C++ Web Framework: http://cppcms.sf.net/ CppDB - C++ SQL Connectivity: http://cppcms.sf.net/sql/cppdb/ >________________________________ > From: 陈抒 <csf...@gm...> >To: Artyom Beilis <art...@ya...>; cpp...@li... >Sent: Sunday, January 8, 2012 3:49 PM >Subject: Re: [Cppcms-users] Can't jump to another page from server side > > >Hello,Artyom: > It's easy to retrieve detail via Chromium debug mode. > > > > 1. > >Request URL:http://localhost:8081/kaimei/create_account > 2. > >Request Method:POST > 3. > >Status Code: > >302 Found > 4. Request Headersview parsed > 1. POST /kaimei/create_account HTTP/1.1 >Host: localhost:8081 >Connection: keep-alive >Content-Length: 33 >Origin: http://localhost:8081 >X-Requested-With: XMLHttpRequest >User-Agent: Mozilla/5.0 (X11; Linux i686) AppleWebKit/535.2 (KHTML, like Gecko) Ubuntu/11.10 Chromium/15.0.874.106 Chrome/15.0.874.106 Safari/535.2 >Content-Type: application/x-www-form-urlencoded >Accept: */* >Referer: http://localhost:8081/kaimei/register >Accept-Encoding: gzip,deflate,sdch >Accept-Language: en-US,en;q=0.8 >Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3 >Cookie: cppcms_session=Id308630366b70e1e8950182a3389874a > 5. Form Dataview URL encoded > 1. > >email:cd...@gm... > 2. > >pwd:123456 > 6. Response Headersview source > 1. > >Connection:close > 2. Content-Encoding: > >gzip > 3. > >Content-Type:text/html; charset=utf-8 > 4. > >Location:http://localhost:8081/kaimei/user_home > 5. > >Server:CppCMS-Embedded/0.99.11 > 6. > >Set-Cookie:cppcms_session=Id308630366b70e1e8950182a3389874a; Max-Age=600; Path=/; Version=1 > 7. > >Status:302 Found > 8. X-Powered-By: > >CppCMS/0.99.11 > > > > > > > > > > > > > 1. > >Request URL:http://localhost:8081/kaimei/user_home > 2. > >Request Method:GET > 3. > >Status Code: > >200 Ok > 4. Request Headersview source > 1. > >Accept:*/* > 2. Accept-Charset: > >ISO-8859-1,utf-8;q=0.7,*;q=0.3 > 3. > >Accept-Encoding:gzip,deflate,sdch > 4. > >Accept-Language:en-US,en;q=0.8 > 5. > >Connection:keep-alive > 6. > >Cookie:cppcms_session=Id308630366b70e1e8950182a3389874a > 7. > >Host:localhost:8081 > 8. > >Referer:http://localhost:8081/kaimei/register > 9. > >User-Agent:Mozilla/5.0 (X11; Linux i686) AppleWebKit/535.2 (KHTML, like Gecko) Ubuntu/11.10 Chromium/15.0.874.106 Chrome/15.0.874.106 Safari/535.2 > 10. > >X-Requested-With:XMLHttpRequest > 5. Response Headersview source > 1. > >Connection:close > 2. Content-Encoding: > >gzip > 3. > >Content-Type:text/html; charset=utf-8 > 4. > >Server:CppCMS-Embedded/0.99.11 > 5. > >X-Powered-By:CppCMS/0.99.11 > > >陈抒 >Best regards >http://blog.csdn.net/sheismylife > > > >On Sun, Jan 8, 2012 at 5:11 PM, Artyom Beilis <art...@ya...> wrote: > >Can you send a headers that are returned by the web server, for example >>simulate the request with wget >> >> >>wget -d http://some/url >> >> >>And provide output (-d debug - prints all headers) >> >> >>So we can see what is send by the server. >> >> >> >> >> >> >>Artyom Beilis >>-------------- >>CppCMS - C++ Web Framework: http://cppcms.sf.net/ >>CppDB - C++ SQL Connectivity: http://cppcms.sf.net/sql/cppdb/ >> >> >>>________________________________ >>> From: 陈抒 <csf...@gm...> >>>To: Artyom Beilis <art...@ya...>; cpp...@li... >>>Sent: Sunday, January 8, 2012 10:38 AM >>>Subject: Re: [Cppcms-users] Can't jump to another page from server side >>> >>> >>> >>>Hello,Artyom: >>> Please see my comments below. >>>陈抒 >>>Best regards >>>http://blog.csdn.net/sheismylife >>> >>> >>> >>>On Sun, Jan 8, 2012 at 3:48 PM, Artyom Beilis <art...@ya...> wrote: >>> >>>1. Are you sure you call response().set_redirect_header(...) beforeyou call response().out()? Because this is likely the reason it may not work. >>>>> yes. >>> >>>> >>>>2. Show me the code :-) >>>> >>>My codes looks like so: >>> >>> >>>kaimei_web_site::kaimei_web_site(cppcms::service &srv):cppcms::application(srv){ >>> //web page >>> dispatcher().assign("/welcome" , &kaimei_web_site::welcome , this , 1); //first page >>> dispatcher().assign("/register" , &kaimei_web_site::register_client , this , 2); //register a new account on this page >>>.... >>> //restful web method called by Javascript form client-side >>> dispatcher().assign("/send_email" , &kaimei_web_site::save_email , this , 7); >>> dispatcher().assign("/create_account?(.+)" , &kaimei_web_site::create_account , this , 8); >>>.... >>> >>> >>>} >>> >>> >>>//render the register html page for user >>>void kaimei_web_site::register_client(std::string url){ >>> BOOSTER_INFO("kaimei_web_site") << "enter register_client function"; >>> init_session(); >>> >>> >>> string language = this->session().get("language"); >>> language_cache& cache = app_singleton_holder::Instance().cache(); >>> content::welcome_content content = cache.get(language).clone_welcome_content(); >>> configuration& config = app_singleton_holder::Instance().config(); >>> content.base_uri=config.base_uri; >>> content.jsonp= config.jsonp; >>> render("create_account","create_account_view",content); >>>} >>> >>> >>> >>> >>>void kaimei_web_site::create_account(std::string str){ >>> try{ >>>init_session(); >>>string email = request().post().find("email")->second; >>>string pwd = request().post().find("pwd")->second; >>>user_manager::create_account(email,pwd); >>>string language = this->session().get("language"); >>> >>> >>>shared_ptr<web_user> user = user_manager::login(email,pwd); >>>if(user){ >>> BOOSTER_INFO("kaimei_web_site") << "login succeeded"; >>> this->session()["email"]=user->email; >>> this->session()["user_id"]=user->oid; >>> configuration& config = app_singleton_holder::Instance().config(); >>> response().set_redirect_header(config.jsonp + "/user_home"); //I try to redirect to new page but failed >>>}else{ >>> kaimei::response res; >>> res.message="Login failed!"; >>> res.status=kaimei::response::LOGIN_ERROR; >>> response().out()<<cppcms::json::value(res); >>>} >>> }catch(std::exception &ex){ >>>kaimei::response res; >>>res.message=ex.what(); >>>res.status=kaimei::response::CREATE_ACCOUNT_ERROR; >>>response().out()<<cppcms::json::value(res); >>> } >>> >>>} >>> >>> >>>the real value of config.jsonp >>>(gdb) p config.jsonp >>>$1 = {static npos = <optimized out>, _M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, _M_p = 0x80c6e24 "http://localhost:8081/kaimei"}} >>> >>> >>> >>> >>>3. Small example that reproduces the problem. >>>> >>>>>I can create it if necessary,but need some hours. >>> >>>4. What is the web server you are using, what protocol? >>>> (some web servers like nginx, do not handle Status header properly over SCGI protocol). >>>> >>>> >>>> >>>> >>>>> In my development environment,I just use cppcms and HTTP protocol. >>> >>>Artyom Beilis >>>>-------------- >>>>CppCMS - C++ Web Framework: http://cppcms.sf.net/ >>>>CppDB - C++ SQL Connectivity: http://cppcms.sf.net/sql/cppdb/ >>>> >>>> >>>>>________________________________ >>>>> From: 陈抒 <csf...@gm...> >>>>>To: cpp...@li... >>>>>Sent: Sunday, January 8, 2012 9:30 AM >>>>>Subject: [Cppcms-users] Can't jump to another page from server side >>>>> >>>>> >>>>> >>>>>Hello, >>>>> I tried response().set_redirect_header(...) function ,but it doesn't work. >>>>> If one user registers his/her account into my web site successfully,the page will jump to user's home page automatically. >>>>>陈抒 >>>>>Best regards >>>>>http://blog.csdn.net/sheismylife >>>>> >>>>>------------------------------------------------------------------------------ >>>>>Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex >>>>>infrastructure or vast IT resources to deliver seamless, secure access to >>>>>virtual desktops. With this all-in-one solution, easily deploy virtual >>>>>desktops for less than the cost of PCs and save 60% on VDI infrastructure >>>>>costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox >>>>>_______________________________________________ >>>>>Cppcms-users mailing list >>>>>Cpp...@li... >>>>>https://lists.sourceforge.net/lists/listinfo/cppcms-users >>>>> >>>>> >>>>> >>>>------------------------------------------------------------------------------ >>>>Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex >>>>infrastructure or vast IT resources to deliver seamless, secure access to >>>>virtual desktops. With this all-in-one solution, easily deploy virtual >>>>desktops for less than the cost of PCs and save 60% on VDI infrastructure >>>>costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox >>>>_______________________________________________ >>>>Cppcms-users mailing list >>>>Cpp...@li... >>>>https://lists.sourceforge.net/lists/listinfo/cppcms-users >>>> >>>> >>> >>>------------------------------------------------------------------------------ >>>Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex >>>infrastructure or vast IT resources to deliver seamless, secure access to >>>virtual desktops. With this all-in-one solution, easily deploy virtual >>>desktops for less than the cost of PCs and save 60% on VDI infrastructure >>>costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox >>>_______________________________________________ >>>Cppcms-users mailing list >>>Cpp...@li... >>>https://lists.sourceforge.net/lists/listinfo/cppcms-users >>> >>> >>> >>------------------------------------------------------------------------------ >>Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex >>infrastructure or vast IT resources to deliver seamless, secure access to >>virtual desktops. With this all-in-one solution, easily deploy virtual >>desktops for less than the cost of PCs and save 60% on VDI infrastructure >>costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox >>_______________________________________________ >>Cppcms-users mailing list >>Cpp...@li... >>https://lists.sourceforge.net/lists/listinfo/cppcms-users >> >> > > > |
From: 陈抒 <csf...@gm...> - 2012-01-08 13:49:36
|
Hello,Artyom: It's easy to retrieve detail via Chromium debug mode. 1. Request URL: http://localhost:8081/kaimei/create_account 2. Request Method: POST 3. Status Code: 302 Found 4. Request Headersview parsed 1. POST /kaimei/create_account HTTP/1.1 Host: localhost:8081 Connection: keep-alive Content-Length: 33 Origin: http://localhost:8081 X-Requested-With: XMLHttpRequest User-Agent: Mozilla/5.0 (X11; Linux i686) AppleWebKit/535.2 (KHTML, like Gecko) Ubuntu/11.10 Chromium/15.0.874.106 Chrome/15.0.874.106 Safari/535.2 Content-Type: application/x-www-form-urlencoded Accept: */* Referer: http://localhost:8081/kaimei/register Accept-Encoding: gzip,deflate,sdch Accept-Language: en-US,en;q=0.8 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3 Cookie: cppcms_session=Id308630366b70e1e8950182a3389874a 5. Form Dataview URL encoded 1. email: cd...@gm... 2. pwd: 123456 6. Response Headersview source 1. Connection: close 2. Content-Encoding: gzip 3. Content-Type: text/html; charset=utf-8 4. Location: http://localhost:8081/kaimei/user_home 5. Server: CppCMS-Embedded/0.99.11 6. Set-Cookie: cppcms_session=Id308630366b70e1e8950182a3389874a; Max-Age=600; Path=/; Version=1 7. Status: 302 Found 8. X-Powered-By: CppCMS/0.99.11 1. Request URL: http://localhost:8081/kaimei/user_home 2. Request Method: GET 3. Status Code: 200 Ok 4. Request Headersview source 1. Accept: */* 2. Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3 3. Accept-Encoding: gzip,deflate,sdch 4. Accept-Language: en-US,en;q=0.8 5. Connection: keep-alive 6. Cookie: cppcms_session=Id308630366b70e1e8950182a3389874a 7. Host: localhost:8081 8. Referer: http://localhost:8081/kaimei/register 9. User-Agent: Mozilla/5.0 (X11; Linux i686) AppleWebKit/535.2 (KHTML, like Gecko) Ubuntu/11.10 Chromium/15.0.874.106 Chrome/15.0.874.106 Safari/535.2 10. X-Requested-With: XMLHttpRequest 5. Response Headersview source 1. Connection: close 2. Content-Encoding: gzip 3. Content-Type: text/html; charset=utf-8 4. Server: CppCMS-Embedded/0.99.11 5. X-Powered-By: CppCMS/0.99.11 陈抒 Best regards http://blog.csdn.net/sheismylife On Sun, Jan 8, 2012 at 5:11 PM, Artyom Beilis <art...@ya...> wrote: > Can you send a headers that are returned by the web server, for example > simulate the request with wget > > wget -d http://some/url > > And provide output (-d debug - prints all headers) > > So we can see what is send by the server. > > > > Artyom Beilis > -------------- > CppCMS - C++ Web Framework: http://cppcms.sf.net/ > CppDB - C++ SQL Connectivity: http://cppcms.sf.net/sql/cppdb/ > > ------------------------------ > *From:* 陈抒 <csf...@gm...> > *To:* Artyom Beilis <art...@ya...>; > cpp...@li... > *Sent:* Sunday, January 8, 2012 10:38 AM > *Subject:* Re: [Cppcms-users] Can't jump to another page from server side > > Hello,Artyom: > Please see my comments below. > > 陈抒 > Best regards > http://blog.csdn.net/sheismylife > > > On Sun, Jan 8, 2012 at 3:48 PM, Artyom Beilis <art...@ya...> wrote: > > 1. Are you sure you call response().set_redirect_header(...) before you > call response().out()? Because this is likely the reason it may not work. > > >> yes. > > > 2. Show me the code :-) > > My codes looks like so: > > kaimei_web_site::kaimei_web_site(cppcms::service > &srv):cppcms::application(srv){ > //web page > dispatcher().assign("/welcome" , &kaimei_web_site::welcome , this , > 1); //first page > dispatcher().assign("/register" , &kaimei_web_site::register_client , > this , 2); //register a new account on this page > .... > //restful web method called by Javascript form client-side > dispatcher().assign("/send_email" , &kaimei_web_site::save_email , > this , 7); > dispatcher().assign("/create_account?(.+)" , > &kaimei_web_site::create_account , this , 8); > .... > > } > > > //render the register html page for user > void kaimei_web_site::register_client(std::string url){ > BOOSTER_INFO("kaimei_web_site") << "enter register_client function"; > init_session(); > > string language = this->session().get("language"); > language_cache& cache = app_singleton_holder::Instance().cache(); > content::welcome_content content = > cache.get(language).clone_welcome_content(); > configuration& config = app_singleton_holder::Instance().config(); > content.base_uri=config.base_uri; > content.jsonp= config.jsonp; > render("create_account","create_account_view",content); > } > > > void kaimei_web_site::create_account(std::string str){ > try{ > init_session(); > string email = request().post().find("email")->second; > string pwd = request().post().find("pwd")->second; > user_manager::create_account(email,pwd); > string language = this->session().get("language"); > > shared_ptr<web_user> user = user_manager::login(email,pwd); > if(user){ > BOOSTER_INFO("kaimei_web_site") << "login succeeded"; > this->session()["email"]=user->email; > this->session()["user_id"]=user->oid; > configuration& config = app_singleton_holder::Instance().config(); > response().set_redirect_header(config.jsonp + "/user_home"); //I try > to redirect to new page but failed > }else{ > kaimei::response res; > res.message="Login failed!"; > res.status=kaimei::response::LOGIN_ERROR; > response().out()<<cppcms::json::value(res); > } > }catch(std::exception &ex){ > kaimei::response res; > res.message=ex.what(); > res.status=kaimei::response::CREATE_ACCOUNT_ERROR; > response().out()<<cppcms::json::value(res); > } > > } > > the real value of config.jsonp > (gdb) p config.jsonp > $1 = {static npos = <optimized out>, _M_dataplus = {<std::allocator<char>> > = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data > fields>}, _M_p = 0x80c6e24 "http://localhost:8081/kaimei"}} > > > 3. Small example that reproduces the problem. > > >>I can create it if necessary,but need some hours. > > > 4. What is the web server you are using, what protocol? > (some web servers like nginx, do not handle Status header properly > over SCGI protocol). > > > >> In my development environment,I just use cppcms and HTTP protocol. > > > Artyom Beilis > -------------- > CppCMS - C++ Web Framework: http://cppcms.sf.net/ > CppDB - C++ SQL Connectivity: http://cppcms.sf.net/sql/cppdb/ > > ------------------------------ > *From:* 陈抒 <csf...@gm...> > *To:* cpp...@li... > *Sent:* Sunday, January 8, 2012 9:30 AM > *Subject:* [Cppcms-users] Can't jump to another page from server side > > Hello, > I tried response().set_redirect_header(...) function ,but it doesn't > work. > If one user registers his/her account into my web site successfully,the > page will jump to user's home page automatically. > > 陈抒 > Best regards > http://blog.csdn.net/sheismylife > > > ------------------------------------------------------------------------------ > Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex > infrastructure or vast IT resources to deliver seamless, secure access to > virtual desktops. With this all-in-one solution, easily deploy virtual > desktops for less than the cost of PCs and save 60% on VDI infrastructure > costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox > _______________________________________________ > Cppcms-users mailing list > Cpp...@li... > https://lists.sourceforge.net/lists/listinfo/cppcms-users > > > > > ------------------------------------------------------------------------------ > Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex > infrastructure or vast IT resources to deliver seamless, secure access to > virtual desktops. With this all-in-one solution, easily deploy virtual > desktops for less than the cost of PCs and save 60% on VDI infrastructure > costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox > _______________________________________________ > Cppcms-users mailing list > Cpp...@li... > https://lists.sourceforge.net/lists/listinfo/cppcms-users > > > > > ------------------------------------------------------------------------------ > Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex > infrastructure or vast IT resources to deliver seamless, secure access to > virtual desktops. With this all-in-one solution, easily deploy virtual > desktops for less than the cost of PCs and save 60% on VDI infrastructure > costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox > _______________________________________________ > Cppcms-users mailing list > Cpp...@li... > https://lists.sourceforge.net/lists/listinfo/cppcms-users > > > > > ------------------------------------------------------------------------------ > Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex > infrastructure or vast IT resources to deliver seamless, secure access to > virtual desktops. With this all-in-one solution, easily deploy virtual > desktops for less than the cost of PCs and save 60% on VDI infrastructure > costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox > _______________________________________________ > Cppcms-users mailing list > Cpp...@li... > https://lists.sourceforge.net/lists/listinfo/cppcms-users > > |
From: Artyom B. <art...@ya...> - 2012-01-08 09:11:16
|
Can you send a headers that are returned by the web server, for example simulate the request with wget wget -d http://some/url And provide output (-d debug - prints all headers) So we can see what is send by the server. Artyom Beilis -------------- CppCMS - C++ Web Framework: http://cppcms.sf.net/ CppDB - C++ SQL Connectivity: http://cppcms.sf.net/sql/cppdb/ >________________________________ > From: 陈抒 <csf...@gm...> >To: Artyom Beilis <art...@ya...>; cpp...@li... >Sent: Sunday, January 8, 2012 10:38 AM >Subject: Re: [Cppcms-users] Can't jump to another page from server side > > >Hello,Artyom: > Please see my comments below. >陈抒 >Best regards >http://blog.csdn.net/sheismylife > > > >On Sun, Jan 8, 2012 at 3:48 PM, Artyom Beilis <art...@ya...> wrote: > >1. Are you sure you call response().set_redirect_header(...) beforeyou call response().out()? Because this is likely the reason it may not work. >>> yes. > >> >>2. Show me the code :-) >> >My codes looks like so: > > >kaimei_web_site::kaimei_web_site(cppcms::service &srv):cppcms::application(srv){ > //web page > dispatcher().assign("/welcome" , &kaimei_web_site::welcome , this , 1); //first page > dispatcher().assign("/register" , &kaimei_web_site::register_client , this , 2); //register a new account on this page >.... > //restful web method called by Javascript form client-side > dispatcher().assign("/send_email" , &kaimei_web_site::save_email , this , 7); > dispatcher().assign("/create_account?(.+)" , &kaimei_web_site::create_account , this , 8); >.... > > >} > > >//render the register html page for user >void kaimei_web_site::register_client(std::string url){ > BOOSTER_INFO("kaimei_web_site") << "enter register_client function"; > init_session(); > > > string language = this->session().get("language"); > language_cache& cache = app_singleton_holder::Instance().cache(); > content::welcome_content content = cache.get(language).clone_welcome_content(); > configuration& config = app_singleton_holder::Instance().config(); > content.base_uri=config.base_uri; > content.jsonp= config.jsonp; > render("create_account","create_account_view",content); >} > > > > >void kaimei_web_site::create_account(std::string str){ > try{ >init_session(); >string email = request().post().find("email")->second; >string pwd = request().post().find("pwd")->second; >user_manager::create_account(email,pwd); >string language = this->session().get("language"); > > >shared_ptr<web_user> user = user_manager::login(email,pwd); >if(user){ > BOOSTER_INFO("kaimei_web_site") << "login succeeded"; > this->session()["email"]=user->email; > this->session()["user_id"]=user->oid; > configuration& config = app_singleton_holder::Instance().config(); > response().set_redirect_header(config.jsonp + "/user_home"); //I try to redirect to new page but failed >}else{ > kaimei::response res; > res.message="Login failed!"; > res.status=kaimei::response::LOGIN_ERROR; > response().out()<<cppcms::json::value(res); >} > }catch(std::exception &ex){ >kaimei::response res; >res.message=ex.what(); >res.status=kaimei::response::CREATE_ACCOUNT_ERROR; >response().out()<<cppcms::json::value(res); > } > >} > > >the real value of config.jsonp >(gdb) p config.jsonp >$1 = {static npos = <optimized out>, _M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, _M_p = 0x80c6e24 "http://localhost:8081/kaimei"}} > > > > >3. Small example that reproduces the problem. >> >>>I can create it if necessary,but need some hours. > >4. What is the web server you are using, what protocol? >> (some web servers like nginx, do not handle Status header properly over SCGI protocol). >> >> >> >> >>> In my development environment,I just use cppcms and HTTP protocol. > >Artyom Beilis >>-------------- >>CppCMS - C++ Web Framework: http://cppcms.sf.net/ >>CppDB - C++ SQL Connectivity: http://cppcms.sf.net/sql/cppdb/ >> >> >>>________________________________ >>> From: 陈抒 <csf...@gm...> >>>To: cpp...@li... >>>Sent: Sunday, January 8, 2012 9:30 AM >>>Subject: [Cppcms-users] Can't jump to another page from server side >>> >>> >>> >>>Hello, >>> I tried response().set_redirect_header(...) function ,but it doesn't work. >>> If one user registers his/her account into my web site successfully,the page will jump to user's home page automatically. >>>陈抒 >>>Best regards >>>http://blog.csdn.net/sheismylife >>> >>>------------------------------------------------------------------------------ >>>Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex >>>infrastructure or vast IT resources to deliver seamless, secure access to >>>virtual desktops. With this all-in-one solution, easily deploy virtual >>>desktops for less than the cost of PCs and save 60% on VDI infrastructure >>>costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox >>>_______________________________________________ >>>Cppcms-users mailing list >>>Cpp...@li... >>>https://lists.sourceforge.net/lists/listinfo/cppcms-users >>> >>> >>> >>------------------------------------------------------------------------------ >>Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex >>infrastructure or vast IT resources to deliver seamless, secure access to >>virtual desktops. With this all-in-one solution, easily deploy virtual >>desktops for less than the cost of PCs and save 60% on VDI infrastructure >>costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox >>_______________________________________________ >>Cppcms-users mailing list >>Cpp...@li... >>https://lists.sourceforge.net/lists/listinfo/cppcms-users >> >> > >------------------------------------------------------------------------------ >Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex >infrastructure or vast IT resources to deliver seamless, secure access to >virtual desktops. With this all-in-one solution, easily deploy virtual >desktops for less than the cost of PCs and save 60% on VDI infrastructure >costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox >_______________________________________________ >Cppcms-users mailing list >Cpp...@li... >https://lists.sourceforge.net/lists/listinfo/cppcms-users > > > |
From: 陈抒 <csf...@gm...> - 2012-01-08 08:38:30
|
Hello,Artyom: Please see my comments below. 陈抒 Best regards http://blog.csdn.net/sheismylife On Sun, Jan 8, 2012 at 3:48 PM, Artyom Beilis <art...@ya...> wrote: > 1. Are you sure you call response().set_redirect_header(...) before you > call response().out()? Because this is likely the reason it may not work. > >> yes. > > 2. Show me the code :-) > My codes looks like so: kaimei_web_site::kaimei_web_site(cppcms::service &srv):cppcms::application(srv){ //web page dispatcher().assign("/welcome" , &kaimei_web_site::welcome , this , 1); //first page dispatcher().assign("/register" , &kaimei_web_site::register_client , this , 2); //register a new account on this page .... //restful web method called by Javascript form client-side dispatcher().assign("/send_email" , &kaimei_web_site::save_email , this , 7); dispatcher().assign("/create_account?(.+)" , &kaimei_web_site::create_account , this , 8); .... } //render the register html page for user void kaimei_web_site::register_client(std::string url){ BOOSTER_INFO("kaimei_web_site") << "enter register_client function"; init_session(); string language = this->session().get("language"); language_cache& cache = app_singleton_holder::Instance().cache(); content::welcome_content content = cache.get(language).clone_welcome_content(); configuration& config = app_singleton_holder::Instance().config(); content.base_uri=config.base_uri; content.jsonp= config.jsonp; render("create_account","create_account_view",content); } void kaimei_web_site::create_account(std::string str){ try{ init_session(); string email = request().post().find("email")->second; string pwd = request().post().find("pwd")->second; user_manager::create_account(email,pwd); string language = this->session().get("language"); shared_ptr<web_user> user = user_manager::login(email,pwd); if(user){ BOOSTER_INFO("kaimei_web_site") << "login succeeded"; this->session()["email"]=user->email; this->session()["user_id"]=user->oid; configuration& config = app_singleton_holder::Instance().config(); response().set_redirect_header(config.jsonp + "/user_home"); //I try to redirect to new page but failed }else{ kaimei::response res; res.message="Login failed!"; res.status=kaimei::response::LOGIN_ERROR; response().out()<<cppcms::json::value(res); } }catch(std::exception &ex){ kaimei::response res; res.message=ex.what(); res.status=kaimei::response::CREATE_ACCOUNT_ERROR; response().out()<<cppcms::json::value(res); } } the real value of config.jsonp (gdb) p config.jsonp $1 = {static npos = <optimized out>, _M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, _M_p = 0x80c6e24 "http://localhost:8081/kaimei"}} 3. Small example that reproduces the problem. > >>I can create it if necessary,but need some hours. > 4. What is the web server you are using, what protocol? > (some web servers like nginx, do not handle Status header properly > over SCGI protocol). > > > >> In my development environment,I just use cppcms and HTTP protocol. > Artyom Beilis > -------------- > CppCMS - C++ Web Framework: http://cppcms.sf.net/ > CppDB - C++ SQL Connectivity: http://cppcms.sf.net/sql/cppdb/ > > ------------------------------ > *From:* 陈抒 <csf...@gm...> > *To:* cpp...@li... > *Sent:* Sunday, January 8, 2012 9:30 AM > *Subject:* [Cppcms-users] Can't jump to another page from server side > > Hello, > I tried response().set_redirect_header(...) function ,but it doesn't > work. > If one user registers his/her account into my web site successfully,the > page will jump to user's home page automatically. > > 陈抒 > Best regards > http://blog.csdn.net/sheismylife > > > ------------------------------------------------------------------------------ > Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex > infrastructure or vast IT resources to deliver seamless, secure access to > virtual desktops. With this all-in-one solution, easily deploy virtual > desktops for less than the cost of PCs and save 60% on VDI infrastructure > costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox > _______________________________________________ > Cppcms-users mailing list > Cpp...@li... > https://lists.sourceforge.net/lists/listinfo/cppcms-users > > > > > ------------------------------------------------------------------------------ > Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex > infrastructure or vast IT resources to deliver seamless, secure access to > virtual desktops. With this all-in-one solution, easily deploy virtual > desktops for less than the cost of PCs and save 60% on VDI infrastructure > costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox > _______________________________________________ > Cppcms-users mailing list > Cpp...@li... > https://lists.sourceforge.net/lists/listinfo/cppcms-users > > |
From: Artyom B. <art...@ya...> - 2012-01-08 07:49:39
|
1. Are you sure you call response().set_redirect_header(...) beforeyou call response().out()? Because this is likely the reason it may not work. 2. Show me the code :-) 3. Small example that reproduces the problem. 4. What is the web server you are using, what protocol? (some web servers like nginx, do not handle Status header properly over SCGI protocol). Artyom Beilis -------------- CppCMS - C++ Web Framework: http://cppcms.sf.net/ CppDB - C++ SQL Connectivity: http://cppcms.sf.net/sql/cppdb/ >________________________________ > From: 陈抒 <csf...@gm...> >To: cpp...@li... >Sent: Sunday, January 8, 2012 9:30 AM >Subject: [Cppcms-users] Can't jump to another page from server side > > >Hello, > I tried response().set_redirect_header(...) function ,but it doesn't work. > If one user registers his/her account into my web site successfully,the page will jump to user's home page automatically. >陈抒 >Best regards >http://blog.csdn.net/sheismylife > >------------------------------------------------------------------------------ >Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex >infrastructure or vast IT resources to deliver seamless, secure access to >virtual desktops. With this all-in-one solution, easily deploy virtual >desktops for less than the cost of PCs and save 60% on VDI infrastructure >costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox >_______________________________________________ >Cppcms-users mailing list >Cpp...@li... >https://lists.sourceforge.net/lists/listinfo/cppcms-users > > > |
From: 陈抒 <csf...@gm...> - 2012-01-08 07:30:37
|
Hello, I tried response().set_redirect_header(...) function ,but it doesn't work. If one user registers his/her account into my web site successfully,the page will jump to user's home page automatically. 陈抒 Best regards http://blog.csdn.net/sheismylife |
From: augustin <aug...@ov...> - 2012-01-06 08:33:05
|
On Thursday, January 05, 2012 07:02:00 PM Artyom Beilis wrote: > Even thou in general different "skins" are originally > used for "skinning" purposes, it is not a mandatory > way to see the things. Ok. > Now all the above should go to wiki :-) :) Of course! http://art-blog.no-ip.info/wikipp/en/page/cppcms_1x_plugin_architecture > I don't know, 1.0 probably in a month... 1.1 would start immediatly > when it become stable as 1.2 probably few month afterward. Great! :) > >http://art-blog.no-ip.info/wikipp/en/page/cppcms_1x_templates_gen > >I quote from above: > > "Each skin should implement the virtual function render(), > > unless it is already implemented in its parent." > >Do you mean that a skin can have parents?? > >In the wiki page above, you mention a views hierarchy (which, I think, I > >understand) but not a skin hierarchy! > > Ok this is a mistake, I ment "Each view should implemen", skins are > namespaces they do not have inheritence. Fixed. I'll study all of this in the upcoming New Year Holidays, when I'll have more time to code and try to actually implement this. But it's all already much clearer in my head, so I shouldn't have any more problem with this. Thanks for the detailed explanation. Blessings, Augustin. -- Friends: http://www.reuniting.info/ My projects: http://astralcity.org/ http://3enjeux.overshoot.tv/ http://linux.overshoot.tv/ http://overshoot.tv/ http://charityware.info/ http://masquilier.org/ http://openteacher.info/ http://minguo.info/ http://www.wechange.org/ http://searching911.info/ . |
From: augustin <aug...@ov...> - 2012-01-05 15:00:44
|
Artyom, Quick reply before I go to bed: Thanks a lot! I haven't had time to study everything in detail, yet, but I already feel much better now ;) You answered very clearly all my questions, thanks. I'll study further the code examples and add them to the wiki as soon as I can. Thanks, Augustin. |
From: Artyom B. <art...@ya...> - 2012-01-05 11:02:08
|
Hi, First of all before I'll answer any specific points I'll summarize my answer. General Concepts Notes ======================= Skin = namespace View = class Template = class-member-function Even thou in general different "skins" are originally used for "skinning" purposes, it is not a mandatory way to see the things. Each plugin should have its own skin (or namespace) and its content can be rendered they way you need. Limitations =========== Currently cppcms_tmpl_cc does not generate separate h and cpp file and thus you can't derive views (classes) in one skin (namespac) from other. There is other way to reuses "shared-skin", I'll show it later. Making simple plugin ===================== There are two ways to do it. One, related to CppCMS 0.99.11 and other to the latest version in trunk. Lets start with current 0.99.11. Our main page <% skin basic_skin %> <% view basic_view uses content::basic_content %> <html> ... <body> ... <!--- aux part--> <% foreach p in plugings %> <% item %><%= p.rendered_aux_html_content | raw %><% end %> <% end %> ... <!--- Main part--> <% foreach p in plugings %> <% item %> <div id="plugin_<%=p.id %>" > <%= p.rendered_main_html_content | raw %> </div> <% end %> <% end %> ... </body> <% end view %> ... <% end skin %> Now this is what plugin's template should contain <% skin plugin_a %> <% view main_html uses plugin_a_content::some_content_b %> <% template render() %> <!-- Notice render function --> some plugin specific html that does something it needs <% end template %> <% view aux_html uses plugin_a_content::some_content_a %> <% template render() %> <!-- Notice render function --> some plugin specific html that does something it needs <% end template %> <% end view %> Now how we integrate all this. Let's say that our plugin should provide following API class plugin { public: virtual std::string main_html(cppcms::applicatin *app) = 0; virtual std::string aux_html(cppcms::application *app) = 0; }; Now when we render each plugin we do following: main_application.cpp content::basic_content c; // prepare c ... // render plugins for(int i=0;i<loaded_plugins.size();i++) { c.plugins[i].rendered_main_html_content = loaded_plugins[i]->main_html(this); c.plugins[i].rendered_aux_html_content = loaded_plugins[i]->aux_html(this); } render("basic_skin","basic_view",c); And plugin looks like this: std::string main_html(cppcms::applicatin *app) { plugin_a_content::some_content_b c; ... std::ostringstream buf; app->render("plugin_a","main_html",c,buf); return buf.str(); } std::string aux_html(cppcms::applicatin *app) { plugin_a_content::some_content_a c; ... std::ostringstream buf; app->render("plugin_a","aux_html",c,buf); return buf.str(); } That's it... Now in CppCMS 0.99.12 (trunk) you can do following ================================================== There is a new command <% render ... %> http://art-blog.no-ip.info/wikipp/en/page/cppcms_1x_templates_comm#Rendering.other.views Our main page <% skin basic_skin %> <% view basic_view uses content::basic_content %> <html> ... <body> ... <!--- aux part--> <% foreach p in plugings %> <% item %><% render p->name(), "aux_html" with p->aux_html_content() %><% end %> <% end %> ... <!--- Main part--> <% foreach p in plugings %> <% item %> <div id="plugin_<%=p->id() %>" > <% render p->name(), "main_html" with p->main_html_content() %> </div> <% end %> <% end %> ... </body> <% end view %> ... <% end skin %> Where p is actually a pointer to plugin object. Now the plugin skin would look the same. skipping Now how we integrate all this. Let's say that our plugin should provide little bit different api: class plugin { public: virtual void prepare() = 0; virtual cppcms::base_content &main_html_content() = 0; virtual cppcms::base_content &aux_html_content() = 0; virtua std::string name() = 0; }; Now when we render each plugin we do following: basic_content { ... // pointers to plugins std::vector<plugin *> plugins; } main_application.cpp content::basic_content c; // prepare c ... for(p in plugins) p->prepare(); render("basic_skin","basic_view",c); And plugin looks like this: class my_plugin : public plugin { public: virtual void prepare() { ... setup main_ and aux_... } virtual std::string name() { return "plugin_a"; } virtual cppcms::basic_content &main_html_content() { return main_; } virtual cppcms::basic_content &aux_html_content() { return aux_; } private: plugin_a_content::some_content_b aux_; plugin_a_content::some_content_a main_; }; std::string main_html(cppcms::applicatin *app) { plugin_a_content::some_content_b c; ... std::ostringstream buf; app->render("plugin_a","main_html",c,buf); return buf.str(); } std::string aux_html(cppcms::applicatin *app) { plugin_a_content::some_content_a c; ... std::ostringstream buf; app->render("plugin_a","aux_html",c,buf); return buf.str(); } ========================================================== Of course there are more variansts (for 0.99.12/trunk). For example: plugin { void render_main(cppcms::application &); void render_aux(cppcms::application &); } Where plugin executed like render_main(cppcms::application &app) { app.render("plugin_a","main_html",my_content); } And in the template code you cakk <% foreach p in plugins %> <% item %> <% c++ p->render_main(content.app()); %> <% end item %> <% end foreach %> According to your imagination ========================================== Derivation ========================================== Now, reusing a skin. Consider that your plugin wants to extend basic_skin::basic_view (i.e. derive from it). And have control over entire page. It is much more tricky. You can't derive from it as cppcms_tmpl_cc does not generate header files, what you can do is to do follwoing Instead of writing <% skin basic_skin %> You use nameless skin <% skin %> And for example when you compile main skin Main view cpp: cppcms_tmpl_cc -s basic_skin basic_view.tmpl some_other_main_views.tmpl -o basic_skin.cpp g++ basic_skin.cpp -o libbasic_skin.so cppcms_tmpl_cc -s plugin_a basic_view.tmpl plugin_a.tmpl -o plugin_a.cpp g++ plugin_code.cpp plugin_a.cpp -o libplugin_a.so Notice basic_view.tmpl appears twice but once under skin=namespace "basic_skin" and the second time under skin=namespace plugin_a. This copies c++ code, and requires plugin to actually use application's skin code, it is not so good but it is tolerable, at least untill cppcms_tmpl_cc will support generation of h and cpp files. ============================ Now all the above should go to wiki :-) ========================================================== Now particular answers ================================ > >Oh, up to today I have been using 0.99.10. >I see you released 0.99.11 ten days ago: >http://art-blog.no-ip.info/cppcms/blog/post/90 >In your blog, you don't give any details on how / why the views have been >refactored, and the implication, if any, for existing code >(e.g. what is now possible that wasn't before?) > This class was not existing: http://art-blog.no-ip.info/cppcms_ref_v0_99/classcppcms_1_1views_1_1pool.html All the operations on skins should be done via cppcms::application, the code was bad and many parts where declared as private. Now it is publicly usable > > >So, back to my original question: can you guesstimate the release dates for >1.0 and 1.1? >>From yesterday's post, I guesstimate that 1.0.0 RC1 will be released this >month, and the final 1.0.0 in February at the latest >When would the first beta 1.1 be released? Early spring? >And the first 1.1.0 RC? >I don't mind developing against a beta release. I guess it'll be stable enough >for a live release of my own application late this year..... > I don't know, 1.0 probably in a month... 1.1 would start immediatly when it become stable as 1.2 probably few month afterward. > >> On the other hand if I spend now lots of time today on plugin framework >> and tomorrow on other very important feature I'll never release a stable >> version and this is not good for the project. It was in beta stage for >> too long time. > >Well, I was not asking for you to implement the whole plugin framework right >now, before the release 1.0.0. >However, it seems that I am missing a single method in order to complete my >own plugin framework: how to attach new template includes. And again, I am not >the first one to ask about it. > See below. >So, what I was asking is, in terms of additional code before the code freeze, >can we have that extra method to complete our own frameworks? (unless, again, >I am doing things the wrong way, and what I am asking is possible another >way...) > I hope the notes above answer on what you ask. >-- > >I started replying to the rest of your comments, but I guess the discussion >will be clearer if I do my best to state as clearly as possible what I am >after. > > [snip] > > Right now, the > important is that you understand what I am after. > The core of the application is defining the general layout of the template, and > tells where the content from different plugins shall be inserted. > I think example above clarifies this >> Only thing you should care is to make sure each as its own skin name and >> not collide with its other. > >(=> with *each* other) > >Err... This is a major departure from what I was trying to do. Maybe I don't >understand the way you use the term 'skin'. For me, 'skin' refers to the >general look and appearance and colour scheme of the web site. A plugin >implementing a block of content would output this content in a way that's >congruent with the site's skin/theme. > > ... >Again, for me skin == theme. Only one is operative for any page request. >Or do you mean that a single page can be assembled from the output of different >skins? > If you have doughs take a look on skin as separate unit, namespace not certainly the style. >http://art-blog.no-ip.info/wikipp/en/page/cppcms_1x_templates_gen >I quote from above: > "Each skin should implement the virtual function render(), > unless it is already implemented in its parent." >Do you mean that a skin can have parents?? >In the wiki page above, you mention a views hierarchy (which, I think, I >understand) but not a skin hierarchy! > > Ok this is a mistake, I ment "Each view should implemen", skins are namespaces they do not have inheritence. >For reference, my problem appears to me to be very, very similar to that of >Julian Pietron, > > [snip] > > I still fail to see how I can tell each plugin to render their specific >parts according to their own data and own templates, and to pass the result >back to the core application which will render the whole page and send it to >the user. > I think that code above explains it >How would >views_pool::static_instance().render(...) >interact with the core template/view/skin? It was changed since to: cppcms::views::pool::instance().render(skin_name,view_name,content,output_stream) It would render: a view in skin using content to the stream :-) I home it is clear now. > > >> > 4. Note: you can't load and unload two plugins simultaneously as it would >> > not be thread safe, > >I don't understand what you mean by "loading two plugins simultaneously". > I think it is out of date note. > >Basically, what follows is the implementation side of the simple example I >posted above: > >// core content.hpp >struct main : public cppcms::base_content { > std::string title; > std::string content; >} > >// plugin: plugin_content.hpp >#include "core/content.hpp" >namespace content { >struct example_page : public main { > std::string my_test; >}; >} // namespace content. > >As you see, the plugin content are sub-classes of the main content. See examples above. >In the thread mentioned above, Julian asked: > > [snip] > > >which obviously registers the view within the pool. > >And what I was originally asking, is a method to add a template to an already >registered skin/view. Not possible to do it directly today. See a workaround above. You need to create a new skin and reuse some templates. > >> > 2) On the other hand, you seemed to say that it was not possible, because >> > it was difficult to do it right, especially considering race conditions >> > in a multi- threaded web server, leading to a crash when one thread is >> > trying to render a sub-template from a plugin that was just disabled in >> > another thread. >> >> The cppcms::views::pool::render(...) is thread safe >> as it holds shared lock during any rendering process. If you >> would try to unload a skin during this period you would be blocked >> till **all** rendering operations will complete and >> then you'll be able to load/unload the view > >Julian asked: > >> > Would it be possible to register a view at runtime? > >You replied: > >> > Not sure. It would required making views loading >> > and unloading be thread safe and make the interaction >> > with actual DLL quite complicated. > > >But that was 18 months ago, so maybe things have changed since then... > DLLs are supported, and views loading is thread safe now. >If I can achieve the end result above, then I would have passed a very major >hurdle. > >Sorry for being slow to catch up with you, and for the length of this email. > I think the example above provides the solution. Correct me if I wrong. >Thanks, as always, > >Augustin. > > Best Regards, Artyom |
From: <un...@fu...> - 2012-01-04 17:12:31
|
On Wed, 4 Jan 2012 22:55:53 +0800, augustin wrote: > The above example is at its simplest: only one plugin at a time is > affecting > the output. It starts to get trickier when the whole html page is > divided into > a random number regions and different plugins are responsible for the > content > of each region. maybe we should divide this into 2 parts - plugins & components (as defined here http://doc.nette.org/en/presenters). for me, components are more important than automatic reloading. i'm working on "persistent parameters" and components, but it's still too ugly. pavel. |
From: augustin <aug...@ov...> - 2012-01-04 15:26:50
|
Hi, Thanks for your detailed reply. I apologise for the length of this email, but things are so confused to me at this stage, that I though too much information and redundant information may be better than too little. And I thank you for your time spend reading and replying! On Tuesday, January 03, 2012 06:12:02 PM Artyom Beilis wrote: > - Full rewrite of templates loading API (0.99.11) > which by the way would make modules generation much > easier. Oh, up to today I have been using 0.99.10. I see you released 0.99.11 ten days ago: http://art-blog.no-ip.info/cppcms/blog/post/90 In your blog, you don't give any details on how / why the views have been refactored, and the implication, if any, for existing code (e.g. what is now possible that wasn't before?) > So once 1.0.0 is released there would be immediately created a new > beta version 1.1 that would receive new features and once it is stabilized > it would be released as stable version 1.2 while 1.0.0 would receive > only bug fix updates (1.0.1, 1.0.2 etc). > > So the release frequency would be high and plugin support would > be scheduled according to its priority (which is high BTW) Ok, thanks. I understand the reasons for such a long release schedule to 1.0.0. (and I certainly wasn't complaining about it! ;) ) So, back to my original question: can you guesstimate the release dates for 1.0 and 1.1? From yesterday's post, I guesstimate that 1.0.0 RC1 will be released this month, and the final 1.0.0 in February at the latest When would the first beta 1.1 be released? Early spring? And the first 1.1.0 RC? I don't mind developing against a beta release. I guess it'll be stable enough for a live release of my own application late this year..... > > There seems to be a fairly large demand for a plugin framework. Several > > people have already mentioned it on this list. Fortunately, we can roll > > out our own without waiting for CPPCMS 1.1. However, I counted at least > > three different people, maybe four, who brought the same issue over the > > last 12~18 months, and I would be the fifth person to do so. > > Small notes. Today CppCMS provides all the basics for support of plugins. > > Templates are already fully pluggable, load shared object and you > get your template in place. > > Also there is a new booster::shared_object class that allows to load > dynamic libraries easily. OK. As I told you earlier, I have already implemented my own plugin framework, but since I was following unrelated tutorials found on the web, it's very possible I made things more complicated than they needed to be. On the other hand, I learned a lot that way! ;) > On the other hand if I spend now lots of time today on plugin framework > and tomorrow on other very important feature I'll never release a stable > version and this is not good for the project. It was in beta stage for > too long time. Well, I was not asking for you to implement the whole plugin framework right now, before the release 1.0.0. However, it seems that I am missing a single method in order to complete my own plugin framework: how to attach new template includes. And again, I am not the first one to ask about it. See below. So, what I was asking is, in terms of additional code before the code freeze, can we have that extra method to complete our own frameworks? (unless, again, I am doing things the wrong way, and what I am asking is possible another way...) -- I started replying to the rest of your comments, but I guess the discussion will be clearer if I do my best to state as clearly as possible what I am after. Assume I only want to implement one single theme for my web site, i.e. one 'skin' (one single layout, one colour scheme, etc.). Let's call this unique skin: my_skin. I want the HTML output to be very simple, as follows: <!DOCTYPE etc... > <html> <head> title, metas, links here. </head> <body> <div id="top_menu"> home | blog | etc </div> <div id="page_content"> (insert content here) </div> </body> </html> Let's say the core of the application defines the general layout and a core .tmpl file declares the headers, the top_menu div like this: <% c++ #include "content.hpp" %> <% xhtml %> <% skin my_skin %> <% view page uses content::page %> <% template render() %> <html> <head> title, metas, links here. </head> <body> <div id="top_menu"> home | blog | etc </div> <% include main_content() %> </body> </html> <% end template %> <% end view %> <% end skin %> Now, the content of <div id="page_content"> is defined in each plugin. When the application starts, the revelant plugins are loaded (no problem). The plugins each register their own paths to the router (no problem). Depending on the user request, the corresponding methods in the relevant plugin is called (no problem). Each plugin implement its own .tmpl file as follows: <% skin my_skin %> <%view example_page uses content::example_page extends main %> <% template main_content() %> <p>This is the content output by this plugin.</p> <%= content | raw %> <% end template %> <% end view %> <% end skin %> We'll discuss below the details of the implementation. Right now, the important is that you understand what I am after. The core of the application is defining the general layout of the template, and tells where the content from different plugins shall be inserted. The above example is at its simplest: only one plugin at a time is affecting the output. It starts to get trickier when the whole html page is divided into a random number regions and different plugins are responsible for the content of each region. > > It seems that independently from each other, we all were confronted with > > the same issue, namely: how does a plugin register a single part of a > > larger template which is implemented by the core application? > > Simple: > > Each template shared object has global constructor and destructor. > Once shared object is loaded, constructor is called and it registers > itself in cppcms::views::pool singleton and become visible for everybody. > When it is unloaded it is unregistered via global destructor and can't > be used any more. It is simple and transparent semantics. > > > Let's say we have a core application which implements a common template > > (skin). And we have several plugins, each implementing a functionality, > > e.g. a block of content with its own specific HTML markup > > (sub-template). The core of the application does not know in advance > > what additional sub-templates the plugins will implement, and plugins do > > not know what other plugins need. Basically, what each of us were trying > > to do is to 'attach' a > > sub-template to the core main template. And we all hit the problem that > > you don't offer an API to do so. > > If the plugin is linked with the template code it would loads its own > template: > > libmy_plugin.so > my_application.cpp > // my code > { > ... > render("my_plugin_skin","some_view",some_content); > } > my_view.cpp <- my_view.tmpl > // this code is auto-generated > namespace { > struct loader { > loader() { > cppcms::views::pool::instance().add(my_skin_generator()); } ~loader() { > cppcms::views::pool::instance().remove(my_skin_generator()); } } > loader_instance; > } > > So once you load shared object loader::loader() is executed > and registers a view > and when you unload the shared object loader::~loader() > unregisters it. Hmmmm... I've read all of the above a dozen times, been pondering its relevance, and I still can't decide whether it's you who don't understand my question or if it's me who don't understand the answer. If hope my simple case scenario above is helping... > Only thing you should care is to make sure each as its own skin name and > not collide with its other. (=> with *each* other) Err... This is a major departure from what I was trying to do. Maybe I don't understand the way you use the term 'skin'. For me, 'skin' refers to the general look and appearance and colour scheme of the web site. A plugin implementing a block of content would output this content in a way that's congruent with the site's skin/theme. So, in my plugins, their templates use the same skin name as the core templates. It compiles, but it's useless! Semantically, it's the same skin. And I fail how using different skin names will solve my problem. The most likely explanation is that I don't yet fully grasp the the proper uses of 'skins' and 'views' or their respective meaning, but it seems to me that you're telling me that each plugin should implement a whole skins. http://art-blog.no-ip.info/wikipp/en/page/cppcms_1x_templates_gen I quote from above: "Each skin should implement the virtual function render(), unless it is already implemented in its parent." Do you mean that a skin can have parents?? In the wiki page above, you mention a views hierarchy (which, I think, I understand) but not a skin hierarchy! Again, for me skin == theme. Only one is operative for any page request. Or do you mean that a single page can be assembled from the output of different skins? For reference, my problem appears to me to be very, very similar to that of Julian Pietron, in the second half of the thread "Plugins and templates", from August 19th~23rd 2010. He wrote: > > Would it be possible to register a view at runtime? As I see in the code > > generated of cppcms_tmpl_cc, the template loader registers the skin > > alongside with a mapping_type that contains the name of view and the > > appropriate handler class / the result of passing it together with the > > required content object to view_builder. > > So could you add a call like > > cppcms::views_pool::static_instance::extend_view("skin","view > >name",&cppcms::views_pool::view_builder<skin::view_class,content::master>); > > that I could call in the constructor of my plugin? > > I would then compile the output of cppcms_tmpl_cc excluding the loader > > to my shared object and could add the required views at runtime to > > cppcms view_pool. > > It would be good if there also was a call like reduce_view("skin","view > > name"); just to remove a view when plugin is unloaded. Over the last year, I have read that thread dozens of times, and I referred to it in my previous email. But I still don't understand the solution; I am even confused as to whether there IS a solution or not! :-/ You gave him the same solution (Aug 20th 2010) as you gave me, but something still does not add up for me. (sorry to be dense!) In that email, you wrote: > > 3. In the plugin itself you can use > > views_pool::static_instance().render(...) > > to render the view. I have been looking at the different overloaded functions render(...): http://art-blog.no- ip.info/cppcms_ref_v0_99/classcppcms_1_1application.html#a46054c0f0e55b2638cc73fc8eb07fe4f and I still fail to see how I can tell each plugin to render their specific parts according to their own data and own templates, and to pass the result back to the core application which will render the whole page and send it to the user. How would views_pool::static_instance().render(...) interact with the core template/view/skin? > > 4. Note: you can't load and unload two plugins simultaneously as it would > > not be thread safe, I don't understand what you mean by "loading two plugins simultaneously". > > We can manually create a header file for the sub .tmpl file (part of the > > plugin), so that the template at least compiles, but then the core > > application is not aware of it and doesn't use it. > > I don't really understand what are you trying to say in the paragraph > above. I would have sworn that another user asked the very same question fairly recently but I have gone through the whole 2011 archives and earlier, and couldn't find it. Basically, what follows is the implementation side of the simple example I posted above: // core content.hpp struct main : public cppcms::base_content { std::string title; std::string content; } // plugin: plugin_content.hpp #include "core/content.hpp" namespace content { struct example_page : public main { std::string my_test; }; } // namespace content. As you see, the plugin content are sub-classes of the main content. In the thread mentioned above, Julian asked: >> it would be nice if cppcms_tmpl_cc could be modified to >> generate a header file alongside the cpp, so that I can easily include >> it into my plugin and you denied it (certainly for very good reasons). Anyhow, I got to manually re-create the header for the core content.cpp, so that I could include it in my plugin's template page (as shown above). Thus the code compiles: one skin shared between core and the various plugins. A core content class with sub-content classes within plugins. However, cppcms_tmpl_cc output .cpp files, at the bottom of which one finds code like this: namespace { cppcms::views::generator my_generator; struct loader { loader() { my_generator.name("my_view"); my_generator.add_view<my_view::page,content::page>("page",true); my_generator.add_view<my_view::main,content::main>("main",true); my_generator.add_view<my_view::system_error,content::system_error>("system_error",true); my_generator.add_view<my_view::page_form,content::page_form>("page_form",true); my_generator.add_view<my_view::configure_plugins,content::configure_plugins>("configure_plugins",true); cppcms::views::pool::instance().add(my_generator); } ~loader() { cppcms::views::pool::instance().remove(my_generator); } } a_loader; } // anon which obviously registers the view within the pool. And what I was originally asking, is a method to add a template to an already registered skin/view. I.e. I am looking for a way to tell the core view that a certain function (implemented in the base view class) has been replaced by another function with the same name in the derived class. Anyway... this was how I attempted to do it. From what you keep telling us, I have the nagging feeling that I use the wrong approach, but, please forgive me, I still can't grok the proper approach to take. Also, I checked the "plugin implementation" that kpeo posted in November but: 1) I can't use it because of licensing issues. 2) It doesn't seem to answer my problem anyway, as it seems to skirt around the very issue that's causing me a headache by not implementing what I'm after! > > I didn't fully understand all of your answers, though I tried and read > > them many times. From what I understood, your answer was two-fold: > > > > 1) On one hand you say that the plugin can recompile the whole skin and > > load it at run time. Maybe there is a need to properly document this > > because I didn't fully understand how to do so, and how a plugin would > > be aware of all > > > > the other sub-templates implemented by the other plugins. > > See the example above. Also plugin should not "recompile" the skin > in the run time... It can do it you need to implement "recompilation" > on your own. The skin is compiled beforehand at the same time as the plugin. What I'm trying to do at run time is let core know that a certain piece of template should be inserted at its proper place within a larger skin. > > 2) On the other hand, you seemed to say that it was not possible, because > > it was difficult to do it right, especially considering race conditions > > in a multi- threaded web server, leading to a crash when one thread is > > trying to render a sub-template from a plugin that was just disabled in > > another thread. > > The cppcms::views::pool::render(...) is thread safe > as it holds shared lock during any rendering process. If you > would try to unload a skin during this period you would be blocked > till **all** rendering operations will complete and > then you'll be able to load/unload the view Julian asked: > > Would it be possible to register a view at runtime? You replied: > > Not sure. It would required making views loading > > and unloading be thread safe and make the interaction > > with actual DLL quite complicated. But that was 18 months ago, so maybe things have changed since then... > However if you want to load/unload **application** classes > it is totally different story... I there is no support > of dynamic **unloading** of CppCMS applications, only templates. I only have one application, which is core. Core is then supposed to pass one relevant data to plugins which are then responsible to output specific blocks of content within a large page. I can already dynamically load/unload plugins at run time, which is the whole point ;) > > So, my request is thus: > > > > a) If what we are trying to implement is fully possible today, can the > > proper solution be documented? > > Yes... indeed. I think this e-mail content should go to the wiki. > (after some notes below) You know me: I always like it when I can help in some small ways, and unlike other people here, I have contributed what I could to the wiki. Unfortunately, at this time, I am still in the dark about your answer.... :-/ > > b) If not, some projects will not be able to wait until the release of > > CPPCMS 1.1 (see questions at the top). Could you at least implement in > > 1.0 some stop- gap measure that would be usable for our purposes, even > > if not completely ideal? > > Today it should be implementable and not even hard at all. Well, I am glad to hear that, at least :) > Can you please provide a sample use case where: > > a) You describe a simple application with several plugins. > > How do they interact (what calls what, how are they mounted) > > b) For each plugin and the application what templates does it > render > > c) what content does they uses. > > d) How dynamic do you want it to be (when loaded, unloaded, etc) > To complete the simple example I gave at the top, here is what I have and what I want. - I have a single cppcms application, which is the core of the application. - Core defines a polymorphic plugins class which is NOT a CPPCMS related class. - A couple of key methods in that class are pure virtual methods. - Each plugin is expected to implement a derived class, obviously implemeting the pure virtual methods of the base class, together with any other methods the plugin might need. - I have implemented my own loading/unloading of plugins at runtime, according to values saved in a database, as set the administrator (basically, there is a plugin administration form, and the administrator chooses which plugins he wants enabled, and the core system saves the values and load/unload the plugins accordingly). All of the above work well, although I'm sure you're going to tell me I was not supposed to implement it this way!! :-s - I have a single skin, the base of which is defined by core. - Core is controlling the general layout of the page. - Each plugin is supposed to define a variable number of blocks of content to insert into the skin, according to templates defined in plugins, and compiled at the same time. Now, let me rephrase my earlier simple example, to make it look more like it should in a real case scenario. The HTML would look this way: <!DOCTYPE etc... > <html> <head> title, metas, links here. </head> <body> <div id="content_of_block_1"> (content from plugin 1 here) </div> <div id="content_of_block_2"> (content from plugin 2 here) </div> <div id="content_of_block_3"> (content from plugin 3 here) </div> <div id="content_of_block_4"> (content from plugin 4 here) </div> .... <div id="content_of_block_n"> (content from plugin n here) </div> </body> </html> It's obviously schematized, but it should give you the main idea. The core template would look somehow like this: <% c++ #include "content.hpp" %> <% xhtml %> <% skin my_skin %> <% view page uses content::page %> <% template render() %> <html> <head> title, metas, links here. </head> <body> <% foreach block in content::blocks %> <% item %> <div id="conent_of_block_<%= block.id %>"> <%= block.content %> </div> <% end %> <%end %> </body> </html> <% end template %> <% end view %> <% end skin %> where obviously, each block.content is defined in its own template at the plugin level, as stated above: <% skin my_skin %> <%view example_page uses content::example_page extends main %> <% template main_content() %> <p>This is the content output by this plugin.</p> <%= content | raw %> <% end template %> <% end view %> <% end skin %> If I can achieve the end result above, then I would have passed a very major hurdle. Sorry for being slow to catch up with you, and for the length of this email. Thanks, as always, Augustin. -- Friends: http://www.reuniting.info/ My projects: http://astralcity.org/ http://3enjeux.overshoot.tv/ http://linux.overshoot.tv/ http://overshoot.tv/ http://charityware.info/ http://masquilier.org/ http://openteacher.info/ http://minguo.info/ http://www.wechange.org/ http://searching911.info/ . |
From: Artyom B. <art...@ya...> - 2012-01-03 10:12:14
|
> From: augustin <aug...@ov...> > > In reply both to your December 18th email regarding documentation requests, > and to yesterday's email regarding the looming code freeze, I'd like to > bring > up an issue that has been discussed several times on this list. > Ok > I know that a plugin framework is planned for CPPCMS 1.1. Can you guesstimate > when such a release would take place? One year from now? Two years from > now...? Maybe more? > I'll explain. CppCMS project started about 4 years ago and 3 years ago the first stable version was released. However it was soon become clear that in order to move forward major deep internal changes should be done: - Redesign concurrency model - which brings COMET support - Redesign API they way it would be much easier to maintain and it would be able to keep backward compatibility - Redesign 1001 other things like dropping CgiCC and Boost dependency And that was CppCMS 1.x.x that went to Beta stage as 0.99.1 in June 2010. It required a lots of work and thanks to this it become what it is today a popular C++ web development framework. The long period (year and a half) of beta testing was required for two things: 1. Make sure that the API is clear stable and fits the needs. This allowed me to change the API if I felt it was not good, for example: - Full rewrite of templates loading API (0.99.11) which by the way would make modules generation much easier. - XSS prevention (0.99.10) - Performance improvements in JSON handling (0.99.9) - Localization API redesign (0.99.8) And more... 2. Once stable version is released I would not have a privilege to change API in backward incompatible way. That is why there was a long beta testing - the testing of the API. From all other points view the framework was stable, tested actively, released frequently. So once 1.0.0 is released there would be immediately created a new beta version 1.1 that would receive new features and once it is stabilized it would be released as stable version 1.2 while 1.0.0 would receive only bug fix updates (1.0.1, 1.0.2 etc). So the release frequency would be high and plugin support would be scheduled according to its priority (which is high BTW) So 1.1 and 1.2 releases would be **very** different from 0.0.x -> 1.0.0 because that was almost complete refactoring of the code base that had bring CppCMS to what it is today, while 1.0 -> 1.2 is just a new features that are introduced to the framework. So you should not worry about "keeping CppCMS" unmodified for years > There seems to be a fairly large demand for a plugin framework. Several people > have already mentioned it on this list. Fortunately, we can roll out our own > without waiting for CPPCMS 1.1. However, I counted at least three different > people, maybe four, who brought the same issue over the last 12~18 months, and > I would be the fifth person to do so. > Small notes. Today CppCMS provides all the basics for support of plugins. Templates are already fully pluggable, load shared object and you get your template in place. Also there is a new booster::shared_object class that allows to load dynamic libraries easily. On the other hand if I spend now lots of time today on plugin framework and tomorrow on other very important feature I'll never release a stable version and this is not good for the project. It was in beta stage for too long time. > It seems that independently from each other, we all were confronted with the > same issue, namely: how does a plugin register a single part of a larger > template which is implemented by the core application? > Simple: Each template shared object has global constructor and destructor. Once shared object is loaded, constructor is called and it registers itself in cppcms::views::pool singleton and become visible for everybody. When it is unloaded it is unregistered via global destructor and can't be used any more. It is simple and transparent semantics. > Let's say we have a core application which implements a common template > (skin). And we have several plugins, each implementing a functionality, e.g. a > block of content with its own specific HTML markup (sub-template). The core of > the application does not know in advance what additional sub-templates the > plugins will implement, and plugins do not know what other plugins need. > Basically, what each of us were trying to do is to 'attach' a > sub-template to the core main template. And we all hit the problem that you don't offer an > API to do so. If the plugin is linked with the template code it would loads its own template: libmy_plugin.so my_application.cpp // my code { ... render("my_plugin_skin","some_view",some_content); } my_view.cpp <- my_view.tmpl // this code is auto-generated namespace { struct loader { loader() { cppcms::views::pool::instance().add(my_skin_generator()); } ~loader() { cppcms::views::pool::instance().remove(my_skin_generator()); } } loader_instance; } So once you load shared object loader::loader() is executed and registers a view and when you unload the shared object loader::~loader() unregisters it. Only thing you should care is to make sure each as its own skin name and not collide with its other. > > We can manually create a header file for the sub .tmpl file (part of the > plugin), so that the template at least compiles, but then the core application > is not aware of it and doesn't use it. > I don't really understand what are you trying to say in the paragraph above. > I didn't fully understand all of your answers, though I tried and read them > many times. From what I understood, your answer was two-fold: > > 1) On one hand you say that the plugin can recompile the whole skin and load > it at run time. Maybe there is a need to properly document this because I > didn't fully understand how to do so, and how a plugin would be aware of all > > the other sub-templates implemented by the other plugins. See the example above. Also plugin should not "recompile" the skin in the run time... It can do it you need to implement "recompilation" on your own. You are probably misguided by the "automatic skin" reload support that can be used for development. Where setting an option "reload" would check if the shared object had changed and reload it. > > 2) On the other hand, you seemed to say that it was not possible, because it > was difficult to do it right, especially considering race conditions in a multi- > threaded web server, leading to a crash when one thread is trying to render a > sub-template from a plugin that was just disabled in another thread. > The cppcms::views::pool::render(...) is thread safe as it holds shared lock during any rendering process. If you would try to unload a skin during this period you would be blocked till **all** rendering operations will complete and then you'll be able to load/unload the view However if you want to load/unload **application** classes it is totally different story... I there is no support of dynamic **unloading** of CppCMS applications, only templates. > So, my request is thus: > > a) If what we are trying to implement is fully possible today, can the proper > solution be documented? > Yes... indeed. I think this e-mail content should go to the wiki. (after some notes below) > b) If not, some projects will not be able to wait until the release of CPPCMS > 1.1 (see questions at the top). Could you at least implement in 1.0 some stop- > gap measure that would be usable for our purposes, even if not completely > ideal? > Today it should be implementable and not even hard at all. > Let me know if you want me to dig up the discussion threads where those topics > have already been raised. Can you please provide a sample use case where: a) You describe a simple application with several plugins. How do they interact (what calls what, how are they mounted) b) For each plugin and the application what templates does it render c) what content does they uses. d) How dynamic do you want it to be (when loaded, unloaded, etc) I'll show how and what could be done today and would is not possible. And you could write down it in the wiki :-) till I get more time to implement plugin framework. > Thanks, > > Augustin. > > Regards, Artyom |
From: augustin <aug...@ov...> - 2012-01-03 03:28:49
|
Artyom, In reply both to your December 18th email regarding documentation requests, and to yesterday's email regarding the looming code freeze, I'd like to bring up an issue that has been discussed several times on this list. I know that a plugin framework is planned for CPPCMS 1.1. Can you guesstimate when such a release would take place? One year from now? Two years from now...? Maybe more? There seems to be a fairly large demand for a plugin framework. Several people have already mentioned it on this list. Fortunately, we can roll out our own without waiting for CPPCMS 1.1. However, I counted at least three different people, maybe four, who brought the same issue over the last 12~18 months, and I would be the fifth person to do so. It seems that independently from each other, we all were confronted with the same issue, namely: how does a plugin register a single part of a larger template which is implemented by the core application? Let's say we have a core application which implements a common template (skin). And we have several plugins, each implementing a functionality, e.g. a block of content with its own specific HTML markup (sub-template). The core of the application does not know in advance what additional sub-templates the plugins will implement, and plugins do not know what other plugins need. Basically, what each of us were trying to do is to 'attach' a sub-template to the core main template. And we all hit the problem that you don't offer an API to do so. We can manually create a header file for the sub .tmpl file (part of the plugin), so that the template at least compiles, but then the core application is not aware of it and doesn't use it. I didn't fully understand all of your answers, though I tried and read them many times. From what I understood, your answer was two-fold: 1) On one hand you say that the plugin can recompile the whole skin and load it at run time. Maybe there is a need to properly document this because I didn't fully understand how to do so, and how a plugin would be aware of all the other sub-templates implemented by the other plugins. 2) On the other hand, you seemed to say that it was not possible, because it was difficult to do it right, especially considering race conditions in a multi- threaded web server, leading to a crash when one thread is trying to render a sub-template from a plugin that was just disabled in another thread. So, my request is thus: a) If what we are trying to implement is fully possible today, can the proper solution be documented? b) If not, some projects will not be able to wait until the release of CPPCMS 1.1 (see questions at the top). Could you at least implement in 1.0 some stop- gap measure that would be usable for our purposes, even if not completely ideal? Let me know if you want me to dig up the discussion threads where those topics have already been raised. Thanks, Augustin. -- Friends: http://www.reuniting.info/ My projects: http://astralcity.org/ http://3enjeux.overshoot.tv/ http://linux.overshoot.tv/ http://overshoot.tv/ http://charityware.info/ http://masquilier.org/ http://openteacher.info/ http://minguo.info/ http://www.wechange.org/ http://searching911.info/ . |
From: Artyom B. <art...@ya...> - 2012-01-02 14:11:56
|
Hello, All RC1 tasks are now complete: http://art-blog.no-ip.info/wikipp/en/page/cppcms_1x_tasks So I'm going to code freeze very soon in order to release first "Release Candidate" so no backward incompatible changes would be done. If you have last minute request it is better to bring them **now** Hopefully, the stable version - with stabilized API and ABI would be released. Best Regards, Artyom Beilis -------------- CppCMS - C++ Web Framework: http://cppcms.sf.net/ CppDB - C++ SQL Connectivity: http://cppcms.sf.net/sql/cppdb/ |
From: Sergey <dan...@gm...> - 2012-01-02 10:00:33
|
to author: Спасибо уже нашел to all: Or: <% foreach t in vector %> <% item %> <%= t->key() %> <% end item %> <% end %> |
From: kpeo <sla...@ya...> - 2012-01-02 09:35:35
|
Hello, Template framework for foreach block has an iterators: <% foreach s rowid i in some %> See: http://cppcms.sourceforge.net/wikipp/en/page/cppcms_1x_templates_flow#Foreach.block 02.01.2012, 12:43, "Sergey" <dan...@gm...>: > data/ > std::vector<some_class *> some; > > apps/ > data::some_content c; > c.success.push_back(&some); > > tmpl/ > <% foreach s in some %> > <% item %><%= s.key() %><% end %> > <% end %> > > Of course i need like that <%= s[i].key() %> > Anyway it does not work > > Anybody have solution? > > ------------------------------------------------------------------------------ > Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex > infrastructure or vast IT resources to deliver seamless, secure access to > virtual desktops. With this all-in-one solution, easily deploy virtual > desktops for less than the cost of PCs and save 60% on VDI infrastructure > costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox > _______________________________________________ > Cppcms-users mailing list > Cpp...@li... > https://lists.sourceforge.net/lists/listinfo/cppcms-users |