Thread: [Cppcms-users] Plugins and templates
Brought to you by:
artyom-beilis
Menu
▾
▴
cppcms-users
|
From: Julian P. <ju...@wh...> - 2010-08-18 20:43:09
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hallo, for one of my applications I'm currently developing a plugin system. The plugin is deployed as shared object and contains some methods that work with a content class that is derived from cppcms::base_content. Now I'm looking for a way to deliver the required cppcms template alongside the plugin (e.g., for a way to plug the required view into cppcms for rendering the plugin's content). To achieve this, I first wrote a template file for the common layout that the output of all plugins share and compiled it into the main application. Now each plugin has an own template file which derives from the master view and overrides some template functions to customise output. The template file is compiled as shared object after parsing it with cppcms_tmpl_cc. What I want to do now is to load the shared object and use the views contained in it. The problem I stumbled upon is, that cppcms complains that the named skin already exists when I try to load the so file as described in the online documentation via the config.js file, and of course it does, because the master view compiled in the main binary shares the skin with the view in the shared object, because this view only extends the master template. One solution that came to my mind is to not specify a skin in the master template and instead passing one with -s to cppcms_tmpl_cc to create shared objects that contain the whole stuff but all have another skin to be able to load a shared object file for each plugin and use them side by side and specifying the skin for the plugin in the render method. Is there another, perhaps more elegant method to achieve the behaviour I need? Thanks, Julian -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJMbEXUAAoJENidYKvYQHlQnz4QAMg6PTq1qPWp8qUxzQi+BZ4O 5iKR4jRBmu2K6DG+2gJjggd01c7loGvXKUxQwaBHHg7ew4UCN6VlWVU1pXdcnaUb APiGCAeYgMjMsrw/1sAbNnkJlq3FyjPA+8s92CP3gWG1syamTVWnFDeCnInZJB3V /8JWTAHPnYwSPYWCTQe5HkopEubaRsDsBvCgEBOT/vqzDKP6wHKmBMS4O/qNq1Xi V6997ZkLTzuj1O/GPwJGKHPdj4mhfl5RmMMSckrKLmuaHNM85dz1VXSwY/quzrna sVghuOq5sVeXmLDFAxNshtVBUJm2iVU919mISN3U+ko1dDtByWLw+1V34ZkYknSb /WL8EWQWEowoRh7t8i85D4erA7xT59u/mXquVGumv2qbFOex799wvS0Qv9uCwjqu AUJR8d1JxC/csuYARvcu+U1tKicFlNsD5P3NHq9mWljYRdEfk+Lo3WI9k/ze5D/6 Y5I/xrzdovdoqkzt/eIuQ/Iw/xnD4rq5hyZc6Srp74UoquvlPmYKtyGKapnqxkec VDEDGLEfSt+LiEo5w85Lk8IjlXDSaI7dX9CwdEBWVEEffCA2gxnYtQ7kQVIthgSu D2btah6zBLDT7C0bjqK095DbziyvpJVmyjoT2rC27yEfr1vmqs43CUssji/k06sT +PC9qwdDTD3uORLuGwQT =rLhn -----END PGP SIGNATURE----- |
|
From: Julian P. <ju...@wh...> - 2010-08-19 01:23:25
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Just another question:
The plugins currently return their own content class derived from a
master class containing common properties such as a page title.
Because C++ doesn't allow to redefine return types when overloading
virtual methods, I use a booster::shared_ptr<content::master> for
passing the content class.
The problem that occurs is the following:
Example:
Plugin HelloWorld has a content class content::hello_world derived from
content::master which is returned on calling handleRequest() wrapped in
a booster::shared_ptr<content::master>. This content class now has to be
rendered by the main application which does not now which content
subclass is wrapped in the pointer / knows it at runtime only, so that a
hard-compiled conversion via
booster::dynamic_pointer_cast<content::hello_world,content::master> is
not possible, because there could be other plugins returning different
subclasses of the master than hello_world.
The plugin tells the main application to use the view 'hello_world' for
rendering. This view uses content::hello_world, because it needs access
to some fields defined only in the subclass.
Now, if I call
render("hello_world", *c.get());
where c is the returned shared_ptr, cppcms catches a std::bad_cast
exception occuring in http_context.c, line 132.
If I use booster::dynamic_pointer_cast beforehand and pass the casted
shared_ptr, everything works.
So what I need is basically the following:
1. A way to use something like dynamic_pointer_cast with a type that is
known only at runtime (could be queried from the plugin)
2. Or: The template compiler should not write a constructor expecting
content::hello_world but instead from a
booster::shared_ptr<content::master> which is then
dynamic_pointer_cast'ed to the required pointer to a
content::hello_world. Assumption for the compiler would be, that the
base class is always content::master, so that the information from <%
view uses content::hello_world %> would be used to construct this:
content::hello_world &content;
hello_world(booster::shared_ptr<content::master> ptr) {
booster::shared_ptr<content::hello_world> hptr =
booster::dynamic_pointer_cast<content::hello_world,content::master> (ptr);
content = *hptr.get();
}
Any ideas on that matter?
Thank you,
Julian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.15 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBAgAGBQJMbIeDAAoJENidYKvYQHlQqLMQAMXLquJctetMqg47huo+4D8l
Z1a70oCfCwtQjL0DYdV7o8zMBZL4CKjC3H7i0XsCVcR3TokFl+EjBCQtJEQK+JQE
ZWQ2SwhY3HwKELaNSF2wXt0H+iZgwjLDc2UUvx9t0hEpdesoL0LG2Nl0FgBUvGX7
BxUDmspjiWBsFTfSBHB9sVy4Iq7RXD5HLvnIJEaYN8KnZ8NmllLIl+VX/N3ECrgW
GNxD057MRih2eMn999GWEoRJPOytMWwgq0F2IQRdzRPKIi+BQbFWXwQRQ7i0mbUX
Lmm6WRbqGjt+eeEZWz6QkAsvX52xgJWGLPJw+PQmXADpd2O0PV2WS9uqtVxdeSrP
fatJwAl/2+9uj5uIXKhkiHhkqW9AmmNIXGDgeo9F17RsryCgsWqlVlpSQoZBXSA0
g6PpIm2iDGBVue1+5X9LMxUbVLv7m1rJNaXJIsHg9yN/ebBK9li23zXFffQ2I1uj
z2o4O+WoyOD6vCUbYa38M2kJU+Iuwwt4fjvZVmbr0wezeLUPtsXp2Zw5DLZNWUC1
gEhmCrDFvgQXcUvlQwYzmDYLPrNq7y5ovkgRccNt/kY0kxLJouahNtFfv7GLnVIl
BWjef8qQ4vS+l9h6e5g5R+Et50DSSDKqpdoWGSr4YvaG5cCjEpfI9doISC05QTSv
o84I1M1kAcEpUQGu9Q23
=hpb4
-----END PGP SIGNATURE-----
|
|
From: Artyom <art...@ya...> - 2010-08-19 07:28:36
|
> Just another question:
> The plugins currently return their own content class derived from a
> master class containing common properties such as a page title.
> Because C++ doesn't allow to redefine return types when overloading
> virtual methods, I use a booster::shared_ptr<content::master> for
> passing the content class.
Actually you can redefine. But not for shared pointer but rather for
ordinary pointers and references. i.e.
class A{}; class B: public A{}
class foo {
public:
virtual A &get();
};
class bar {
public:
virtual B &get();
};
Is legal as B derived from A. This is what is called co-variant types.
So you may do this.
> Example:
> Plugin HelloWorld has a content class content::hello_world derived from
> content::master which is returned on calling handleRequest() wrapped in
> a booster::shared_ptr<content::master>. This content class now has to be
> rendered by the main application which does not now which content
> subclass is wrapped in the pointer / knows it at runtime only, so that a
> hard-compiled conversion via
> booster::dynamic_pointer_cast<content::hello_world,content::master> is
> not possible, because there could be other plugins returning different
> subclasses of the master than hello_world.
> The plugin tells the main application to use the view 'hello_world' for
> rendering. This view uses content::hello_world, because it needs access
> to some fields defined only in the subclass.
>
> Now, if I call
>
> render("hello_world", *c.get());
>
> where c is the returned shared_ptr, cppcms catches a std::bad_cast
> exception occuring in http_context.c, line 132.
First of all `render` function always receives `content::master` and
dynamic casts after-wards in views to correct content. If cast
fails it throws bad_cast.
> If I use booster::dynamic_pointer_cast beforehand and pass the casted
> shared_ptr, everything works.
What do you cast? Do you mean that you cast to `content::hello_world` ?
It seems to me this is more shared object issues.
Do you compile your application with -rdynamic or --export-dynamic.
see:
<http://art-blog.no-ip.info/wikipp/en/page/cppcms_1x_templates_bld#Dynamic+Loading+of+Views>
Because use it looks like this issue.
If you don't compile your applications with -rdynamic, dynamic cast between
shared object boundaries
may fail.
This is very important to remember.
Artyom
|
|
From: Artyom <art...@ya...> - 2010-08-19 07:10:39
|
Hello,
> One solution that came to my mind is to not specify a skin in the master
> template and instead passing one with -s to cppcms_tmpl_cc to create
> shared objects that contain the whole stuff but all have another skin to
> be able to load a shared object file for each plugin and use them side
> by side and specifying the skin for the plugin in the render method.
Yes I think this is the way. I would suggest following.
1. Compile entry skin for each plugin, acutally this what I'm doing
for each skin/view.
For example if I need two skins I do something like:
master_foo.tmpl
master_bar.tmpl
shared1.tmpl, shared2.tmpl
Then I compile all of them into two skins:
cppcms_tmpl_cc master_foo.tmpl shared1.tmpl shared1.tmpl -s "foo" ...
cppcms_tmpl_cc master_bar.tmpl shared1.tmpl shared1.tmpl -s "bar" ...
In your case it would be:
master.tmpl
plugin_foo.tmpl
plugin_bar.tmpl
cppcms_tmpl_cc master.tmpl plugin_foo.tmpl -s "plugins_skin_foo" ...
cppcms_tmpl_cc master.tmpl plugin_bar.tmpl -s "plugins_skin_bar" ...
It duplicates the code but makes the life much easier as you don't need to
deal
with classes.
And you may add some query to pluging to get its skin name.
2. Another option is to use separate skin for what plugin need to render. For
example
if the pluging need to create a one or two pice of HTML you may create small
skinks that render only these parts for them and each one of them has its own
skins.
I hope I understand your question correctly.
Artyom
|
|
From: Julian P. <ju...@wh...> - 2010-08-19 16:49:50
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Would it be possible to register a view at runtime? As I see in the code
generated of cppcms_tmpl_cc, the template loader registers the skin
alongside with a mapping_type that contains the name of view and the
appropriate handler class / the result of passing it together with the
required content object to view_builder.
So could you add a call like
cppcms::views_pool::static_instance::extend_view("skin","view
name",&cppcms::views_pool::view_builder<skin::view_class,content::master>);
that I could call in the constructor of my plugin?
I would then compile the output of cppcms_tmpl_cc excluding the loader
to my shared object and could add the required views at runtime to
cppcms view_pool.
It would be good if there also was a call like reduce_view("skin","view
name"); just to remove a view when plugin is unloaded.
Thanks,
Julian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.15 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBAgAGBQJMbWClAAoJENidYKvYQHlQydIQAJb4slmqYNrrEYrbWGX3zeBi
+mODXwD2CeDaKO3dbDS8RFBO+Fm53iZfqDKe9dKB8Ao0cWQW3HM914iEIsu+fB7g
Q1qtSRziPByiX7aBBDxvVjpM0BmwlhkoYGirGNzH4mxzlyA9JekdszMOiRL3uDZL
U1KCxsvSWNUoAmpTRUZJwrOsRdM2d6MmDToW2oq2caoKpeqTkYYIWSSOSDGjLyjh
wm8d8othE7AafE9wpfwodDDXJyhxkGwB/fiUwOVJ9ezeUjPLXwT6ZfZkko0DYXT4
4nCPueq9/t73jpNvxT8mjsQ1j/XV9Qs1ina1ou6XPDtoGONuFToBJSiMW7XmqCy8
nD3bEHhsGlF2MHZjOP1pd+IDhy8uOIuOeaZJo9WEKm+U/uX9U8qfVAJttCIRONil
MoyQX1U8W5Ezxl6gxJ7vc+wAmk4aj04JDOZtduYz3pd3Kp1x06R3PmovlI75Fg6c
9MVz7dWHweTArFWQbMs/pm9WX8arKCaFLBH5aKT5YC6PQMUny5xoJTaXcjREHt7H
ifAbsTRyYr9yELNmiYIasxq+YJLNSyiaxYE+LZzdZmsrDuFb2RJolIQapRIMO4oG
joEszGfd/Njfmz5oACoB6VGdbimTJKhQvlC9VZAqlLIUG2DhwWScoDlHILEd51NL
KaqLRkg7weBreMEOda8K
=VFk6
-----END PGP SIGNATURE-----
|
|
From: Artyom <art...@ya...> - 2010-08-20 06:46:36
|
>
> Would it be possible to register a view at runtime?
>
Not sure. It would required making views loading
and unloading be thread safe and make the interaction
with actual DLL quite complicated.
However, I do not really like the views_pool implementation so it
is likely to be updated and may be this feature including unloading views
may be implemented
You may open feature request in bug tracking system
Artyom
|
|
From: Artyom <art...@ya...> - 2010-08-20 07:02:47
|
Hello, Also there is a solution you can do: 1. Compile the skin into the plugin: i.e. create cpp sources for skin and link them into the plugin shared object. 2. When shared object is loaded, it would be automatically loaded to static instance of views pool and unloaded when shared object goes. 3. In the plugin itself you can use views_pool::static_instance().render(...) to render the view. 4. Note: you can't load and unload two plugins simultaneously as it would not be thread safe, 5. When plugin is unloaded, the skin would be automatically unregistered from the static_instance of views_pool. Note: this behavior is undocumented and may be changed in future. You'll get the notice about it. Artyom ----- Original Message ---- > From: Artyom <art...@ya...> > To: cpp...@li... > Sent: Fri, August 20, 2010 9:46:29 AM > Subject: Re: [Cppcms-users] Plugins and templates > > > > > Would it be possible to register a view at runtime? > > > > Not sure. It would required making views loading > and unloading be thread safe and make the interaction > with actual DLL quite complicated. > > However, I do not really like the views_pool implementation so it > is likely to be updated and may be this feature including unloading views > may be implemented > > > You may open feature request in bug tracking system > > Artyom > > > > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by > > Make an app they can't live without > Enter the BlackBerry Developer Challenge > http://p.sf.net/sfu/RIM-dev2dev > _______________________________________________ > Cppcms-users mailing list > Cpp...@li... > https://lists.sourceforge.net/lists/listinfo/cppcms-users > |
|
From: Julian P. <ju...@wh...> - 2010-08-20 08:05:26
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 20.08.2010 09:02, schrieb Artyom: > Hello, > > Also there is a solution you can do: > > 1. Compile the skin into the plugin: i.e. create cpp sources for skin > and link them into the plugin shared object. > 2. When shared object is loaded, it would be automatically loaded to static > instance > of views pool and unloaded when shared object goes. How does this work? Do I have to invoke the loader in the plugin's setup code or is it somehow invoked automatically if I dlopen the library? > 3. In the plugin itself you can use views_pool::static_instance().render(...) > to render the view. > 4. Note: you can't load and unload two plugins simultaneously as it would not be > thread safe, > 5. When plugin is unloaded, the skin would be automatically unregistered from > the static_instance > of views_pool. > Does a simple dlclose() cause that behaviour or do I have to call something in my plugin's destroy operations? Thanks, Julian -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJMbjc7AAoJENidYKvYQHlQOH8QAItTvNZdNfVgmcObyRwTxer7 xq4FrC6A3u6Qy0sVgifadWwjmBxi5FMWa1QsOPEn5WtNgBrX96WjAgq1iixDk92C FIOkLBhrNC0xflX1i9FpeRGRQYq44VQ4TElhzLFDAQJuyPyh8qgoJXj7NyK659sx wgWvzTvXl9zvYqjCPgRkTCkuHEgtAmwXYBQGcBezlw580h+wSiBpdKU+Sia1hT9N NFjRLWjPZcZ4qnr5OMzF4o0vR+oZEr1FQCoKfZrvA6MaoA4abJSHj99jfB4XGzlI pa3FxPCbxNIALIGDj/Ye220Rz/gUiPa9dAoQdBIdYBSbnxMn1SQZaiNO0HdR9TWc IU2m3gLUow99avXopxfQQjn2qS8AAEUE825v2y6V99eFlllFsgYnMePe4I19HPWS xY+xIhsvJBV3mCnOSMQo7y9mgLFQEbzq6bw98idKR0r7iZ8IWkbPhfSq4Fm9AxVN 42gun8of3T74WAKBq+tz98WhO9WKyzj7fEovS5yYmkXNcipdkCTfVeo8tkNjW4Y0 BIj1b5oCuZWMqpFDbQ/kIBiG31oh6FWw9Ml1gAYX/LLN/4PKNzuRc48fletbkWmJ aslAbFHYOURp8i+JH4cWWprZ7VWFQDFdCzHKX3qQDlcmoyB1bXu7SUKivYMfmpEz SpC44ivZess1QtSFBSgY =N8DI -----END PGP SIGNATURE----- |
|
From: Artyom <art...@ya...> - 2010-08-20 08:30:49
|
> > 2. When shared object is loaded, it would be automatically loaded to
static
> > instance
> > of views pool and unloaded when shared object goes.
>
> How does this work? Do I have to invoke the loader in the plugin's setup
> code or is it somehow invoked automatically if I dlopen the library?
Yes. view registration is done by global constructor placed in created
c++ file, when shared object is loaded it's constructors are called
automatically.
> > 5. When plugin is unloaded, the skin would be automatically unregistered
>from
>
> > the static_instance
> > of views_pool.
> >
>
> Does a simple dlclose() cause that behaviour or do I have to call
> something in my plugin's destroy operations?
>
Yes. It unregistered in global destructor that are called automatically.
Actually this is the way you can put view's code into your
project and it would "just-work" without giving any specific notices to your
code.
Artyom
|
|
From: Julian P. <ju...@wh...> - 2010-08-21 01:03:56
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ok, implemented this solution and it works! Brings me a big step closer to what I want. Just have to play a bit with the CMakeList.txt that shall generate my templates automatically, doesn't work as it should right now ^^ Many thanks, Julian -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJMbyXxAAoJENidYKvYQHlQ0S8P/jWM69Z9cVblEvy0XEczeRMG 5yTHjJ+d4DahwfRa6c4sR2yLJmOw3B/RsJniNvmLGSyIEgiKLepDUj4esNtsSSrN HkWmQKv5eWZbs/yYQ8H1F0zc6oNAS1PNFnVHrPvf78y5evY3e74BhChIWWIJPRzE Nfr1qqC98h7y/R2QfT2Ec0XGxyEKdwcL/ZbF1PlMH2nB/kIWd/KpSA0QfZZvozhF 643OdsePFRdAm1c4gn4HiTx6kg3cRIGFg27HNMsdjPBu0+v0AYdKTEc/QASfV2E9 UQ964wEf5YFU4HHJ5tp0KIJ/1+X8BGgfTarDuvBftrYS9KSJLxAiRx+VdW65nWuX U67UpeZl+Dcxm5djpZHfp//xEzJ5Mdiz9kmLdLZ8iW90lRkIvNqe+rCixgxWEpa2 wPf4YzI3Fob1uvCHPifAuWAU19zPxWMeGLabmyIIMNBMe3F+Z7o/hhEl9LJCKn6U LXk0osDDTzZP53MjU4MV63lxSi8b1vzev4+8uddRMbt0amIEzGq9Y3j39KASibJA YumtxJic5e6GfdEw2oSQ/UqBvPSeouKdE+Zir7BinfcEMo6Mc3xqG7b00aY10eF4 31NXue6AyGgqpZxDJx3mJB6lBoFnIIlszoe8aR+eZX+cGGEwqVImQaq390fIYTUf BAnbDJlhKUJkYP61Sc9r =PMyE -----END PGP SIGNATURE----- |
|
From: Artyom <art...@ya...> - 2010-08-21 08:36:23
|
> Just have to play a bit with the CMakeList.txt that shall generate my
> templates automatically, doesn't work as it should right now ^^
Take a look on wikipp's CMake file sources, it would give you an idea.
|
|
From: Julian P. <ju...@wh...> - 2010-08-19 16:58:10
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Am 19.08.2010 18:49, schrieb Julian Pietron:
> Would it be possible to register a view at runtime? As I see in the code
> generated of cppcms_tmpl_cc, the template loader registers the skin
> alongside with a mapping_type that contains the name of view and the
> appropriate handler class / the result of passing it together with the
> required content object to view_builder.
> So could you add a call like
> cppcms::views_pool::static_instance::extend_view("skin","view
> name",&cppcms::views_pool::view_builder<skin::view_class,content::master>);
> that I could call in the constructor of my plugin?
> I would then compile the output of cppcms_tmpl_cc excluding the loader
> to my shared object and could add the required views at runtime to
> cppcms view_pool.
> It would be good if there also was a call like reduce_view("skin","view
> name"); just to remove a view when plugin is unloaded.
>
> Thanks,
> Julian
Additionally, it would be nice if cppcms_tmpl_cc could be modified to
generate a header file alongside the cpp, so that I can easily include
it into my plugin and use all classes that have been created by
cppcms_tmpl_cc.
Many Thanks,
Julian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.15 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBAgAGBQJMbWKZAAoJENidYKvYQHlQ0dgQAKRYADJ5xE43bh3WV88vHE0S
UlBqSfP/jug0EqnYHrLtM8xyYDwXVeWmG/uumvJUH2WreHxpPHwFv3ihLXiT68mT
R4KCzOr+H60KNFzEfVRx3+Ue0JZIJMp8ZBqsZnMmdEWgaYjah8GaLYziVXKepTn9
iZErFpeLYqMe0FYjPEZH4e39GB2BSEHDow+20QYiTMsNiI8roiQ7MQnfKNn40KxX
+6LNa0AfGSZ9tNsU5jiAL3QUi4v6RhYUK3+KWK3IigGf4y9dEHAjZTS85Xc7M2ch
Qmt41JmBKLZMkmSTasW6zD0FKzDhIqFehuMxx05oafyzTAYkQaE7j59QobbTkxDQ
zcope+Z7K05LAwCvv6iVAOyK0fItIqoQNGGCH37sr/Ekxj2LRPWBDcz7BzxKHuQV
zuEnYy4UpEklI+Iu9bBvxv0mH6PR7LdHDEQsl5jfVhGgCgrUFf9ryY/vMweknJxO
6l9S/udeVB4s8SriEfsP/yikiCTJJXUnF1ArqV00HrgC1CqhhO2JaAik0aavedXB
zSychX8kBvDL5GJGTK+8T1tgE1uGPhdr5n8ZaS8MTqS7tgpBjmCCXbpQHhi5YGLB
HVFr42n67ZQr2Epu58ehHwYEIh68Sg7Xb9i3rw0JDtAbhRnT4jhEjhnZaND/EV88
ZBixLDfl0f1umwcrwPS0
=u/8a
-----END PGP SIGNATURE-----
|
|
From: Artyom <art...@ya...> - 2010-08-20 06:51:59
|
>
> Additionally, it would be nice if cppcms_tmpl_cc could be modified to
> generate a header file alongside the cpp, so that I can easily include
> it into my plugin and use all classes that have been created by
> cppcms_tmpl_cc.
>
I thought about it once, but it requires quite complex changes in cppcms_tmpl_cc
that I'm not sure what the benefit you get from it.
The biggest problem is automatic view registration - all views are register
them selfs to cppcms in share object loading. For example how would you
register a view's templates derived from other?
Also note, there is almost no problems renaming .cpp file to .h
with exception of automatic registration.
So I don't really it comes in near future.
Artyom
|
|
From: Julian P. <ju...@wh...> - 2010-08-20 08:01:47
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Am 20.08.2010 08:46, schrieb Artyom:
>>
>> Would it be possible to register a view at runtime?
>>
>
> Not sure. It would required making views loading
> and unloading be thread safe
At least for my case thread safety for loading and unloading views
wouldn't be a problem, because my plugins are loaded sequentially for my
Plugin registration class not being thread safe either.
And wouldn't a simple thread lock suffice to allow only one call to the
views_pool loading system at a time? I think boost features already some
implementations in its thread part, you could integrate that to booster
as well if it isn't integrated yet.
> and make the interaction
> with actual DLL quite complicated.
What about a solution that would employ another factory here, a factory
for the view classes. So I could simply create a factory instance for
each view I want to register from my DSO.
Then my plugin would issue a request of this form in its constructor:
cppcms::views_pool::static_instance().extend_view("skin","view
name",booster::shared_ptr<viewfactory>)
Where the viewfactory pointed to by the shared_ptr would generate
instances of
cppcms::view_pool::view_builder<skin::view_class,content::master>
So interaction should be simplified.
> However, I do not really like the views_pool implementation so it
> is likely to be updated and may be this feature including unloading views
> may be implemented
>
>
> You may open feature request in bug tracking system
>
I'll do that later this day.
Julian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.15 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBAgAGBQJMbjZhAAoJENidYKvYQHlQGC0P/j7Bb9chCKO6YHze9cNxUzYM
JhxQr8OjCS1kp7VyanN9dCsV2u8mHHoKylnOSdFlDoYKodGqo1azpqBDXuKbIKKl
g5VxpHIubknmApUp9RGQYU8bvqYrHfrc/v+F6ajxFCf+nxU4YGSa7reWdvrTsR7l
kt5yAjDuxUdf+O04DDUkQIQUZA0JmVPqnG2X28cklT5g54qnNIksvuuTw7gfgZ7b
/Vcu93sgJOOmQv5v51XF7LUH9h0IjTpxc2evO+FJyVEghEMsyJlelPnyWW88fh3K
pdqCv7KKOh+fMhtfjHSWHPJENpSe/Sy8pvdEOj2yvlIrJADPOLuxCgcJ9AJr4ThN
ulefQ+Cs2aOPk6IapX2A/i/pkA+Ugg4pUP5n+bnlg7J1Sz1tTrNo8C3uE+LfLn0H
3R7MlIVoKcH/T6tahZBy+mcxsZjg4zyIYDmmEOKN0tp1qGvLJGmTYWWuglUIQobw
EoeqWOiZ/CcJ/YlZvBA8NSssHtAZxbk8FS+i5h9wJUk1HdhkR/iuXQ7FnKnVuXez
MLy/NFiS45PetA9xYPlPAhN6KkWcOe7w168U30QdKw8sGOuzLxYn0+ERB4d0ZDuf
kWDNP9IFqE2kZ/+DknFZyiQfCoT45wQHYfS8wDwTjVw2jQdTUdlNEBf9B6Zt5vtI
6/16BFhTI4H0MtONfK6l
=Whjs
-----END PGP SIGNATURE-----
|
|
From: Artyom <art...@ya...> - 2010-08-20 08:36:25
|
> >>
> >> Would it be possible to register a view at runtime?
> >>
> >
> > Not sure. It would required making views loading
> > and unloading be thread safe
>
> And wouldn't a simple thread lock suffice to allow only one call to the
> views_pool loading system at a time? I think boost features already some
> implementations in its thread part, you could integrate that to booster
> as well if it isn't integrated yet.
Than not that simple, think of unloading view while it in use.
When using view you don't really what to hold a lock.
Actually something like that is done in automatic views reloading,
using RW locks... You may define if you recompile the shared object/dll
it would be automatically reloaded. But it may have major performance issue.
I need to think about how to do it right.
In any case, it may be doable, but it should be done very carefully
Artyom
|
|
From: Julian P. <ju...@wh...> - 2010-08-22 19:22:34
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 21.08.2010 10:36, schrieb Artyom: >> Just have to play a bit with the CMakeList.txt that shall generate my >> templates automatically, doesn't work as it should right now ^^ > > Take a look on wikipp's CMake file sources, it would give you an idea. > > Where can I find the CMake file sources for wikipp? Even in SVN trunk I'm just able to find the standard ./configure, make make install configuration. Thanks, Julian -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJMcXjtAAoJENidYKvYQHlQ4wEP/A7lCKEkxSJZE6JPgwOB3k39 ryuYllzIpk5FeR+nkmkz8td4eWydcaMe7Mo+YmCsEBrDQPq/9+Eq5ihCgTd4XgWp rarWRz8xoJctinBP4ZXHLPUdz/Rwl871F3NJbkChXaU/RjcCHJ5w6zs2KwekP1Z/ iJMPgmdbvrvFZgEwwlv7K3oQWK193BA/eUsxFs1mxVVQoIcvvLD40i6HEJzn1ICa 8I/lv4TImxtIqTyl6Y/f2nmAYNRovWNznWGjJa3TgtSauNatHm9sfhhUKPLz/SGB X/SZ5AOHAb9Ca+8ziHGvgC9EDoRsd4xVDzpfAjD5IMo9/j/Flk11FO9ScMTGyl+a a1VwpiK4BeaftSnZxz2eaHFsCn0vFDm/wiWpjKdlKkuMxG+u5I+OVZk2DFSWZdla hJNeyHJghjH8iP7tnCjMD7IUl6qs6M4oCaQAuCCy3oiZpVTGKM2tv5d2Iioo+HIn a1YcvCiV34V+8X4AtCpqZcJafEn+ivKMbc+BULLFFHBAX/EnqK9REcbb5Gq8pgI+ km5TxeHRKivQqZ/IfNyMJe+K2Z7KBHIg5FukX+Nu2AxxFSISxz3gxqhPxvDSSW7g 97WO+SOiLwpZvxWk8yU3ntcv0CeFt2oBfGevKhSB5gBd/sIOqd6+jDwOpZLBUNes SUsMVACLP0Y2slAIyH29 =zS4O -----END PGP SIGNATURE----- |
|
From: Artyom <art...@ya...> - 2010-08-22 19:37:45
|
See: http://cppcms.svn.sourceforge.net/viewvc/cppcms/wikipp/branches/for_cppcms_v100/ It is not in trunk, it is in branch Artyom > Where can I find the CMake file sources for wikipp? Even in SVN trunk > I'm just able to find the standard ./configure, make make install > configuration. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X