as far I as know how the childrenswitching system work, it switchs layers
(or layerGroups), not mapfiles
if only generate one mapfile, but give the layers an additional id
corresponding to a selected switch
after discussing a bit with one of my colleague, the only way you have is to
"duplicate" your projects and set in each a different mapfile
then you can use the project switcher menu to change easily from one to
another
see the "Choose project" menu in http://www.cartoweb.org/demos/client.php
name it "Choose mapfile" and the users wont notice they effectively change
of project
to make things easier, one can certainly imagine to have the file of the
projects "copies" to simply use symbolic links to the original project, with
just the few different files in hard, like layers.ini and the mapfile
or use a automated deploying/copying script to generate the project copies
easily
regards
Oliver
Hello Oliver,
thanks. That worked. Maybe, you could help me with the other question that
I wrote in the original post?
"I am still looking for a possibility to handle more than 200 layers in
one project. Since an extended plugin and recompiling mapserver are
(currently) not an option, I thought about using children switching.
Therefore, I divided the layers into two groups with less than 200 layers
each and assigned a switch to each group. The map files for the switches
are generated, but each file contains all layers. Based on the
documentation I thought that the mapfiles generated for one switch would
only contain the necessary layers. Am I doing something wrong? Is it
possible at all to handle that many layers using children switching?"
Thanks very much,
Dirk
Oliver Christen wrote:
well, the problem come from the loadFromArray function (defined in
Structhandler.php, called from ClientExportPdf.php)
this function try to convert a string like foo.1.bar into a object
hierarchy like foo->1->bar and it doesnt like at all "->1" (in this
exemple)
so I would suggest you simlpy modify the setPdfObjects function in
ClientExportPdf.php to feed the function a modified $ini_array, where you
would have removed the extra parameters you added with the syntax
foo.numericvalue.bar
this way you can add as many extra parametesr you want with the
foo.numericvalue.bar syntax without having side effect on the normal
exportPdf code
by the way, it is perfectly normal your cExportPdf.ini is ignored, from
cartoweb point of view, you are using the exportPdf plugin. You would
have the same problem if you added, css, js or images, You would have to
put them in the exportPdf folder.
I hope this help
regards
Oliver
Hello Alexandre,
that's my my plan. However, I can not figure out, how / where to add the
additional keys. If I add them to exportPdf.ini (as proposed in the
documentation), I get the error message. If I add them to cExportPdf.ini
(cExportPdf is my plugin, which extends / replaces exportPdf) the
entries are not available.
I can not figure out, how the ini files are handled. For example, in
location.ini or locate.ini, entries like
scales.0.label = 500
scales.0.value = 500
scales.0.visible = true
work, but if I use similar entries with a number in exportPdf, they do
not work. How do I tell my plugin to read such kind of entries correctly
without changing the original exportPdf plugin too much?
Regards,
Dirk
The simple problem that I can not solve is: How do I get my extended
plugin to read the additional configuration entries so I can use them
within the Client class?
Have you tried to adapt the following code, available in
ClientLocate.php:
$locate = ConfigParser::parseObjectArray($this->getConfig(),
'locate',
array('id', 'sql'));
_______________________________________________
Cartoweb-users mailing list
Cartoweb-users@lists.maptools.org
http://lists.maptools.org/mailman/listinfo/cartoweb-users
_______________________________________________
Cartoweb-users mailing list
Cartoweb-users@lists.maptools.org
http://lists.maptools.org/mailman/listinfo/cartoweb-users
