Re: [Cppcms-users] Plugins, Localization, url mapper
Brought to you by:
artyom-beilis
Menu
▾
▴
Re: [Cppcms-users] Plugins, Localization, url mapper
|
From: Markus R. <us...@ma...> - 2012-03-06 16:05:01
|
Hi!
Thanks for your detailed answer.
Artyom Beilis wrote:
>> In the first example of the plugin interface you pass
>> the application pointer to the plugin. I think it
>> would be more decoupled if the plugin could create
>> its own stripped down application just for rendering.
>
> It is up to you, really.
>
> I just had shown the general concept how it can be
> done.
Yes, there are of course different requirements on how plugins should work.
>> Btw. the functions rendering to a stream should be
>> const, or do they modify the application? That change
>> would however break the API..
>>
>
> It is not const. Because when you call render to access
> response().out() that does many things under the hood.
>
> So even thou technically it may be const. Semantically
> it does not have to.
>
>> Is there any approach how to get booster::locale working
>> Inside own plugins?
>>
>
> No problem:
>
> 1. All applications that are build in hierarchy
> share same http::context() that holds the locale,
>
> 2. Also the response().out() stream has std::locale
> imbued inside it. That is why you can call
> for example <% gt ... %> from the view.
>
> Of course if you render to your own std::ostream
> then you should imbue the std::locale object.
>
> my_stream.imbue(context().locale());
That is working.
I was asking myself how the booster::locale::translate is working within
plugins. In the main program translate() is working, but not in the plugins.
I did not called std::locale::global(gen(""));
> But it is better to use <% render ... %> template
> to render the plugin's view, this way you don\t use
> intermediate buffers and render to the same ostream.
The advantage of using a own buffer to render is that it is completely up to
the plugins if they want to use cppcms rendering at all. They might directly
stream the text, e.g. for error pages or where templates are overkill.
But if it does not work well - see problem below - I may change to use
render() template. I do not understand the "With the command render"
example: In std::string main_html(cppcms::applicatin *app) the plugin still
renders to a buffer and returs the string, so what is the difference?
The problem I currently have with the streaming to buffer is when having a
form and requesting the POST data within the plugin.
E.g. I have the following code:
17 void My_plugin::do(std::ostream & buf, cppcms::application & app)
18 {
19 if(app.request().request_method()=="POST")
20 {
21 m_main.m_form.load(app.context());
22 m_main.m_form.validate();
23 ::std::cout << "x is: " << m_main.m_form.x.value() <<
std::endl;
24 m_main.m_form.clear();
25 }
26
27 app.render("plugin_skin","main_html",buf,m_main);
28 }
Then I get following exception:
2012-03-06 09:52:08; cppcms, error: Caught exception [Value was not loaded]
0x40566414: booster::stack_trace::trace(void**, int) + 0x24 in
/usr/lib/libbooster.so.0
0x4015fe9b: cppcms::widgets::base_text::value() + 0xcb in
/usr/lib/libcppcms.so.1
0x43132180: My_plugin::do(std::ostream&, cppcms::application&) in line 23
>> Is it possible with the integrated webserver to
>> have the script at /? If "script_names" is set to "/",
>> the url is localhost//name. If it is not given or "",
>> I always get 404 for every url.
>>
>
> Yes:
>
> http://cppcms.com/wikipp/en/page/run_application_web_server_root
>
>
> Specifically:
>
> http://cppcms.com/wikipp/en/page/run_application_web_server_root#CppCMS-
Embedded
Works perfectly, thanks!
>> Is it possible to reconfigure the internal file server
>> to be at another root?
>
> You mean "document root"?
>
> Yes:
>
>
http://cppcms.com/wikipp/en/page/cppcms_1x_config#file_server.document_root
No, I mean the root where the internal file server application is mounted
to. But it seems to be hardcoded with "" in line 238:
applications_pool().mount(applications_factory<cppcms::impl::file_server>(),mount_point(""));
> Also you may be interested in aliases:
>
> http://cppcms.com/wikipp/en/page/cppcms_1x_config#file_server.alias
Yeah, that seems to solve the issue.
Is there some explanation how this works if multiple applications are
mounted at the same root?
>> I am afraid I do not fully understand the url mapper.
>> E.g. I have:
>>
>> 27 attach (new Base_gui(srv),
>> 28 "gui", "/gui{1}",
>> 29 "/gui(/(.*))?", 1);
>> 30
>> 31 attach (new Base_rpc(srv),
>> 32 "rpc", "/rpc{1}",
>> 33 "/rpc(/(.*))?", 1);
>>
>>
>> For any reason
>>
>> 52 << "<a href='" <<
>> url("gui")<< "'>GUI</a><br>"
>> 53 << "<a href='" <<
>> url("rpc")<< "'>RPC</a><br>
>>
>> works for gui, but not for rpc? See following error for rpc:
>>
>> 2012-03-01 15:46:48; cppcms, error: url_mapper: key `' not found for url
>> `gui'
>
> Because when you map sub-application and refer to it
> you automatically referred to the default URL
> of the sub-application - empty one "empty key"
Sorry, I do not understand this statement.
There are some examples for mapper and dispatcher, but I can't find anything
related to how the url() call works.
Doxygen just says: "Map url-key key to actual URL, without parameters"
What does url("gui") does?
Can I use mapper().set_value?
I think copy&paste of how wikipp does + explanation would help, because the
redirecting + url resolving there is what most users want anyway.
> See:
>
>
http://cppcms.com/cppcms_ref/latest/classcppcms_1_1url__mapper.html#a249e59de419f7fd0241cab6634c68393
"Map the default key for the application, url has same rules as for
assign(key,url) but they rather refer to default application's URL when it
is used in hierarchy. "
does not help much either
> Also I'd recommend to update to CppCMS 1.0.0 as in latest
> version exception is not thrown in case of invalid URL but
> rather "/this_is_invalid_url" some something like that generated.
Done :-)
But I still get
http://localhost:10000/this_is_an_invalid_url_generated_by_url_mapper
best regards
Markus
|
