cppcms-users Mailing List for CppCMS C++ Web Framework
Brought to you by:
artyom-beilis
Menu
▾
▴
cppcms-users — Disussions of users of CppCMS
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: Varstray Pl <var...@gm...> - 2022-05-24 15:57:18
|
I'm slowly building a website that consists of multiple component apps, each placed inside of their own root directory. The filesystem structure is as follows: (Assume "/" is the webserver root.) Inside "/" is the top-level application, "klt". Underneath root, we have the following directories: /static/ /attach/ "/static/" is what you'd expect. Inside "/attach/", are symbolic links to each sub-application's home directories, which holds templates, *.cpp and *.hpp files, as well as the application binary and an application specific config.js file. How would I go about building everything into a single purpose application hierarchy? I want each sub-application to be able to function completely on its own as well as part of a unit. e.g. I can compile each sub-application by itself and have it run on a web-server independently of the others. But also compile the top-level application to include all the sub-applications, and have them all work as a unit under "klt" app. Do I try and compile all the templates from all applications at once? Then compile all the app.cpp files together with their app_skin.cpp and app_content.hpp files Do I have to specify the location of each cpp file explicitly when compiling, since they are in different directories, and g++ wouldn't know where to look for them in that case? Please note, that I'm in the process of debugging, and this is an old project. So there's A LOT of other issues with compilation and linking that I'm slowly working through. As a result, I can't test this directly and be sure that any issues are with my build system's approach vs other issues in the code directly. So, before I spend huge amounts of time doing the wrong thing, I would like to get some help about what the best way to build this setup actually would be. Additional Info: 1. My build system is actually currently pretty jank at the moment. I eventually want to use autoconf. So any autoconf specific advice would be helpful and appreciated. 2. Originally making sure each sub-application could function as a web app on it's own was a high priority. That's no longer the case. So if it actually would be far easier to just "dump everything into a single directory", then I'm... willing to accept that. Though keeping things in separate directories would also help keep things organized. So I'm not entirely sure the best way to go. Thank you very much for your time. :D |
|
From: Pierre C. <pi...@co...> - 2022-04-23 09:25:10
|
Thank you. My mistake is not having understood the link between widgets::file and "underlying" http::file. On 4/22/22 17:17, Artyom Beilis wrote: > Use cppcms::http::file::filename > > http://cppcms.com/cppcms_ref/latest/classcppcms_1_1http_1_1file.html#aec7aaa5ab4f57aada988507d5d299f6f > > Artyom > > > On Fri, Apr 22, 2022 at 3:12 PM Pierre Couderc via Cppcms-users > <cpp...@li...> wrote: > > I have been warned, I should not use supplied file name in a > widget::file... > > But I want it anyway, how should I get it...? > > Thanks again for cppcms ! > > PC > > > > _______________________________________________ > Cppcms-users mailing list > Cpp...@li... > https://lists.sourceforge.net/lists/listinfo/cppcms-users > > > > _______________________________________________ > Cppcms-users mailing list > Cpp...@li... > https://lists.sourceforge.net/lists/listinfo/cppcms-users |
|
From: Artyom B. <art...@gm...> - 2022-04-22 15:18:05
|
Use cppcms::http::file::filename http://cppcms.com/cppcms_ref/latest/classcppcms_1_1http_1_1file.html#aec7aaa5ab4f57aada988507d5d299f6f Artyom On Fri, Apr 22, 2022 at 3:12 PM Pierre Couderc via Cppcms-users < cpp...@li...> wrote: > I have been warned, I should not use supplied file name in a > widget::file... > > But I want it anyway, how should I get it...? > > Thanks again for cppcms ! > > PC > > > > _______________________________________________ > Cppcms-users mailing list > Cpp...@li... > https://lists.sourceforge.net/lists/listinfo/cppcms-users > |
|
From: Pierre C. <pi...@co...> - 2022-04-22 12:12:19
|
I have been warned, I should not use supplied file name in a widget::file... But I want it anyway, how should I get it...? Thanks again for cppcms ! PC |
|
From: Nazim C. <nz...@pr...> - 2021-10-19 19:40:55
|
Hello, >> I might try to setup a generator but I don't fully grasp how these work >> so if there is somebody who would like to team up on this I'd be glad >> to hear from you. > > You are more than welcome to try and contribute the code to the project. If it's required, I can implement lexical analyser (with re2c) and parser (with Yacc/Hyacc) for the specification on my free time (mostly Saturdays). After that is complete, generator may be implemented by just writing appropriate semantic actions of the parser. But of course, I would need document which gives detailed explanation of OpenAPI. What kind of generator could benefit everyone? Best regards, Nazim Can. |
|
From: Artyom B. <art...@gm...> - 2021-09-18 08:55:07
|
> I noticed the item for an OpenApi Generator on the Roadmap on > cppcms.com and I wanted to ask if somebody is currently working on > this. No, at least not that I'm aware of. Closest targets to implement are WebSockets support and multiple-event loops. I'm very busy and progress is slow... > > I am currently working on an API and in the decision phase for the tech > to use and would very much appreciate if there would exist a generator > for cppcms. > I clearly understand importance but unfortunately I'm not that familiar with OpenAPI so I can even estimate the amount and type of work needed. > I might try to setup a generator but I don't fully grasp how these work > so if there is somebody who would like to team up on this I'd be glad > to hear from you. You are more than welcome to try and contribute the code to the project. > > Cheers, > Martin > > Regards, Artyom Beilis |
|
From: Martin B. <mar...@gm...> - 2021-09-18 06:58:42
|
Hello, I noticed the item for an OpenApi Generator on the Roadmap on cppcms.com and I wanted to ask if somebody is currently working on this. I am currently working on an API and in the decision phase for the tech to use and would very much appreciate if there would exist a generator for cppcms. I might try to setup a generator but I don't fully grasp how these work so if there is somebody who would like to team up on this I'd be glad to hear from you. Cheers, Martin |
|
From: Pierre C. <pi...@co...> - 2021-09-15 17:25:26
|
Thnk you ! Sure. My mistake. On 9/15/21 2:43 PM, Artyom Beilis wrote: > You need to rebuild cppcns/app on new system with relevant icu versions > > Artyom > > > בתאריך יום ד׳, 15 בספט׳ 2021, 11:44, מאת Pierre Couderc via > Cppcms-users <cpp...@li... > <mailto:cpp...@li...>>: > > Trying to migrate a cppcms application to bullseye debian, I am > blocked > by : > > /usr/bin/ld: warning: libicuuc.so.63, needed by > /usr/local/lib/libbooster.so, not found (try using -rpath or > -rpath-link) > /usr/bin/ld: warning: libicui18n.so.63, needed by > /usr/local/lib/libbooster.so, not found (try using -rpath or > -rpath-link) > > I have libicuuc but it is libicuuc.so.67. > > What is the best practice to correct...? > > Thanks. > > PC > > |
|
From: Artyom B. <art...@gm...> - 2021-09-15 12:43:27
|
You need to rebuild cppcns/app on new system with relevant icu versions Artyom בתאריך יום ד׳, 15 בספט׳ 2021, 11:44, מאת Pierre Couderc via Cppcms-users < cpp...@li...>: > Trying to migrate a cppcms application to bullseye debian, I am blocked > by : > > /usr/bin/ld: warning: libicuuc.so.63, needed by > /usr/local/lib/libbooster.so, not found (try using -rpath or -rpath-link) > /usr/bin/ld: warning: libicui18n.so.63, needed by > /usr/local/lib/libbooster.so, not found (try using -rpath or -rpath-link) > > I have libicuuc but it is libicuuc.so.67. > > What is the best practice to correct...? > > Thanks. > > PC > > > > _______________________________________________ > Cppcms-users mailing list > Cpp...@li... > https://lists.sourceforge.net/lists/listinfo/cppcms-users > |
|
From: Pierre C. <pi...@co...> - 2021-09-15 08:43:44
|
Trying to migrate a cppcms application to bullseye debian, I am blocked by : /usr/bin/ld: warning: libicuuc.so.63, needed by /usr/local/lib/libbooster.so, not found (try using -rpath or -rpath-link) /usr/bin/ld: warning: libicui18n.so.63, needed by /usr/local/lib/libbooster.so, not found (try using -rpath or -rpath-link) I have libicuuc but it is libicuuc.so.67. What is the best practice to correct...? Thanks. PC |
|
From: Pierre C. <pi...@co...> - 2021-09-15 08:34:49
|
I just did declare a new compiler /usr/local/bin/cppcms_tmpl_cc3 : #!/bin/sh python3 /usr/local/bin/cppcms_tmpl_cc $@ Thank you very much ! PC On 9/15/21 7:08 AM, Artyom Beilis wrote: > Unfortunately there is no shebang that fits both python and python3. > Just instead of calling the executable directly, call python3 > cppcms_tmpl_cc specifying an interpreter manually. > > Artyom > > On Wed, Sep 15, 2021 at 12:36 AM Pierre Couderc via Cppcms-users > <cpp...@li... > <mailto:cpp...@li...>> wrote: > > After some update (debian), I get an error : > > [1/9] Generating templ with a custom command > FAILED: templates.cpp > /usr/local/bin/cppcms_tmpl_cc ../templates/master.tmpl > ../templates/ddefault.tmpl ../templates/llist.tmpl > ../templates/question.tmpl ../admin/templates/ad_recup.tmpl > ../admin/templates/ad_sql.tmpl (...) -o templates.cpp > /usr/bin/env: ‘python’: No such file or directory > > Is it because my pithon has gone to python3...? > > Thanks > > PC > > > > > > _______________________________________________ > Cppcms-users mailing list > Cpp...@li... > <mailto:Cpp...@li...> > https://lists.sourceforge.net/lists/listinfo/cppcms-users > <https://lists.sourceforge.net/lists/listinfo/cppcms-users> > > > > _______________________________________________ > Cppcms-users mailing list > Cpp...@li... > https://lists.sourceforge.net/lists/listinfo/cppcms-users |
|
From: Artyom B. <art...@gm...> - 2021-09-15 05:08:40
|
Unfortunately there is no shebang that fits both python and python3. Just instead of calling the executable directly, call python3 cppcms_tmpl_cc specifying an interpreter manually. Artyom On Wed, Sep 15, 2021 at 12:36 AM Pierre Couderc via Cppcms-users < cpp...@li...> wrote: > After some update (debian), I get an error : > > [1/9] Generating templ with a custom command > FAILED: templates.cpp > /usr/local/bin/cppcms_tmpl_cc ../templates/master.tmpl > ../templates/ddefault.tmpl ../templates/llist.tmpl > ../templates/question.tmpl ../admin/templates/ad_recup.tmpl > ../admin/templates/ad_sql.tmpl (...) -o templates.cpp > /usr/bin/env: ‘python’: No such file or directory > > Is it because my pithon has gone to python3...? > > Thanks > > PC > > > > > > _______________________________________________ > Cppcms-users mailing list > Cpp...@li... > https://lists.sourceforge.net/lists/listinfo/cppcms-users > |
|
From: Pierre C. <pi...@co...> - 2021-09-14 21:35:33
|
After some update (debian), I get an error : [1/9] Generating templ with a custom command FAILED: templates.cpp /usr/local/bin/cppcms_tmpl_cc ../templates/master.tmpl ../templates/ddefault.tmpl ../templates/llist.tmpl ../templates/question.tmpl ../admin/templates/ad_recup.tmpl ../admin/templates/ad_sql.tmpl (...) -o templates.cpp /usr/bin/env: ‘python’: No such file or directory Is it because my pithon has gone to python3...? Thanks PC |
|
From: Artyom B. <art...@gm...> - 2021-09-14 20:24:10
|
Hello cppcms users, I migrated web server to uptodate ubuntu 20.04 I noticed there are glitcheckes with table of content for wikipp I'll handle it later. If you see any issues with cppcms.com or blog.cppcms.com update me please. Additional notes: apt.cppcms.com was removed as it isn't up-to-date any more and I can't provide deb packaged for distributions. Artyom |
|
From: Jon F. <jon...@jf...> - 2021-06-15 17:25:01
|
I'm just checking in to see how the Beta is going. Anybody have anything good, bad or ugly to report? I'm thinking about giving this a test drive on a site I've been developing for a while. TIA - Jon -- Sent from my Devuan Linux workstation -- https://devuan.org/ "Init Freedom", Yeah! Jon Foster JF Possibilities, Inc. jo...@jf... |
|
From: <jo...@em...> - 2021-04-06 10:57:04
|
Thank you for this information, Artyom! Best regards, ~ Joel From: Artyom Beilis <art...@gm...> Sent: Friday, 19 March 2021 21:24 To: cpp...@li... Subject: Re: [Cppcms-users] Compile templates into several "view libraries" Yes plugin can, Take a look there: http://cppcms.com/wikipp/en/page/cppcms_1_2_plugin_api In general you can compile view together with the plugin an load it dynamically Artyom On Tue, Mar 16, 2021 at 3:19 AM <jo...@em... <mailto:jo...@em...> > wrote: Hello folks, I am starting to prepare a skeleton for a larger web-platform we’re planning to build that will be based on CppCMS. Due to the size of the application I want to split different modules into different modules. To illustrate this, imagine something like a collaboration platform. It has different functionalities such as: * Task management * Repository/code management * Knowledge base / Wiki * Q & A * Chats * … >From a code structural point of view I’d like each of these features to be plugins in forms of shared libraries (*.so, *.dll, *.dynlib, …). The main application will provide a plugin interface to implement the different functionalities. To achieve this properly, a plugin should be able to provide everything including the various views (compiled CppCMS templates). The main application will then load the plugins and provide menu items in the main navigation so the user can jump to those functionalities. My question: Is there a way that each plugin can compile its own templates with the template compiler? As I see things right now the template compiler needs to know all the templates (views?) What I want is that each plugin compiles its own templates into the C++ views code and then provides that to the main application via the plugin interface. Unfortunately, I was unable to figure out whether this can be achieved – and if so how. Is there a technical limitation that prevents me from achieving this? I saw the documentation of “Dynamic Loading of Views” but as far as I understand that does not really cover my use case as it seems like all the templates/views need to be known when running the compiler. Best regards, ~ Joel Bodenmann _______________________________________________ Cppcms-users mailing list Cpp...@li... <mailto:Cpp...@li...> https://lists.sourceforge.net/lists/listinfo/cppcms-users |
|
From: Jon F. <jon...@jf...> - 2021-03-31 19:00:30
|
Done! Fixed! If anyone else cares. - Jon On 03/29/2021 01:22 PM, Jon Foster wrote: > For anyone else who might care: This weekend I chased this back to the > MySQL backend. The MySQL client library loses all "prepared" queries when > the connection drops and they aren't made again when its auto-reconnected. > The C++DB backend thinks the query is still there and tries to re-use it > causing the "disconnect" error to act as if its being cached. I'll have to > fix this. > > -Jon > > > On 03/25/2021 10:43 AM, Jon Foster wrote: >> This isn't specifically a C++CMS query. I'm using C++DB with C++CMS and >> FLTK to query a MariaDB server. With other languages and tools I can tell >> the client library to auto-reconnect and it does. From the C++DB docs I >> should be able to append ";opt_reconnect=1" to the connection string and it >> should auto-reconnect. But this has not been reliable, where in other tools >> it is. My test FLTK app, which doesn't use a connection pool, will fail >> after the idle timeout set in the server (1hr in this case) and *never* >> reconnect. My C++CMS apps which use connection pooling kind of work but I >> still get random 500s and logs telling me "MySQL went away". Fortunately it >> seems to mostly re-connect if I hit another page and then come back to the >> one that broke. >> >> But I *HATE* random fails in my projects. I'm not a "80% of the time it >> works 100% of the time" kind of guy. So! Is there an easy fix for this? Am >> I misinterpreting the docs and writing that option wrong? Or do I just need >> to dig into the source and force that client option? I'm not even sure why >> its an option. ;-) Anyhow I can't go live with a real C++CMS website and >> have this happening. >> >> Versions: >> >> C++DB: 0.3.1 >> MariaDB: 10.0.38 & 10.2.25 >> G++: 4.9.2 >> >> TIA, >> Jon >> >> -- Sent from my Devuan Linux workstation -- https://devuan.org/ "Init Freedom", Yeah! Jon Foster JF Possibilities, Inc. jo...@jf... |
|
From: Jon F. <jon...@jf...> - 2021-03-29 20:22:51
|
For anyone else who might care: This weekend I chased this back to the MySQL backend. The MySQL client library loses all "prepared" queries when the connection drops and they aren't made again when its auto-reconnected. The C++DB backend thinks the query is still there and tries to re-use it causing the "disconnect" error to act as if its being cached. I'll have to fix this. -Jon On 03/25/2021 10:43 AM, Jon Foster wrote: > This isn't specifically a C++CMS query. I'm using C++DB with C++CMS and > FLTK to query a MariaDB server. With other languages and tools I can tell > the client library to auto-reconnect and it does. From the C++DB docs I > should be able to append ";opt_reconnect=1" to the connection string and it > should auto-reconnect. But this has not been reliable, where in other tools > it is. My test FLTK app, which doesn't use a connection pool, will fail > after the idle timeout set in the server (1hr in this case) and *never* > reconnect. My C++CMS apps which use connection pooling kind of work but I > still get random 500s and logs telling me "MySQL went away". Fortunately it > seems to mostly re-connect if I hit another page and then come back to the > one that broke. > > But I *HATE* random fails in my projects. I'm not a "80% of the time it > works 100% of the time" kind of guy. So! Is there an easy fix for this? Am > I misinterpreting the docs and writing that option wrong? Or do I just need > to dig into the source and force that client option? I'm not even sure why > its an option. ;-) Anyhow I can't go live with a real C++CMS website and > have this happening. > > Versions: > > C++DB: 0.3.1 > MariaDB: 10.0.38 & 10.2.25 > G++: 4.9.2 > > TIA, > Jon > > -- Sent from my Devuan Linux workstation -- https://devuan.org/ "Init Freedom", Yeah! Jon Foster JF Possibilities, Inc. jo...@jf... |
|
From: Jon F. <jon...@jf...> - 2021-03-25 18:23:38
|
This isn't specifically a C++CMS query. I'm using C++DB with C++CMS and FLTK to query a MariaDB server. With other languages and tools I can tell the client library to auto-reconnect and it does. From the C++DB docs I should be able to append ";opt_reconnect=1" to the connection string and it should auto-reconnect. But this has not been reliable, where in other tools it is. My test FLTK app, which doesn't use a connection pool, will fail after the idle timeout set in the server (1hr in this case) and *never* reconnect. My C++CMS apps which use connection pooling kind of work but I still get random 500s and logs telling me "MySQL went away". Fortunately it seems to mostly re-connect if I hit another page and then come back to the one that broke. But I *HATE* random fails in my projects. I'm not a "80% of the time it works 100% of the time" kind of guy. So! Is there an easy fix for this? Am I misinterpreting the docs and writing that option wrong? Or do I just need to dig into the source and force that client option? I'm not even sure why its an option. ;-) Anyhow I can't go live with a real C++CMS website and have this happening. Versions: C++DB: 0.3.1 MariaDB: 10.0.38 & 10.2.25 G++: 4.9.2 TIA, Jon -- Sent from my Devuan Linux workstation -- https://devuan.org/ "Init Freedom", Yeah! Jon Foster JF Possibilities, Inc. jo...@jf... |
|
From: Artyom B. <art...@gm...> - 2021-03-19 20:24:03
|
Yes plugin can, Take a look there: http://cppcms.com/wikipp/en/page/cppcms_1_2_plugin_api In general you can compile view together with the plugin an load it dynamically Artyom On Tue, Mar 16, 2021 at 3:19 AM <jo...@em...> wrote: > Hello folks, > > > > I am starting to prepare a skeleton for a larger web-platform we’re > planning to build that will be based on CppCMS. > > > > Due to the size of the application I want to split different modules into > different modules. > > To illustrate this, imagine something like a collaboration platform. It > has different functionalities such as: > > - Task management > - Repository/code management > - Knowledge base / Wiki > - Q & A > - Chats > - … > > > > From a code structural point of view I’d like each of these features to be > plugins in forms of shared libraries (*.so, *.dll, *.dynlib, …). > > The main application will provide a plugin interface to implement the > different functionalities. > > To achieve this properly, a plugin should be able to provide everything > including the various views (compiled CppCMS templates). The main > application will then load the plugins and provide menu items in the main > navigation so the user can jump to those functionalities. > > > > My question: Is there a way that each plugin can compile its own templates > with the template compiler? As I see things right now the template compiler > needs to know all the templates (views?) > > What I want is that each plugin compiles its own templates into the C++ > views code and then provides that to the main application via the plugin > interface. > > > > Unfortunately, I was unable to figure out whether this can be achieved – > and if so how. > > Is there a technical limitation that prevents me from achieving this? > > > > I saw the documentation of “Dynamic Loading of Views” but as far as I > understand that does not really cover my use case as it seems like all the > templates/views need to be known when running the compiler. > > > > > > Best regards, > > ~ Joel Bodenmann > _______________________________________________ > Cppcms-users mailing list > Cpp...@li... > https://lists.sourceforge.net/lists/listinfo/cppcms-users > |
|
From: Artyom B. <art...@gm...> - 2021-03-19 20:19:50
|
Beast is very low level library. It is build around heavily templated library Boost.Asio. As an example I remember you need to compile templated code to make it work with SSL and basic HTTP. Also It misses basic things like sessions, form validation security framework etc. CppCMS provides much higher level api and both synchronous and asynchronous paradigms I'm Boost developer. Boost.Locale and Boost.Nowide were taken from CppCMS. I voted No for Beast during the review but I was in minority Artyom On Tue, Mar 16, 2021 at 3:47 AM <jo...@em...> wrote: > Hello folks! > > > > I’ve been working with boost::beast for the last year. This is basically a > boost-based library built on top of boost::asio to provide HTTP and > websocket functionalities. > > I was curious about CppCMS and played around with it a little for a few > days. > > The gist of this paragraph: I am new to CppCMS and mildly familiar working > with boost::beast. > > > > I would be interested to hear from the CppCMS community where you see > advantages of using CppCMS over boost::beast for building a > collaboration-tool website. > > Unlike CppCMS, boost::beast does not provide a template engine/mechanism > nor does it provide higher-level features such as utility classes for forms > etc. > > These are of course very valuable assets but I am wondering how much > effort it is to build something like that on boost::beast vs. relying on a > different library I am currently largely unfamiliar with. > > Are there any features that CppCMS provides that you would deem essential > or “hard to roll yourself” for building something like a collaboration > platform? > > I see that there is a CppDb library to interface databases. However, I > would be using that as we own a license for SQLAPI++ and we’re fairly > familiar working with that. > > > > Maybe some of you even know boost::beast and can provide more detailed > insights. > > > > I understand that this is an open question. I am really looking for > opinions and experiences here – not necessarily only technical facts. > > > > Thank you for your efforts. > > > > > > Best regards, > > ~ Joel Bodenmann > _______________________________________________ > Cppcms-users mailing list > Cpp...@li... > https://lists.sourceforge.net/lists/listinfo/cppcms-users > |
|
From: <jo...@em...> - 2021-03-16 01:46:23
|
Hello folks! I’ve been working with boost::beast for the last year. This is basically a boost-based library built on top of boost::asio to provide HTTP and websocket functionalities. I was curious about CppCMS and played around with it a little for a few days. The gist of this paragraph: I am new to CppCMS and mildly familiar working with boost::beast. I would be interested to hear from the CppCMS community where you see advantages of using CppCMS over boost::beast for building a collaboration-tool website. Unlike CppCMS, boost::beast does not provide a template engine/mechanism nor does it provide higher-level features such as utility classes for forms etc. These are of course very valuable assets but I am wondering how much effort it is to build something like that on boost::beast vs. relying on a different library I am currently largely unfamiliar with. Are there any features that CppCMS provides that you would deem essential or “hard to roll yourself” for building something like a collaboration platform? I see that there is a CppDb library to interface databases. However, I would be using that as we own a license for SQLAPI++ and we’re fairly familiar working with that. Maybe some of you even know boost::beast and can provide more detailed insights. I understand that this is an open question. I am really looking for opinions and experiences here – not necessarily only technical facts. Thank you for your efforts. Best regards, ~ Joel Bodenmann |
|
From: <jo...@em...> - 2021-03-16 01:18:23
|
Hello folks, I am starting to prepare a skeleton for a larger web-platform we’re planning to build that will be based on CppCMS. Due to the size of the application I want to split different modules into different modules. To illustrate this, imagine something like a collaboration platform. It has different functionalities such as: * Task management * Repository/code management * Knowledge base / Wiki * Q & A * Chats * … >From a code structural point of view I’d like each of these features to be plugins in forms of shared libraries (*.so, *.dll, *.dynlib, …). The main application will provide a plugin interface to implement the different functionalities. To achieve this properly, a plugin should be able to provide everything including the various views (compiled CppCMS templates). The main application will then load the plugins and provide menu items in the main navigation so the user can jump to those functionalities. My question: Is there a way that each plugin can compile its own templates with the template compiler? As I see things right now the template compiler needs to know all the templates (views?) What I want is that each plugin compiles its own templates into the C++ views code and then provides that to the main application via the plugin interface. Unfortunately, I was unable to figure out whether this can be achieved – and if so how. Is there a technical limitation that prevents me from achieving this? I saw the documentation of “Dynamic Loading of Views” but as far as I understand that does not really cover my use case as it seems like all the templates/views need to be known when running the compiler. Best regards, ~ Joel Bodenmann |
|
From: Jon F. <jon...@jf...> - 2020-11-10 23:39:41
|
<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>Splendid! Good job! It seems everyone implements their JSON based
APIs/RPCs differently. Looks like Artyom implements the
JSON-RPC-1.0 spec pretty strictly, which is probably a good thing.
Get to know those in-browser debugging tools. They can save a ton
of time!<br>
</p>
<p>@Artyom, if you read this I wanted to let you know: the link to
the spec is broken. Probably should go here:
<a class="moz-txt-link-freetext" href="https://www.jsonrpc.org/specification_v1">https://www.jsonrpc.org/specification_v1</a>. Also RPC is transposed
at least once on your tutorial page.</p>
<p>Congratulations,<br>
Jon<br>
</p>
<br>
<div class="moz-cite-prefix">On 11/10/2020 02:32 PM, Varstray Pl
wrote:<br>
</div>
<blockquote
cite="mid:CAN...@ma..."
type="cite">
<div dir="ltr">Wow! Ok, so I took your information and ran with
it, Jon. The information on CORS was definitely useful.
Originally I thought I was going to have to set the necessary
cors-compliant response headers in my webcomic.cpp code itself,
but something was bugging me about it. My test environment is
essentially from localhost:8080/webcomic, whereas the url given
in the widgets.js getWidgets() method was just simply '/rpc'.
So, to make absolutely sure that I wasn't engaging in any cross
site scripting, I set the xmlhttprequest url to
<a class="moz-txt-link-rfc2396E" href="http:localhost:8080/webcomic/rpc">"http:localhost:8080/webcomic/rpc"</a><br>
<div>.</div>
<div>The response was actually a 404 status code, lol. Verifying
the actual url that the browser tried to contact shed some
light on the issue: It was
<a class="moz-txt-link-rfc2396E" href="http:localhost:8080/webcomic/http:localhost:8080/webcomic/rpc">"http:localhost:8080/webcomic/http:localhost:8080/webcomic/rpc"</a>.
Aha! So the xml request was reaching the json_server backend
after all! I didn't actually have much experience with the
firefox developer console, but your information regarding how
to manually trigger the getWidgets() method and view the
response set me on the right track quickly. I was able to
verify that the "Invalid JSON-RPC" string was actually coming
from the response payload, indicating an issue in the CppCMS
codebase itself.</div>
<div><br>
</div>
<div>A quick bash command:</div>
<div><span style="font-family:monospace">for fd in `ls $SRCDIR`;
do echo "In file: $fd" ; cat ./$fd | grep -e "JSON-RPC" ;
done</span></div>
<div><span style="font-family:monospace"><font
face="arial,sans-serif"><br>
</font></span></div>
<div><span style="font-family:monospace"><font
face="arial,sans-serif">Revealed:</font></span></div>
<div><span style="font-family:monospace">In file: rpc_json.cpp<br>
throw call_error("Invalid JSON-RPC");<br>
BOOSTER_DEBUG("cppcms") << "JSON-RPC Method call:"
<< method();<br>
throw cppcms_error("JSON-RPC Request is not assigned to
class");<br>
</span></div>
<div><span style="font-family:monospace"><br>
</span></div>
<div><span style="font-family:monospace"><font
face="arial,sans-serif">Which led me to this snippet of
code in rpc_json.cpp:</font></span></div>
<div><span style="font-family:monospace"> if(
request.type("method")!=json::is_string <br>
|| request.type("params")!=json::is_array<br>
|| request.type("id")==json::is_undefined)<br>
{<br>
throw call_error("Invalid JSON-RPC");<br>
}</span></div>
<div><span style="font-family:monospace"><br>
</span></div>
<div><span style="font-family:monospace"><font
face="arial,sans-serif">Boom. That was the issue. My JSON
request was originally <span
style="font-family:monospace">{"method":"widgets"}</span>,
but it needed to be <span style="font-family:monospace">{"method":"widgets","params":[],"id":1}</span></font>.</span></div>
<div><span style="font-family:monospace"><font
face="arial,sans-serif">Making the appropriate change and
also updating the XMLHttpRequest url to "/webcomic/rpc"
solved the issue 100%!</font></span></div>
<div><span style="font-family:monospace"><font
face="arial,sans-serif"><br>
</font></span></div>
<div><span style="font-family:monospace"><font
face="arial,sans-serif">Whew! Thank you very much for your
help on this, Jon! I am DEEPLY grateful for all of this!</font></span></div>
<div><span style="font-family:monospace"><font
face="arial,sans-serif"><br>
</font></span></div>
<div><span style="font-family:monospace"><font
face="arial,sans-serif">Sincerely,</font></span></div>
<div><span style="font-family:monospace"><font
face="arial,sans-serif">VarstrayPl.<br>
</font></span></div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Mon, Nov 9, 2020 at 1:52 PM
Jon Foster <<a moz-do-not-send="true"
href="mailto:jon...@jf...">jon...@jf...</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF">
<p>Glad to hear it. I've never actually used the C++CMS JSON
RPC server class because the docs leave too much unsaid,
making it far simpler to write my own handler. I think you
might have to dig through the source to see what its
actually doing. I put together a test environment made
from the "clippings" you sent along and I'm not sure I
made it as far as you did. :-) What I'm seeing is the call
dying in the CORS authentication phase (OPTIONS req) my
C++CMS app failing to respond with the appropriate
"allowed" response, in fact it says nothing and FF just
drops the request.</p>
<p>"CORS" is fairly recent pseudo-security feature. Its
possible that C++CMS is not prepared for it and a simple
extension to the JSON RPC server class may be needed. But
I could be getting ahead of myself.</p>
<p>The primary thing you need to do is fire up your
browser's "dev tools". The "console" section will allow
you to call your javascript function, to manually trigger
requests to the server side. It should also log the
requests and responses made to your server. All XHR
requests should come in two phases the "OPTIONS" request
to ask the server for permission, followed by the actual
JSON request you made, which would be a "POST"
transaction. Check the request and response to make sure
your getting what you expect. Often times what you see
there will reveal the issue.</p>
<p>I don't know your experience level so this page from MDN
might be useful in understanding CORS: <a
moz-do-not-send="true"
href="https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS"
target="_blank">https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS</a></p>
<p>Anyhow I have client needs to attend to or I'd drill the
rest of the way down. Use your browser's debugger and
sprinkle "std::cerr << ..." stuff liberally in your
server side code to get a picture of what its doing. On my
setup I can call the RPC url with a generic client
(browser, wget, curl, ...) and get "invalid content type"
so I know the request is getting dispatched to the RPC
handler. Yet an override of main() fails to show an URL
hit the application so the call must be getting blocked
further up in the class. maybe init()? Or I fat-fingered
something? Like I said I'd have to drill down on the
source to figure out what its up to.</p>
<p>I'll try to help out as I can.</p>
<p>- Jon<br>
</p>
<br>
<div>On 11/09/2020 09:29 AM, Varstray Pl wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>Ah! Ok. So this is actually very helpful!</div>
<div><br>
</div>
<div>I've decided to go with mounting the rpc server in
the webcomic's url space using the attach method you
described above. The code for my webcomic page
constructor is as follows:</div>
<div>* * *<br>
</div>
<div><span style="font-family:monospace">webcomic::webcomic(cppcms::service
&srv) : cppcms::application(srv){<br>
attach(new json_service(srv), "rpc", "/rpc{1}",
"/rpc(/(.*))?", 1);</span></div>
<div><span style="font-family:monospace"> //.. various
dispatcher and mapper calls.<br>
</span></div>
<div><span style="font-family:monospace">};</span></div>
<div><span style="font-family:monospace">***<br>
</span></div>
<div><span style="font-family:monospace"><font
face="arial,sans-serif">The browser now appears to
be successfully calling the rpc server! Yay!
Unfortunately (there's always an unfortunately,
isn't there? xD), I think I haven't set up the
handling of the rpc request properly within the
server, because instead of a proper response, the
widgets panel is simply filled with the text
"Invalid JSON-RPC"</font>. <span
style="font-family:arial,sans-serif">I'm not sure
where in the pipeline things are going wrong, but
here is how I've set up the rpc server. Maybe you
can see what I'm doing wrong?</span></span></div>
<div><span style="font-family:monospace"><span
style="font-family:arial,sans-serif"><br>
</span></span></div>
<div><span style="font-family:monospace"><span
style="font-family:arial,sans-serif">First, the
basic class definition:</span></span></div>
<div><span style="font-family:monospace"><span
style="font-family:arial,sans-serif">* * *</span></span></div>
<div><span style="font-family:monospace">class
json_service: public cppcms::rpc::json_rpc_server{<br>
public:<br>
json_service(cppcms::service &srv);<br>
<br>
// Ajax Methods<br>
void widgets();<br>
};</span></div>
<div><span style="font-family:monospace"><span
style="font-family:arial,sans-serif">* * *</span></span></div>
<div><span style="font-family:monospace"><span
style="font-family:arial,sans-serif"><br>
</span></span></div>
<div><span style="font-family:monospace"><span
style="font-family:arial,sans-serif">And then the
implementation of the server constructor and the
widgets method:</span></span></div>
<div><span style="font-family:monospace"><span
style="font-family:arial,sans-serif">* * *</span></span></div>
<div><span style="font-family:monospace">json_service::json_service(cppcms::service
&srv) : cppcms::rpc::json_rpc_server(srv)<br>
{<br>
bind("widgets",
cppcms::rpc::json_method(&json_service::widgets,
this),method_role);<br>
}<br>
<br>
void json_service::widgets()<br>
{<br>
return_result("widgets via AJAX-RPC!!! Cool!");<br>
}</span></div>
<div><span style="font-family:monospace"><span
style="font-family:arial,sans-serif">* * *</span></span></div>
<div><span style="font-family:monospace"><span
style="font-family:arial,sans-serif"><br>
</span></span></div>
<div><span style="font-family:monospace"><span
style="font-family:arial,sans-serif">Finally, this
is how the request is set up on the client side
via javascript:</span></span></div>
<div><span style="font-family:monospace"><span
style="font-family:arial,sans-serif">* * *</span></span></div>
<div><span style="font-family:monospace"><span
style="font-family:arial,sans-serif"><span
style="font-family:monospace">function
getWidgets() { <br>
var xhr = new XMLHttpRequest(); <br>
xhr.open("post", '/rpc');<br>
<br>
// Required by JSON-RPC over HTTP <br>
xhr.setRequestHeader("Content-Type","application/json");<br>
<br>
// Configure JSON-RPC request.<br>
var request = '{"method":"widgets"}';<br>
<br>
// Define our callback function.<br>
xhr.onreadystatechange = function(){<br>
if (xhr.readyState === 4){<br>
var response;<br>
<br>
if (xhr.status === 200){<br>
response = xhr.responseText;<br>
} else {<br>
response = 'Invalid Status: ' + xhr.status;<br>
}<br>
<br>
document.getElementById('widgets').innerHTML =
response;<br>
}<br>
}<br>
<br>
xhr.send(request);<br>
return false;<br>
} </span><br>
</span></span></div>
<div><span style="font-family:monospace"><span
style="font-family:arial,sans-serif">* * *<br>
</span></span></div>
<div><span style="font-family:monospace"><span
style="font-family:arial,sans-serif">The
javascript method is pretty much taken from the
json-rpc tutorial on the <a
moz-do-not-send="true" href="http://cppcms.com"
target="_blank">cppcms.com</a> website. Although
because this method doesn't take any
parameters(yet), I *think* perhaps the issue lies
somewhere in the modifications I made for sending
a request for a non-parameter method, whereas the
tutorial method does take parameters. Also, up
till this point, diagnostic information on stderr
and stdout has been very helpful, but now there
doesn't appear to be any stderr output at all,
lol.</span></span></div>
<div><span style="font-family:monospace"><span
style="font-family:arial,sans-serif"><br>
</span></span></div>
<div><span style="font-family:monospace"><span
style="font-family:arial,sans-serif">I *can*
verify that on the browser end the rpc call is
actually being sent to the rpc server, and because
'Invalid RPC-JSON' is different from 'Invalid
Status: bla bla', I think that the getWidgets()
method is actually getting a proper response from
the rpc server. It's just clearly there's
something else going wrong somewhere.</span></span></div>
<div><span style="font-family:monospace"><span
style="font-family:arial,sans-serif">* * *</span></span></div>
<div><span style="font-family:monospace"><span
style="font-family:arial,sans-serif"><br>
</span></span></div>
<div><span style="font-family:monospace"><span
style="font-family:arial,sans-serif">Thank you for
your help, Jon, and sorry for any additional
trouble. I'll also keep searching on my end for an
answer as well. ^^;<br>
</span></span></div>
<div><span style="font-family:monospace"><span
style="font-family:arial,sans-serif"><br>
</span></span></div>
<div><span style="font-family:monospace"><span
style="font-family:arial,sans-serif"></span><br>
</span></div>
</div>
<br>
<fieldset></fieldset>
<br>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
Cppcms-users mailing list
<a moz-do-not-send="true" href="mailto:Cpp...@li..." target="_blank">Cpp...@li...</a>
<a moz-do-not-send="true" href="https://lists.sourceforge.net/lists/listinfo/cppcms-users" target="_blank">https://lists.sourceforge.net/lists/listinfo/cppcms-users</a>
</pre>
</blockquote>
<br>
<pre cols="75">--
Sent from my Devuan Linux workstation -- <a moz-do-not-send="true" href="https://devuan.org/" target="_blank">https://devuan.org/</a>
"Init Freedom", Yeah!
Jon Foster
JF Possibilities, Inc.
<a moz-do-not-send="true" href="mailto:jo...@jf..." target="_blank">jo...@jf...</a>
</pre>
</div>
_______________________________________________<br>
Cppcms-users mailing list<br>
<a moz-do-not-send="true"
href="mailto:Cpp...@li..."
target="_blank">Cpp...@li...</a><br>
<a moz-do-not-send="true"
href="https://lists.sourceforge.net/lists/listinfo/cppcms-users"
rel="noreferrer" target="_blank">https://lists.sourceforge.net/lists/listinfo/cppcms-users</a><br>
</blockquote>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Cppcms-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Cpp...@li...">Cpp...@li...</a>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/cppcms-users">https://lists.sourceforge.net/lists/listinfo/cppcms-users</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="75">--
Sent from my Devuan Linux workstation -- <a class="moz-txt-link-freetext" href="https://devuan.org/">https://devuan.org/</a>
"Init Freedom", Yeah!
Jon Foster
JF Possibilities, Inc.
<a class="moz-txt-link-abbreviated" href="mailto:jo...@jf...">jo...@jf...</a>
</pre>
</body>
</html>
|
|
From: Varstray Pl <var...@gm...> - 2020-11-10 22:32:41
|
Wow! Ok, so I took your information and ran with it, Jon. The information
on CORS was definitely useful. Originally I thought I was going to have to
set the necessary cors-compliant response headers in my webcomic.cpp code
itself, but something was bugging me about it. My test environment is
essentially from localhost:8080/webcomic, whereas the url given in the
widgets.js getWidgets() method was just simply '/rpc'. So, to make
absolutely sure that I wasn't engaging in any cross site scripting, I set
the xmlhttprequest url to "http:localhost:8080/webcomic/rpc"
.
The response was actually a 404 status code, lol. Verifying the actual url
that the browser tried to contact shed some light on the issue: It was
"http:localhost:8080/webcomic/http:localhost:8080/webcomic/rpc". Aha! So
the xml request was reaching the json_server backend after all! I didn't
actually have much experience with the firefox developer console, but your
information regarding how to manually trigger the getWidgets() method and
view the response set me on the right track quickly. I was able to verify
that the "Invalid JSON-RPC" string was actually coming from the response
payload, indicating an issue in the CppCMS codebase itself.
A quick bash command:
for fd in `ls $SRCDIR`; do echo "In file: $fd" ; cat ./$fd | grep -e
"JSON-RPC" ; done
Revealed:
In file: rpc_json.cpp
throw call_error("Invalid JSON-RPC");
BOOSTER_DEBUG("cppcms") << "JSON-RPC Method call:" << method();
throw cppcms_error("JSON-RPC Request is not assigned to class");
Which led me to this snippet of code in rpc_json.cpp:
if( request.type("method")!=json::is_string
|| request.type("params")!=json::is_array
|| request.type("id")==json::is_undefined)
{
throw call_error("Invalid JSON-RPC");
}
Boom. That was the issue. My JSON request was originally
{"method":"widgets"}, but it needed to be
{"method":"widgets","params":[],"id":1}.
Making the appropriate change and also updating the XMLHttpRequest url to
"/webcomic/rpc" solved the issue 100%!
Whew! Thank you very much for your help on this, Jon! I am DEEPLY grateful
for all of this!
Sincerely,
VarstrayPl.
On Mon, Nov 9, 2020 at 1:52 PM Jon Foster <jon...@jf...>
wrote:
> Glad to hear it. I've never actually used the C++CMS JSON RPC server class
> because the docs leave too much unsaid, making it far simpler to write my
> own handler. I think you might have to dig through the source to see what
> its actually doing. I put together a test environment made from the
> "clippings" you sent along and I'm not sure I made it as far as you did.
> :-) What I'm seeing is the call dying in the CORS authentication phase
> (OPTIONS req) my C++CMS app failing to respond with the appropriate
> "allowed" response, in fact it says nothing and FF just drops the request.
>
> "CORS" is fairly recent pseudo-security feature. Its possible that C++CMS
> is not prepared for it and a simple extension to the JSON RPC server class
> may be needed. But I could be getting ahead of myself.
>
> The primary thing you need to do is fire up your browser's "dev tools".
> The "console" section will allow you to call your javascript function, to
> manually trigger requests to the server side. It should also log the
> requests and responses made to your server. All XHR requests should come in
> two phases the "OPTIONS" request to ask the server for permission, followed
> by the actual JSON request you made, which would be a "POST" transaction.
> Check the request and response to make sure your getting what you expect.
> Often times what you see there will reveal the issue.
>
> I don't know your experience level so this page from MDN might be useful
> in understanding CORS:
> https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS
>
> Anyhow I have client needs to attend to or I'd drill the rest of the way
> down. Use your browser's debugger and sprinkle "std::cerr << ..." stuff
> liberally in your server side code to get a picture of what its doing. On
> my setup I can call the RPC url with a generic client (browser, wget, curl,
> ...) and get "invalid content type" so I know the request is getting
> dispatched to the RPC handler. Yet an override of main() fails to show an
> URL hit the application so the call must be getting blocked further up in
> the class. maybe init()? Or I fat-fingered something? Like I said I'd have
> to drill down on the source to figure out what its up to.
>
> I'll try to help out as I can.
>
> - Jon
>
> On 11/09/2020 09:29 AM, Varstray Pl wrote:
>
> Ah! Ok. So this is actually very helpful!
>
> I've decided to go with mounting the rpc server in the webcomic's url
> space using the attach method you described above. The code for my webcomic
> page constructor is as follows:
> * * *
> webcomic::webcomic(cppcms::service &srv) : cppcms::application(srv){
> attach(new json_service(srv), "rpc", "/rpc{1}", "/rpc(/(.*))?", 1);
> //.. various dispatcher and mapper calls.
> };
> ***
> The browser now appears to be successfully calling the rpc server! Yay!
> Unfortunately (there's always an unfortunately, isn't there? xD), I think I
> haven't set up the handling of the rpc request properly within the server,
> because instead of a proper response, the widgets panel is simply filled
> with the text "Invalid JSON-RPC". I'm not sure where in the pipeline
> things are going wrong, but here is how I've set up the rpc server. Maybe
> you can see what I'm doing wrong?
>
> First, the basic class definition:
> * * *
> class json_service: public cppcms::rpc::json_rpc_server{
> public:
> json_service(cppcms::service &srv);
>
> // Ajax Methods
> void widgets();
> };
> * * *
>
> And then the implementation of the server constructor and the widgets
> method:
> * * *
> json_service::json_service(cppcms::service &srv) :
> cppcms::rpc::json_rpc_server(srv)
> {
> bind("widgets", cppcms::rpc::json_method(&json_service::widgets,
> this),method_role);
> }
>
> void json_service::widgets()
> {
> return_result("widgets via AJAX-RPC!!! Cool!");
> }
> * * *
>
> Finally, this is how the request is set up on the client side via
> javascript:
> * * *
> function getWidgets() {
> var xhr = new XMLHttpRequest();
> xhr.open("post", '/rpc');
>
> // Required by JSON-RPC over HTTP
> xhr.setRequestHeader("Content-Type","application/json");
>
> // Configure JSON-RPC request.
> var request = '{"method":"widgets"}';
>
> // Define our callback function.
> xhr.onreadystatechange = function(){
> if (xhr.readyState === 4){
> var response;
>
> if (xhr.status === 200){
> response = xhr.responseText;
> } else {
> response = 'Invalid Status: ' + xhr.status;
> }
>
> document.getElementById('widgets').innerHTML = response;
> }
> }
>
> xhr.send(request);
> return false;
> }
> * * *
> The javascript method is pretty much taken from the json-rpc tutorial on
> the cppcms.com website. Although because this method doesn't take any
> parameters(yet), I *think* perhaps the issue lies somewhere in the
> modifications I made for sending a request for a non-parameter method,
> whereas the tutorial method does take parameters. Also, up till this point,
> diagnostic information on stderr and stdout has been very helpful, but now
> there doesn't appear to be any stderr output at all, lol.
>
> I *can* verify that on the browser end the rpc call is actually being sent
> to the rpc server, and because 'Invalid RPC-JSON' is different from
> 'Invalid Status: bla bla', I think that the getWidgets() method is actually
> getting a proper response from the rpc server. It's just clearly there's
> something else going wrong somewhere.
> * * *
>
> Thank you for your help, Jon, and sorry for any additional trouble. I'll
> also keep searching on my end for an answer as well. ^^;
>
>
>
>
>
>
> _______________________________________________
> Cppcms-users mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/cppcms-users
>
>
> --
> Sent from my Devuan Linux workstation -- https://devuan.org/
> "Init Freedom", Yeah!
>
> Jon Foster
> JF Possibilities, In...@jf...
>
> _______________________________________________
> Cppcms-users mailing list
> Cpp...@li...
> https://lists.sourceforge.net/lists/listinfo/cppcms-users
>
|
17 messages has been excluded from this view by a project administrator.
