cppcms-users Mailing List for CppCMS C++ Web Framework (Page 2)
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
|
| 2025 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
|
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...://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
>
|
|
From: Jon F. <jon...@jf...> - 2020-11-09 19:51:40
|
<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<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 class="moz-txt-link-freetext" href="https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS">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 class="moz-cite-prefix">On 11/09/2020 09:29 AM, Varstray Pl
wrote:<br>
</div>
<blockquote
cite="mid:CAN...@ma..."
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">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 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-09 17:29:43
|
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. ^^;
|
|
From: Jon F. <jon...@jf...> - 2020-11-08 22:11:53
|
I feel like I'm missing a piece of the picture but I'll give it a go:
Typically to mount an application in the URL space you do something like
this in the program's main():
cppcms::service srv(argc,argv);
srv.applications_pool().mount(
cppcms::create_pool<rpc_app_class>(),
cppcms::mount_point("/rpc")
);
Or you can mount it in another applications URL space with attach() like
this inside a cppcms::application constructor:
attach( new rpc_app_class(s),
"rpc",
"/rpc{1}",
"/rpc((/.*)?)",1);
And technically you can use dispatcher() and mapper() directly to dispatch
from one app class to another. Just create the additional app object in the
constructor of a parent app object. Then map/dispatch in the traditional
way, but supply the child object to dispatcher. Something like this in the
parent's (app1) constructor:
mapper().assign("rpc", "/rpc");
dispatcher().assign("/rpc", &app2_child::handler, app2);
Obviously the app2 object has to be constructed as a member of app1 in the
usual manner. And don't forget to make sure the object gets destroyed too.
Lastly you can call one app from another through the top most
application::main(). You would need to construct the child app yourself, as
above. But since main() gets the URL you can customize the URL handling to
dispatch the call however you see fit.
I'm sure this is "clear as mud". So ask questions and provide more detail
and I'll see if I can't lend a hand.
- Jon
On 11/05/2020 06:00 AM, Varstray Pl wrote:
> I am setting up a basic webcomic site which uses a class:
>
> class webcomic : cppcms::application { /*...*/ };
>
> for delivering the webcomic functionality, and a class:
>
> class json_service : public cppcms::rpc::json_rpc_server { /*...*/ };
>
> to deliver additional widget based content in a widgets panel. But now I
> can't figure out how to properly dispatch the '/rpc' call that is
> supposed to be sent to the rpc server in my overloaded webcomic::main
> function.
>
> The source code for the implementing chat using json-rpc was... somewhat
> helpful, but also confusing, as I couldn't see any other class in there
> that inherited from cppcms::application. I'm kind of at a loss for how to
> do this.
>
> Please help me. And thank you for your time.
>
>
>
>
> _______________________________________________
> Cppcms-users mailing list
> Cpp...@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, Inc.
jo...@jf...
|
|
From: Varstray Pl <var...@gm...> - 2020-11-05 14:00:49
|
I am setting up a basic webcomic site which uses a class:
class webcomic : cppcms::application { /*...*/ };
for delivering the webcomic functionality, and a class:
class json_service : public cppcms::rpc::json_rpc_server { /*...*/ };
to deliver additional widget based content in a widgets panel. But now I
can't figure out how to properly dispatch the '/rpc' call that is supposed
to be sent to the rpc server in my overloaded webcomic::main function.
The source code for the implementing chat using json-rpc was... somewhat
helpful, but also confusing, as I couldn't see any other class in there
that inherited from cppcms::application. I'm kind of at a loss for how to
do this.
Please help me. And thank you for your time.
|
|
From: <jo...@em...> - 2020-10-17 15:22:23
|
Hello Martin, Thank you a lot - you just made my life a lot easier! Using the `<% form input ... %>` solution is working like a treat. I can work with forms within CppCMS as intended and simply manually render each input element in the template. Best regards, ~ Joel -----Original Message----- From: Martin Bürgmann <mar...@gm...> Sent: Friday, 16 October 2020 14:59 To: cpp...@li... Subject: Re: [Cppcms-users] Multi-step forms Hi Joel, while not having looked at the jquery stuff I have a suggestion. The `cppcms::widgets` classes create the structure of the form and can be used in two ways. 1. Generate HTML from the structure 2. Parse the POST data that would be generated by such a form being submitted. Now if you make the POST data of the jquery form follow the structure of your `cppcms::widgets` form, then you can simply parse the POST data with said form. The HTML generation is then simply skipped. This would be a 50% workaround. Still have the manual created jquery wizard but also have the automated cppcms parsing. Ok, now you got me invested :D I briefly skimmed the link you sent. So the other 50% would possible by using the `<% form input ... %>` tag[1]. You could make your form in HTML but every time you would use an `<input>` tag you just use `<% form input IDENTIFIER %>`. This will need to be formatted correctly with CSS or you use `<% form begin ID %>` and `<% form end ID %>` Sincerely, Martin [1]: http://cppcms.com/wikipp/en/page/cppcms_1x_templates_comm#Rendering.Forms Am Freitag, den 16.10.2020, 11:01 +0200 schrieb jo...@em...: > The forms example is very straight forward and easy to work with. > However, I have to implement a step-by-step wizard using jQuery- > SmartWizard[1]. > As far as I can tell I cannot use the `cppcms::widgets` to create the > form as I need some "custom" HTML as the form is split into multiple > sections etc. > At the end, there's some "Finish" button which triggers a Javascript > function which will post the content of the form. I would then attempt > to parse the POST request manually in the C++ code. > > Is this the recommended way of doing this? Or is there a way to > customize the HTML code generated by the form widgets so that it > structurally matches what I need for the smart wizard? > > > [1] http://techlaboratory.net/jquery-smartwizard > > Best regards, > ~ Joel > > > > _______________________________________________ > 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: Jon F. <jon...@jf...> - 2020-10-16 21:29:35
|
Hey Joel! If I'm reading you correctly what your suggesting is basically what I do. I find putting each "app" in its own name space makes things more pluggable since I can move apps between projects without worrying about name collisions.... unless of course I have multiple apps with the same name, which seems unlikely in my case. I normally don't divide my namespaces based on class kind either. I let those follow names that fit them. My application class is usually just named "app". Making it easy to remember what gets "mounted". So for a particular app the application class name, including namespace would be: my_app::app. And the content classes would be something like "my_app::my_content". I put templates in the same namespace for easy inclusion of related the related content classes. But obviously one could put those in sub namespaces if one wished. C++CMS doesn't really care how you name things outside of the C++ rules. :-) - Jon On 10/13/2020 10:09 AM, jo...@em... wrote: > I’m planning on building a “larger” web application consisting of a complex end-user front-end and an administrator back-end. > Splitting the application into different sub-applications as per the documentation is definitely necessary here. > > My question: I’d like to have a separate namespace per (sub)application. Can views & content classes also be in different namespaces. > Basically I'd like to implement a project folder structure like this: > > my_fancy_server/ > ├─ apps/ > │ ├─ app_01/ > │ │ ├─ app_01.hpp > │ │ ├─ view/ > │ │ │ ├─ foo.tmpl > │ │ │ ├─ bar.tmpl > │ │ ├─ content/ > │ │ │ ├─ tmpl_foo.hpp > │ │ │ ├─ tmpl_bar.hpp > │ ├─ app_02/ > │ │ ├─ view/ > │ │ │ ├─ bar.tmpl > │ │ │ ├─ foo.tmpl > │ │ ├─ content/ > │ │ │ ├─ tmpl_bar.hpp > │ │ │ ├─ tmpl_foo.hpp > │ │ ├─ app_02.hpp > ├─ view/ > │ ├─ master.tmpl > ├─ content/ > │ ├─ content.hpp > ├─ website.hpp > ├─ main.cpp > > Then I'd like each `app_xx` folder to have it's own C++ namespace. Therefore, the data/content class of `app_01/tmpl_foo.hpp` would be `apps::app_01::foo`. > > Is this advisable/recommended/wrong/not-optimal/perfect/ ...? > I'd be thankful for any kind of feedback as I'd like to prevent having to re-organize everything after a few weeks of working and realizing that this is not optimal. > > > Best regards, > ~ Joel > > > > _______________________________________________ > Cppcms-users mailing list > Cpp...@li... > https://lists.sourceforge.net/lists/listinfo/cppcms-users -- Sent from my Debian Linux laptop Jon Foster JF Possibilities, Inc. jo...@jf... |
|
From: Jon F. <jon...@jf...> - 2020-10-16 21:02:43
|
Hey Joel! I confess I've not used the jQuery wizard stuff either. Besides Martin's suggestions I would make one more. I'd study the form widget classes and make appropriate subclasses to facilitate jQuery's wizard system. This would allow for reuse wherever needed. Also it might not be obvious but forms are allowed to be members of forms. This allows for being able to easily render sub sections of the form in a view and once all of the data has been accumulated you pass the whole set of data to the topmost parent for parsing the full form's content. Something along those lines might also be helpful. - Jon On 10/16/2020 05:59 AM, Martin Bürgmann wrote: > Hi Joel, > > while not having looked at the jquery stuff I have a suggestion. > The `cppcms::widgets` classes create the structure of the form and can > be used in two ways. > 1. Generate HTML from the structure > 2. Parse the POST data that would be generated by such a form being > submitted. > > Now if you make the POST data of the jquery form follow the structure > of your `cppcms::widgets` form, then you can simply parse the POST data > with said form. The HTML generation is then simply skipped. > > This would be a 50% workaround. Still have the manual created jquery > wizard but also have the automated cppcms parsing. > > Ok, now you got me invested :D > I briefly skimmed the link you sent. > > So the other 50% would possible by using the `<% form input ... %>` > tag[1]. > You could make your form in HTML but every time you would use an > `<input>` tag you just use `<% form input IDENTIFIER %>`. This will > need to be formatted correctly with CSS or you use `<% form begin ID > %>` and `<% form end ID %>` > > Sincerely, > Martin > > > [1]: > http://cppcms.com/wikipp/en/page/cppcms_1x_templates_comm#Rendering.Forms > > > > > > Am Freitag, den 16.10.2020, 11:01 +0200 schrieb jo...@em...: >> The forms example is very straight forward and easy to work with. >> However, I have to implement a step-by-step wizard using jQuery- >> SmartWizard[1]. >> As far as I can tell I cannot use the `cppcms::widgets` to create the >> form as I need some "custom" HTML as the form is split into multiple >> sections etc. >> At the end, there's some "Finish" button which triggers a Javascript >> function which will post the content of the form. I would then >> attempt to parse the POST request manually in the C++ code. >> >> Is this the recommended way of doing this? Or is there a way to >> customize the HTML code generated by the form widgets so that it >> structurally matches what I need for the smart wizard? >> >> >> [1] http://techlaboratory.net/jquery-smartwizard >> >> Best regards, >> ~ Joel >> >> >> >> _______________________________________________ >> 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 -- Sent from my Debian Linux laptop Jon Foster JF Possibilities, Inc. jo...@jf... |
|
From: Martin B. <mar...@gm...> - 2020-10-16 12:59:32
|
Hi Joel, while not having looked at the jquery stuff I have a suggestion. The `cppcms::widgets` classes create the structure of the form and can be used in two ways. 1. Generate HTML from the structure 2. Parse the POST data that would be generated by such a form being submitted. Now if you make the POST data of the jquery form follow the structure of your `cppcms::widgets` form, then you can simply parse the POST data with said form. The HTML generation is then simply skipped. This would be a 50% workaround. Still have the manual created jquery wizard but also have the automated cppcms parsing. Ok, now you got me invested :D I briefly skimmed the link you sent. So the other 50% would possible by using the `<% form input ... %>` tag[1]. You could make your form in HTML but every time you would use an `<input>` tag you just use `<% form input IDENTIFIER %>`. This will need to be formatted correctly with CSS or you use `<% form begin ID %>` and `<% form end ID %>` Sincerely, Martin [1]: http://cppcms.com/wikipp/en/page/cppcms_1x_templates_comm#Rendering.Forms Am Freitag, den 16.10.2020, 11:01 +0200 schrieb jo...@em...: > The forms example is very straight forward and easy to work with. > However, I have to implement a step-by-step wizard using jQuery- > SmartWizard[1]. > As far as I can tell I cannot use the `cppcms::widgets` to create the > form as I need some "custom" HTML as the form is split into multiple > sections etc. > At the end, there's some "Finish" button which triggers a Javascript > function which will post the content of the form. I would then > attempt to parse the POST request manually in the C++ code. > > Is this the recommended way of doing this? Or is there a way to > customize the HTML code generated by the form widgets so that it > structurally matches what I need for the smart wizard? > > > [1] http://techlaboratory.net/jquery-smartwizard > > Best regards, > ~ Joel > > > > _______________________________________________ > Cppcms-users mailing list > Cpp...@li... > https://lists.sourceforge.net/lists/listinfo/cppcms-users |
|
From: <jo...@em...> - 2020-10-16 09:01:55
|
The forms example is very straight forward and easy to work with. However, I have to implement a step-by-step wizard using jQuery-SmartWizard[1]. As far as I can tell I cannot use the `cppcms::widgets` to create the form as I need some "custom" HTML as the form is split into multiple sections etc. At the end, there's some "Finish" button which triggers a Javascript function which will post the content of the form. I would then attempt to parse the POST request manually in the C++ code. Is this the recommended way of doing this? Or is there a way to customize the HTML code generated by the form widgets so that it structurally matches what I need for the smart wizard? [1] http://techlaboratory.net/jquery-smartwizard Best regards, ~ Joel |
|
From: <jo...@em...> - 2020-10-13 17:09:10
|
I’m planning on building a “larger” web application consisting of a complex end-user front-end and an administrator back-end. Splitting the application into different sub-applications as per the documentation is definitely necessary here. My question: I’d like to have a separate namespace per (sub)application. Can views & content classes also be in different namespaces. Basically I'd like to implement a project folder structure like this: my_fancy_server/ ├─ apps/ │ ├─ app_01/ │ │ ├─ app_01.hpp │ │ ├─ view/ │ │ │ ├─ foo.tmpl │ │ │ ├─ bar.tmpl │ │ ├─ content/ │ │ │ ├─ tmpl_foo.hpp │ │ │ ├─ tmpl_bar.hpp │ ├─ app_02/ │ │ ├─ view/ │ │ │ ├─ bar.tmpl │ │ │ ├─ foo.tmpl │ │ ├─ content/ │ │ │ ├─ tmpl_bar.hpp │ │ │ ├─ tmpl_foo.hpp │ │ ├─ app_02.hpp ├─ view/ │ ├─ master.tmpl ├─ content/ │ ├─ content.hpp ├─ website.hpp ├─ main.cpp Then I'd like each `app_xx` folder to have it's own C++ namespace. Therefore, the data/content class of `app_01/tmpl_foo.hpp` would be `apps::app_01::foo`. Is this advisable/recommended/wrong/not-optimal/perfect/ ...? I'd be thankful for any kind of feedback as I'd like to prevent having to re-organize everything after a few weeks of working and realizing that this is not optimal. Best regards, ~ Joel |
|
From: <jo...@em...> - 2020-10-13 10:15:34
|
This works very well. Thank you a lot!
Please keep up the good work with CppCMS. I know that I’m fairly late to the party but I really hope that this framework will continue to develop and live a long & healthy life!
Best regards,
~ Joel
From: Artyom Beilis <art...@gm...>
Sent: Tuesday, 13 October 2020 11:32
To: cpp...@li...
Subject: Re: [Cppcms-users] Navigation template - Set "active" on corresponding entry
I assume you have several templates derived from base one that provide different page_content
You can also short template home_class, news_class and include it from sidebar
<a <% include home_class() %> href='<% url "/" %>'>Home</a>
<a <% include news_class() %> href='<% url "/news" %>'>News</a>
<a <% include users_class() %> href='<% url "/users" %>'>Users</a>
Define these templates in master as empty
<% template home_class() %><% end template %>
<% template news_class() %><% end template %>
...
Now at the level of the implementation of Home template derived from master override the home class
<% template home_class() %>class="active" <% end template %>
It is little bit long but most generic and does not require from you to modify C++ code.
Artyom
On Mon, Oct 12, 2020 at 11:27 PM <jo...@em... <mailto:jo...@em...> > wrote:
Hi guys!
I started evaluating CppCMS for a project a few days ago. Right now I am trying to build a very simple user management back-end as a proof of concept.
I am implementing a simple portal using CppCMS. The master page has a simple sidebar for navigational purposes based on the W3C example (https://www.w3schools.com/howto/howto_css_sidebar_responsive.asp).
My master template looks like this (mainly the sidebar template is of interest):
<% c++ #include "data/content.hpp" %>
<% skin defskin %>
<% view master uses content::master %>
<% template title() %>
<%= title %>
<% end template %>
<% template page_content() %>
Override Me
<% end template %>
<% template sidebar() %>
<div class="sidebar">
<a class="active" href='<% url "/" %>'>Home</a>
<a href='<% url "/news" %>'>News</a>
<a href='<% url "/users" %>'>Users</a>
</div>
<% end template %>
<% template render() %>
<html>
<head>
<link rel="stylesheet" href="/css/style.css">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title><% include title() %></title>
</head>
<body>
<% include sidebar() %>
<div class="content">
<h1><% include title() %></h1>
<% include page_content() %>
</div>
</body>
</html>
<% end template %>
<% end view %>
<% end skin %>
What is the appropriate/recommended way of setting the class="active" attribute for the URL of the current view/page?
Is there a mechanism in the template engine that allows me to set the attribute on the appropriate menu item in the master template?
Note: I've posted this also on GitHub issues but by now I figured I might have more luck here.
Best regards,
~ Joel
_______________________________________________
Cppcms-users mailing list
Cpp...@li... <mailto:Cpp...@li...>
https://lists.sourceforge.net/lists/listinfo/cppcms-users
|
|
From: Artyom B. <art...@gm...> - 2020-10-13 09:43:19
|
I assume you have several templates derived from base one that provide
different page_content
You can also short template home_class, news_class and include it from
sidebar
<a <% include home_class() %> href='<% url "/" %>'>Home</a>
<a <% include news_class() %> href='<% url "/news" %>'>News</a>
<a <% include users_class() %> href='<% url "/users" %>'>Users</a>
Define these templates in master as empty
<% template home_class() %><% end template %>
<% template news_class() %><% end template %>
...
Now at the level of the implementation of Home template derived from master
override the home class
<% template home_class() %>class="active" <% end template %>
It is little bit long but most generic and does not require from you to
modify C++ code.
Artyom
On Mon, Oct 12, 2020 at 11:27 PM <jo...@em...> wrote:
> Hi guys!
>
> I started evaluating CppCMS for a project a few days ago. Right now I am
> trying to build a very simple user management back-end as a proof of
> concept.
>
>
> I am implementing a simple portal using CppCMS. The master page has a
> simple sidebar for navigational purposes based on the W3C example (
> https://www.w3schools.com/howto/howto_css_sidebar_responsive.asp).
>
> My master template looks like this (mainly the sidebar template is of
> interest):
>
> <% c++ #include "data/content.hpp" %>
> <% skin defskin %>
> <% view master uses content::master %>
> <% template title() %>
> <%= title %>
> <% end template %>
> <% template page_content() %>
> Override Me
> <% end template %>
> <% template sidebar() %>
> <div class="sidebar">
> <a class="active" href='<% url "/" %>'>Home</a>
> <a href='<% url "/news" %>'>News</a>
> <a href='<% url "/users" %>'>Users</a>
> </div>
> <% end template %>
> <% template render() %>
> <html>
> <head>
> <link rel="stylesheet" href="/css/style.css">
> <meta name="viewport" content="width=device-width,
> initial-scale=1.0">
> <title><% include title() %></title>
> </head>
> <body>
> <% include sidebar() %>
> <div class="content">
> <h1><% include title() %></h1>
> <% include page_content() %>
> </div>
> </body>
> </html>
> <% end template %>
> <% end view %>
> <% end skin %>
>
> What is the appropriate/recommended way of setting the class="active"
> attribute for the URL of the current view/page?
> Is there a mechanism in the template engine that allows me to set the
> attribute on the appropriate menu item in the master template?
>
> Note: I've posted this also on GitHub issues but by now I figured I might
> have more luck here.
>
>
> Best regards,
> ~ Joel
>
>
>
> _______________________________________________
> Cppcms-users mailing list
> Cpp...@li...
> https://lists.sourceforge.net/lists/listinfo/cppcms-users
>
|
|
From: <ye...@ye...> - 2020-10-13 01:38:40
|
Hi Joel:
I encountered the same problem as you during the development of my blog site, but I did not find a solution for cppcms. However, the good news is that I implemented this feature using javascript, and it looks like this:
<script type="text/javascript">
$(document).ready(function()
{
var url = window.location.protocol + "//" + window.location.host + window.location.pathname;
$("#main-menu-navigation").find('a').each(function(){
if (this.href === url) {
$(this).parent().addClass('active');
}
});
});
</script>
Because my project uses jquery, you can change it to a form that does not use jquery, which is very simple. I used the congruent judgment here. Of course, this does not work for some URLs. You can change it to indexOf() or search() to retrieve whether the URL is included.
Finally, I am sorry that my English is poor, so I have to use Google Translate to reply to this email.
good luck.
- - - - - - - - - 原版的 - - - - - - - - -
来自: “ joel” <jo...@em...>;
日期: 2020年10月13日,星期二04:26 AM
收件人: “ cppcms-users” <cpp...@li...>;
主题: [Cppcms-用户]导航模板-在相应条目上设置“活动”
嗨,大家好!
几天前,我开始为一个项目评估CppCMS。现在,我正在尝试构建一个非常简单的用户管理后端作为概念证明。
我正在使用CppCMS实现一个简单的门户。该母版页基于W3C示例(https://www.w3schools.com/howto/howto_css_sidebar_sensitive.asp),具有用于导航目的的简单边栏。
我的主模板看起来像这样(主要是侧边栏模板很有趣):
<%c ++ #include“ data / content.hpp”%>
<%skin defskin%>
<%视图母版使用content :: master%>
<%模板title()%>
<%= title%>
<%最终模板%>
<%模板page_content()%>
覆盖我
<%最终模板%>
<div class =“ sidebar”>
<a class="active" href='<% url "/" %>'>主页</a>
<a href='<% url "/news" %>'>新闻</a>
<a href='<% url "/users" %>'>用户</a>
</ div>
<%最终模板%>
<%template render()%>
<html>
<head>
<链接rel =“ stylesheet” href =“ / css / style.css”>
<meta name =“ viewport” content =“ width = device-width,initial-scale = 1.0”>
<title> <%include title()% > </ title>
</ head>
<body>
<%include sidebar()%>
<div class =“ content”>
<h1> <%include title()%> </ h1>
<%include page_content()%>
</ div>
</ body>
</ html>
<%最终模板%>
<%最终视图%>
<%最终皮肤%>
什么是为当前视图的URL设置class =“ active”属性的适当/建议方法/页?
模板引擎中是否有一种机制可以让我在主模板中的相应菜单项上设置属性?
注意:我也已经在GitHub问题上发布了此内容,但到目前为止,我认为我在这里可能还有更多的运气。
最好的问候,
〜乔尔
_______________________________________________
Cppcms用户邮件列表
Cpp...@li...
https://lists.sourceforge.net/lists/listinfo/cppcms-users |
|
From: <jo...@em...> - 2020-10-12 20:26:29
|
Hi guys! I started evaluating CppCMS for a project a few days ago. Right now I am trying to build a very simple user management back-end as a proof of concept. I am implementing a simple portal using CppCMS. The master page has a simple sidebar for navigational purposes based on the W3C example (https://www.w3schools.com/howto/howto_css_sidebar_responsive.asp). My master template looks like this (mainly the sidebar template is of interest): <% c++ #include "data/content.hpp" %> <% skin defskin %> <% view master uses content::master %> <% template title() %> <%= title %> <% end template %> <% template page_content() %> Override Me <% end template %> <% template sidebar() %> <div class="sidebar"> <a class="active" href='<% url "/" %>'>Home</a> <a href='<% url "/news" %>'>News</a> <a href='<% url "/users" %>'>Users</a> </div> <% end template %> <% template render() %> <html> <head> <link rel="stylesheet" href="/css/style.css"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <title><% include title() %></title> </head> <body> <% include sidebar() %> <div class="content"> <h1><% include title() %></h1> <% include page_content() %> </div> </body> </html> <% end template %> <% end view %> <% end skin %> What is the appropriate/recommended way of setting the class="active" attribute for the URL of the current view/page? Is there a mechanism in the template engine that allows me to set the attribute on the appropriate menu item in the master template? Note: I've posted this also on GitHub issues but by now I figured I might have more luck here. Best regards, ~ Joel |
|
From: Artyom B. <art...@gm...> - 2020-09-18 19:47:05
|
Dear CppCMS Users,
CppCMS 2.0.0 bet2 is ready, and It includes:
-
improved HTTP support - now it is first class citizen and not a
debugging tool over CGI protocol. The improvements include:
- HTTP/1.1
- keep-alive support
- Request pipelining
- Chunked transfer encoding
- HTTP response now generated directly rather than being converted
from CGI output stream.
- Performance improvement in environment variables handling and HTTP
general
The HTTP improvements were base requirement for implementation of web
sockets - the next development step
Artyom Beilis
|
|
From: Tee T. <jim...@gm...> - 2020-09-11 07:21:47
|
Hi Everyone I've just started using this amazing tool and I'm having trouble making two microservices communicate with each other. I managed to create two microservices and tested them on Postman and they work perfectly fine. But the difficulty I'm having is making the two Microservices exchange data amongst them, internally. SCENARIO: Microservice A receives an image from client side and processes the image and sends it to Microservice B for further processing. Subsequently send it back to the client side. Furthermore, How can I ensure that the communication amongst the microservices is secure? Thanks for the assistance George |
|
From: M-e-ch T. <mec...@gm...> - 2020-09-06 08:03:03
|
Thanks make works fine Just a few errors with make install ,though I think they are related to my system. I am not sure though On Sun, Sep 6, 2020, 8:26 AM Artyom Beilis <art...@gm...> wrote: > Ok I see, > > it looks like -latomic need to be at all levels including user's buid, so > I moved atomic to internal code instead of inline like it was before > > I committed some changes to fix the issue can you pease test latest git / > *cpp11* branch > > git clone https://github.com/artyom-beilis/cppcms.git > git checkout cpp11 > > Artyom > > > On Sun, Sep 6, 2020 at 5:33 AM M-e-ch Technologies < > mec...@gm...> wrote: > >> the patch did better though the same problem reincured at 36%. >> Clang and platform are in the log file. >> Thank you for taking your time to help me . >> Am fairly new to programming >> >> >> On Fri, Sep 4, 2020, 3:39 PM M-e-ch Technologies < >> mec...@gm...> wrote: >> >>> *[ 29%] Linking C executable external_session_test* >>> */data/data/com.termux/files/usr/bin/arm-linux-androideabi-ld: >>> libcppcms.so.2.0.0.beta1: undefined reference to `__atomic_fetch_sub_4'* >>> */data/data/com.termux/files/usr/bin/arm-linux-androideabi-ld: >>> libcppcms.so.2.0.0.beta1: undefined reference to `__atomic_load_4'* >>> */data/data/com.termux/files/usr/bin/arm-linux-androideabi-ld: >>> libcppcms.so.2.0.0.beta1: undefined reference to `__atomic_fetch_add_4'* >>> *clang-10: error: linker command failed with exit code 1 (use -v to see >>> invocation)* >>> *make[2]: *** [CMakeFiles/external_session_test.dir/build.make:110: >>> external_session_test] Error 1* >>> *make[1]: *** [CMakeFiles/Makefile2:314: >>> CMakeFiles/external_session_test.dir/all] Error 2* >>> *make: *** [Makefile:182: all] Error 2* >>> >>> >>> >>> I am to cppcms and c++ in general how do I solve the above error >>> >>> On Tue, Sep 1, 2020, 11:17 PM Artyom Beilis <art...@gm...> >>> wrote: >>> >>>> Hello Dear CppCMS users >>>> >>>> Have anybody used raw or asynchronous_raw with http_response? >>>> >>>> I'm doing some changes for HTTP/1.1+websockets+performance improvement >>>> support. >>>> The original CppCMS design had an underlying assumption that the basic >>>> communication protocol is derivative of CGI protocols - FastCGI, SCGI. >>>> >>>> So when http web server was added it actually parsed CGI output headers >>>> and converted them to HTTP ones. Thus use of raw/asynchronos_raw mode when >>>> the user writes his own CGI headers instead of generating them via >>>> http_response API was reasonable. >>>> >>>> Today I want to make an HTTP protocol 1st class citizen in CppCMS - >>>> which means that I don't silently assume that all IO is CGI based. It is >>>> actually a requirement for extensions like WebSockets and other things that >>>> can't be passed via *CGI like protocols. >>>> >>>> Removing "raw" *CGI I/O would simplify the task. I can implement it via >>>> an intermediate CGI parser but it isn't the most trivial task. >>>> >>>> So I need to understand if anybody actually uses this feature or I can >>>> remove it in CppCMS 2.0.0? >>>> >>>> Artyom Beilis >>>> _______________________________________________ >>>> 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 >> > _______________________________________________ > Cppcms-users mailing list > Cpp...@li... > https://lists.sourceforge.net/lists/listinfo/cppcms-users > |
|
From: Artyom B. <art...@gm...> - 2020-09-06 05:26:38
|
Ok I see, it looks like -latomic need to be at all levels including user's buid, so I moved atomic to internal code instead of inline like it was before I committed some changes to fix the issue can you pease test latest git / *cpp11* branch git clone https://github.com/artyom-beilis/cppcms.git git checkout cpp11 Artyom On Sun, Sep 6, 2020 at 5:33 AM M-e-ch Technologies < mec...@gm...> wrote: > the patch did better though the same problem reincured at 36%. > Clang and platform are in the log file. > Thank you for taking your time to help me . > Am fairly new to programming > > > On Fri, Sep 4, 2020, 3:39 PM M-e-ch Technologies < > mec...@gm...> wrote: > >> *[ 29%] Linking C executable external_session_test* >> */data/data/com.termux/files/usr/bin/arm-linux-androideabi-ld: >> libcppcms.so.2.0.0.beta1: undefined reference to `__atomic_fetch_sub_4'* >> */data/data/com.termux/files/usr/bin/arm-linux-androideabi-ld: >> libcppcms.so.2.0.0.beta1: undefined reference to `__atomic_load_4'* >> */data/data/com.termux/files/usr/bin/arm-linux-androideabi-ld: >> libcppcms.so.2.0.0.beta1: undefined reference to `__atomic_fetch_add_4'* >> *clang-10: error: linker command failed with exit code 1 (use -v to see >> invocation)* >> *make[2]: *** [CMakeFiles/external_session_test.dir/build.make:110: >> external_session_test] Error 1* >> *make[1]: *** [CMakeFiles/Makefile2:314: >> CMakeFiles/external_session_test.dir/all] Error 2* >> *make: *** [Makefile:182: all] Error 2* >> >> >> >> I am to cppcms and c++ in general how do I solve the above error >> >> On Tue, Sep 1, 2020, 11:17 PM Artyom Beilis <art...@gm...> >> wrote: >> >>> Hello Dear CppCMS users >>> >>> Have anybody used raw or asynchronous_raw with http_response? >>> >>> I'm doing some changes for HTTP/1.1+websockets+performance improvement >>> support. >>> The original CppCMS design had an underlying assumption that the basic >>> communication protocol is derivative of CGI protocols - FastCGI, SCGI. >>> >>> So when http web server was added it actually parsed CGI output headers >>> and converted them to HTTP ones. Thus use of raw/asynchronos_raw mode when >>> the user writes his own CGI headers instead of generating them via >>> http_response API was reasonable. >>> >>> Today I want to make an HTTP protocol 1st class citizen in CppCMS - >>> which means that I don't silently assume that all IO is CGI based. It is >>> actually a requirement for extensions like WebSockets and other things that >>> can't be passed via *CGI like protocols. >>> >>> Removing "raw" *CGI I/O would simplify the task. I can implement it via >>> an intermediate CGI parser but it isn't the most trivial task. >>> >>> So I need to understand if anybody actually uses this feature or I can >>> remove it in CppCMS 2.0.0? >>> >>> Artyom Beilis >>> _______________________________________________ >>> 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: M-e-ch T. <mec...@gm...> - 2020-09-06 02:33:33
|
the patch did better though the same problem reincured at 36%. Clang and platform are in the log file. Thank you for taking your time to help me . Am fairly new to programming On Fri, Sep 4, 2020, 3:39 PM M-e-ch Technologies < mec...@gm...> wrote: > *[ 29%] Linking C executable external_session_test* > */data/data/com.termux/files/usr/bin/arm-linux-androideabi-ld: > libcppcms.so.2.0.0.beta1: undefined reference to `__atomic_fetch_sub_4'* > */data/data/com.termux/files/usr/bin/arm-linux-androideabi-ld: > libcppcms.so.2.0.0.beta1: undefined reference to `__atomic_load_4'* > */data/data/com.termux/files/usr/bin/arm-linux-androideabi-ld: > libcppcms.so.2.0.0.beta1: undefined reference to `__atomic_fetch_add_4'* > *clang-10: error: linker command failed with exit code 1 (use -v to see > invocation)* > *make[2]: *** [CMakeFiles/external_session_test.dir/build.make:110: > external_session_test] Error 1* > *make[1]: *** [CMakeFiles/Makefile2:314: > CMakeFiles/external_session_test.dir/all] Error 2* > *make: *** [Makefile:182: all] Error 2* > > > > I am to cppcms and c++ in general how do I solve the above error > > On Tue, Sep 1, 2020, 11:17 PM Artyom Beilis <art...@gm...> > wrote: > >> Hello Dear CppCMS users >> >> Have anybody used raw or asynchronous_raw with http_response? >> >> I'm doing some changes for HTTP/1.1+websockets+performance improvement >> support. >> The original CppCMS design had an underlying assumption that the basic >> communication protocol is derivative of CGI protocols - FastCGI, SCGI. >> >> So when http web server was added it actually parsed CGI output headers >> and converted them to HTTP ones. Thus use of raw/asynchronos_raw mode when >> the user writes his own CGI headers instead of generating them via >> http_response API was reasonable. >> >> Today I want to make an HTTP protocol 1st class citizen in CppCMS - which >> means that I don't silently assume that all IO is CGI based. It is actually >> a requirement for extensions like WebSockets and other things that can't be >> passed via *CGI like protocols. >> >> Removing "raw" *CGI I/O would simplify the task. I can implement it via >> an intermediate CGI parser but it isn't the most trivial task. >> >> So I need to understand if anybody actually uses this feature or I can >> remove it in CppCMS 2.0.0? >> >> Artyom Beilis >> _______________________________________________ >> Cppcms-users mailing list >> Cpp...@li... >> https://lists.sourceforge.net/lists/listinfo/cppcms-users >> > |
|
From: Artyom B. <art...@gm...> - 2020-09-05 21:53:38
|
Hi, Thanks for the bug report. What is the platform you are compiling for x64/arm etc? What version of clang? >From googling it looks like atomc library link is missing Can you try the attached patch and tell if it helps? Artyom On Fri, Sep 4, 2020 at 3:40 PM M-e-ch Technologies < mec...@gm...> wrote: > *[ 29%] Linking C executable external_session_test* > */data/data/com.termux/files/usr/bin/arm-linux-androideabi-ld: > libcppcms.so.2.0.0.beta1: undefined reference to `__atomic_fetch_sub_4'* > */data/data/com.termux/files/usr/bin/arm-linux-androideabi-ld: > libcppcms.so.2.0.0.beta1: undefined reference to `__atomic_load_4'* > */data/data/com.termux/files/usr/bin/arm-linux-androideabi-ld: > libcppcms.so.2.0.0.beta1: undefined reference to `__atomic_fetch_add_4'* > *clang-10: error: linker command failed with exit code 1 (use -v to see > invocation)* > *make[2]: *** [CMakeFiles/external_session_test.dir/build.make:110: > external_session_test] Error 1* > *make[1]: *** [CMakeFiles/Makefile2:314: > CMakeFiles/external_session_test.dir/all] Error 2* > *make: *** [Makefile:182: all] Error 2* > > > > I am to cppcms and c++ in general how do I solve the above error > > On Tue, Sep 1, 2020, 11:17 PM Artyom Beilis <art...@gm...> > wrote: > >> Hello Dear CppCMS users >> >> Have anybody used raw or asynchronous_raw with http_response? >> >> I'm doing some changes for HTTP/1.1+websockets+performance improvement >> support. >> The original CppCMS design had an underlying assumption that the basic >> communication protocol is derivative of CGI protocols - FastCGI, SCGI. >> >> So when http web server was added it actually parsed CGI output headers >> and converted them to HTTP ones. Thus use of raw/asynchronos_raw mode when >> the user writes his own CGI headers instead of generating them via >> http_response API was reasonable. >> >> Today I want to make an HTTP protocol 1st class citizen in CppCMS - which >> means that I don't silently assume that all IO is CGI based. It is actually >> a requirement for extensions like WebSockets and other things that can't be >> passed via *CGI like protocols. >> >> Removing "raw" *CGI I/O would simplify the task. I can implement it via >> an intermediate CGI parser but it isn't the most trivial task. >> >> So I need to understand if anybody actually uses this feature or I can >> remove it in CppCMS 2.0.0? >> >> Artyom Beilis >> _______________________________________________ >> 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: M-e-ch T. <mec...@gm...> - 2020-09-04 12:39:47
|
*[ 29%] Linking C executable external_session_test* */data/data/com.termux/files/usr/bin/arm-linux-androideabi-ld: libcppcms.so.2.0.0.beta1: undefined reference to `__atomic_fetch_sub_4'* */data/data/com.termux/files/usr/bin/arm-linux-androideabi-ld: libcppcms.so.2.0.0.beta1: undefined reference to `__atomic_load_4'* */data/data/com.termux/files/usr/bin/arm-linux-androideabi-ld: libcppcms.so.2.0.0.beta1: undefined reference to `__atomic_fetch_add_4'* *clang-10: error: linker command failed with exit code 1 (use -v to see invocation)* *make[2]: *** [CMakeFiles/external_session_test.dir/build.make:110: external_session_test] Error 1* *make[1]: *** [CMakeFiles/Makefile2:314: CMakeFiles/external_session_test.dir/all] Error 2* *make: *** [Makefile:182: all] Error 2* I am to cppcms and c++ in general how do I solve the above error On Tue, Sep 1, 2020, 11:17 PM Artyom Beilis <art...@gm...> wrote: > Hello Dear CppCMS users > > Have anybody used raw or asynchronous_raw with http_response? > > I'm doing some changes for HTTP/1.1+websockets+performance improvement > support. > The original CppCMS design had an underlying assumption that the basic > communication protocol is derivative of CGI protocols - FastCGI, SCGI. > > So when http web server was added it actually parsed CGI output headers > and converted them to HTTP ones. Thus use of raw/asynchronos_raw mode when > the user writes his own CGI headers instead of generating them via > http_response API was reasonable. > > Today I want to make an HTTP protocol 1st class citizen in CppCMS - which > means that I don't silently assume that all IO is CGI based. It is actually > a requirement for extensions like WebSockets and other things that can't be > passed via *CGI like protocols. > > Removing "raw" *CGI I/O would simplify the task. I can implement it via an > intermediate CGI parser but it isn't the most trivial task. > > So I need to understand if anybody actually uses this feature or I can > remove it in CppCMS 2.0.0? > > Artyom Beilis > _______________________________________________ > Cppcms-users mailing list > Cpp...@li... > https://lists.sourceforge.net/lists/listinfo/cppcms-users > |
|
From: Artyom B. <art...@gm...> - 2020-09-02 03:42:42
|
On Wed, Sep 2, 2020 at 1:17 AM Fernando Fuentes <die...@gm...> wrote: > > Hi, > > I use "raw_post_data" to parse json, and use it for REST. > > *This is something else and this is of course it remains :-)* raw response mode means something else: response().io_mode(raw) - means you write to out() your CGI headers: i.e.: out() << "Content-Type:text/html\r\nCookie: foo-bbar\r\n\r\n" out() << "Hello" This isn't very low level interface for something very custom. Artyom > > El mar., 1 sept. 2020 a las 15:17, Artyom Beilis (<art...@gm...>) > escribió: > >> Hello Dear CppCMS users >> >> Have anybody used raw or asynchronous_raw with http_response? >> >> I'm doing some changes for HTTP/1.1+websockets+performance improvement >> support. >> The original CppCMS design had an underlying assumption that the basic >> communication protocol is derivative of CGI protocols - FastCGI, SCGI. >> >> So when http web server was added it actually parsed CGI output headers >> and converted them to HTTP ones. Thus use of raw/asynchronos_raw mode when >> the user writes his own CGI headers instead of generating them via >> http_response API was reasonable. >> >> Today I want to make an HTTP protocol 1st class citizen in CppCMS - which >> means that I don't silently assume that all IO is CGI based. It is actually >> a requirement for extensions like WebSockets and other things that can't be >> passed via *CGI like protocols. >> >> Removing "raw" *CGI I/O would simplify the task. I can implement it via >> an intermediate CGI parser but it isn't the most trivial task. >> >> So I need to understand if anybody actually uses this feature or I can >> remove it in CppCMS 2.0.0? >> >> Artyom Beilis >> _______________________________________________ >> 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: Fernando F. <die...@gm...> - 2020-09-01 22:17:07
|
Hi, I use "raw_post_data" to parse json, and use it for REST. (char *) request (). raw_post_data (). first In service implementation I also widely use "raw_post_data". El mar., 1 sept. 2020 a las 15:17, Artyom Beilis (<art...@gm...>) escribió: > Hello Dear CppCMS users > > Have anybody used raw or asynchronous_raw with http_response? > > I'm doing some changes for HTTP/1.1+websockets+performance improvement > support. > The original CppCMS design had an underlying assumption that the basic > communication protocol is derivative of CGI protocols - FastCGI, SCGI. > > So when http web server was added it actually parsed CGI output headers > and converted them to HTTP ones. Thus use of raw/asynchronos_raw mode when > the user writes his own CGI headers instead of generating them via > http_response API was reasonable. > > Today I want to make an HTTP protocol 1st class citizen in CppCMS - which > means that I don't silently assume that all IO is CGI based. It is actually > a requirement for extensions like WebSockets and other things that can't be > passed via *CGI like protocols. > > Removing "raw" *CGI I/O would simplify the task. I can implement it via an > intermediate CGI parser but it isn't the most trivial task. > > So I need to understand if anybody actually uses this feature or I can > remove it in CppCMS 2.0.0? > > Artyom Beilis > _______________________________________________ > Cppcms-users mailing list > Cpp...@li... > https://lists.sourceforge.net/lists/listinfo/cppcms-users > |
|
From: Artyom B. <art...@gm...> - 2020-09-01 20:17:33
|
Hello Dear CppCMS users Have anybody used raw or asynchronous_raw with http_response? I'm doing some changes for HTTP/1.1+websockets+performance improvement support. The original CppCMS design had an underlying assumption that the basic communication protocol is derivative of CGI protocols - FastCGI, SCGI. So when http web server was added it actually parsed CGI output headers and converted them to HTTP ones. Thus use of raw/asynchronos_raw mode when the user writes his own CGI headers instead of generating them via http_response API was reasonable. Today I want to make an HTTP protocol 1st class citizen in CppCMS - which means that I don't silently assume that all IO is CGI based. It is actually a requirement for extensions like WebSockets and other things that can't be passed via *CGI like protocols. Removing "raw" *CGI I/O would simplify the task. I can implement it via an intermediate CGI parser but it isn't the most trivial task. So I need to understand if anybody actually uses this feature or I can remove it in CppCMS 2.0.0? Artyom Beilis |