[Cppcms-users] Potential patch / suggestion

[Jon F. <jon...@jf...>]

Hi guys!

It doesn't look like there is a whole lot going on here. Is this the best 
place to discuss C++CMS?

I recently decided to test the C++ waters again. I've been working with 
FreePascal for a couple of decades now. My! How  C++ has grown in that 
time! In searching out the various C++ tools and libraries for my various 
development endeavors I came across C++CMS for web work. Although getting 
started with it has been extremely time consuming and frustrating I see 
some *HUGE* potentials and the goals that Artyom states are in-line with 
mine. Some minor bench-marking shows some astounding performance figures. 
So I'm committed to going forward with C++CMS.

As such I think I may be of some value as a NOOB reference for 
documentation. If there is some interest I can probably provide feedback. 
If it weren't that I found your project so intriguing I'd have never put 
the effort into learning C++CMS, instead turning to something like 
Ultimate++. The shortcomings that I am running into are probably turning 
other potential users away.

I'm attaching a simple patch that I used to make URL handling in the native 
HTTP server work better. Using URL rewriting to get around weaknesses in 
the internal dispatching is just plain silly and counter productive. An app 
running in the HTTP server should work the same as it would running fCGI 
from Apache or NginX, without needing code changes. In the usual OOP and 
Unix philosophies it should plug in and run, essentially the same, where 
ever you put it. This is not a completed patch. I'm including it as an 
example and to open a discussion if there is interest. Its actually working 
well for me already. Here's the patch:


-----
diff --git a/private/cached_settings.h b/private/cached_settings.h
index ea71ac1..8b5f1e4 100644
--- a/private/cached_settings.h
+++ b/private/cached_settings.h
@@ -125,7 +125,8 @@ namespace impl {

                                 script_names = 
v.get("http.script_names",std::vector<std::string>());
                                 std::string script = v.get("http.script","");
-                               if(!script.empty())
+        /* TODO: need to detect "" vs. missing (nullish) */
+                               //if(!script.empty())
script_names.push_back(script);
                                 timeout = v.get("http.timeout",30);
                         }
diff --git a/src/service.cpp b/src/service.cpp
index 8124ec4..cfabfe2 100644
--- a/src/service.cpp
+++ b/src/service.cpp
@@ -236,7 +236,7 @@ void service::setup()
                 if(settings().get("file_server.async",false)) {
                         flags = app::asynchronous;
                 }
- 
applications_pool().mount(create_pool<cppcms::impl::file_server>(),mount_point(""),flags);
+ 
applications_pool().mount(create_pool<cppcms::impl::file_server>(),mount_point(settings().get("file_server.uri", 
"")),flags);
         }
  }

diff --git a/src/views_pool.cpp b/src/views_pool.cpp
index 0dcb8a8..38f113c 100644
--- a/src/views_pool.cpp
+++ b/src/views_pool.cpp
@@ -140,7 +140,7 @@ base_view *pool::create_view(std::string const 
&skin,std::string const &template

         data::skin_generators_type::const_iterator 
t=reg_skin.find(template_name);
         if(t==reg_skin.end())
-               throw cppcms_error("cppcms::view::pool: no suck view:" + 
template_name + " is registered for skin: " + skin);
+               throw cppcms_error("cppcms::view::pool: no such view:" + 
template_name + " is registered for skin: " + skin);

         std::auto_ptr<base_view> v;
         v = t->second->create(template_name,out,&content);
----



This does a few things for me:

1. Allows me to move static file serving off of "/", so an app can be 
there. Web apps typically provide limited URL sets that serve static files. 
The rest of the URL space being covered by the "app".

2. Allows me to serve an app from "/", which is actually "" in the config file.

3. The last bit of the patch just fixes a misspelling that I found 
humorous. :-)

I think a "final solution" would be one that is more cooperative. Probably 
allowing the APP to pick and choose the URLs to serve and then fall back to 
static, or a more PHP style: look for static files and if not found hand 
the request off to the app. Both of these scenarios could be programmed to 
happen if the file_server was not _hidden_ as _private_, but instead made 
available as a pluggable app.

My main use case would be: I write an app and use the "http" server to run 
locally for development. Then deploy the finished app to the web server. 
The code should run unchanged regardless of URL pinning in either the http 
server or some other traditional web server. I would usually use Apache or 
NginX to serve the app on all URLs, except for certain branches reserved 
for static file content. The http server should be able to emulate that 
without me altering code to make it work (ie no mapper().root() calls).

And my patch currently allows me to do this so I'm off and running!

- Jon

-- 
Sent from my Devuan Linux workstation -- https://devuan.org/
"Init Freedom", Yeah!

Jon Foster
JF Possibilities, Inc.
jon...@jf...