Re: [pmapper-users] Plugins modifications
Ok I see.
Thanx for the tips, I am going to try adding a custom_plugin.js file.
I will also check if the plugins I modified are available as a class.
On Fri, Jul 26, 2013 at 7:04 PM, Armin Burger armin.bur...@gmail.comwrote:
The problem is that the custom.js file from your config directory is
loaded before the plugin JS files, so they will not have any effect
The cleanest way would be to separate the custom JS files from the
default JS files. Currently there is a a single check and all are
referenced at the same time. Since Thomas is probably using this
functionality more often I leave it to him to decide if the main code
should be changed accordingly.
A fast workaround would be to use something like a custom_plugin.js
and reference this in the classical way (script type=text/javascript
) in the map_whatever.phtml file's head section just before
the large link... / block.
There is no golden way of modifying the plugin PHP code. If the plugin
is written as a class you can create a new plugin that inherits from the
default plugin class. Otherwise you will need to check modifications in
the default plugin with you version, using whatever diff-like tool.
armin
On 07/26/2013 11:50 AM, Chris forum wrote:
Hi all,
Now that Thomas has updated several plugins, I realise I shouldn't have
customized them in their own directories.
I am now trying to put my changes back into custom.css and custom.js, in
order to not loose them at the next general update.
I am first trying to do that with the Coordinates plugin where I have
done
some modifications into coordinates.js.
So now there is a modded
*$.extend(PM.Plugin,
{
Coordinates:
{*
into my custom.js file, but it is not used/read by pmapper.
In order to have it taken into account, I have to delete that part in
coordinates.js
Am I doing this correctly?
Is there a way to have custom.js 'taking the lead' over the plugins
files?
What if a PHP file of a plugin needs to be modified?
Cheers,
Chris
--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
___
pmapper-users mailing list
pmapper-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pmapper-users
--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
___
pmapper-users mailing list
pmapper-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pmapper-users
--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
___
pmapper-users mailing list
pmapper-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pmapper-users
Re: [pmapper-users] Plugins modifications
Hi,
Try to inactivate the compression (debug level = 5 I think) and tell us
if the custom.js is before or after the plugins files please?
AFAIK I don't use the same compression functions than in standard
pmapper. So all js files are compressed in the same order than if they
were included without compression. So the custom.js (and all other
config/xxx/yyy.js files) is included AFTER all the plugins js files.
Thomas
Le 29/07/2013 09:53, Chris forum a écrit :
Ok I see.
Thanx for the tips, I am going to try adding a custom_plugin.js file.
I will also check if the plugins I modified are available as a class.
On Fri, Jul 26, 2013 at 7:04 PM, Armin Burger armin.bur...@gmail.comwrote:
The problem is that the custom.js file from your config directory is
loaded before the plugin JS files, so they will not have any effect
The cleanest way would be to separate the custom JS files from the
default JS files. Currently there is a a single check and all are
referenced at the same time. Since Thomas is probably using this
functionality more often I leave it to him to decide if the main code
should be changed accordingly.
A fast workaround would be to use something like a custom_plugin.js
and reference this in the classical way (script type=text/javascript
) in the map_whatever.phtml file's head section just before
the large link... / block.
There is no golden way of modifying the plugin PHP code. If the plugin
is written as a class you can create a new plugin that inherits from the
default plugin class. Otherwise you will need to check modifications in
the default plugin with you version, using whatever diff-like tool.
armin
On 07/26/2013 11:50 AM, Chris forum wrote:
Hi all,
Now that Thomas has updated several plugins, I realise I shouldn't have
customized them in their own directories.
I am now trying to put my changes back into custom.css and custom.js, in
order to not loose them at the next general update.
I am first trying to do that with the Coordinates plugin where I have
done
some modifications into coordinates.js.
So now there is a modded
*$.extend(PM.Plugin,
{
Coordinates:
{*
into my custom.js file, but it is not used/read by pmapper.
In order to have it taken into account, I have to delete that part in
coordinates.js
Am I doing this correctly?
Is there a way to have custom.js 'taking the lead' over the plugins
files?
What if a PHP file of a plugin needs to be modified?
Cheers,
Chris
--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
___
pmapper-users mailing list
pmapper-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pmapper-users
--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
___
pmapper-users mailing list
pmapper-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pmapper-users
--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
___
pmapper-users mailing list
pmapper-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pmapper-users
--
Thomas RAFFIN
Chef de Projet Internet
traf...@sirap.fr mailto:traf...@sirap.fr Sirap http://sirap.fr
Tel
: 04 75 72 84 10
Fax : 04 75 70 07 98
Rue Paul Louis Héroult - BP 253
26106 Romans cedex
--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
___
pmapper-users mailing list
pmapper-users@lists.sourceforge.net
Re: [pmapper-users] Plugins modifications
Hi Thomas,
Just checked, even with
debugLevel5/debugLevel
the custom.js is still read before the plugins JS file
What compression function are you using and where?
On Mon, Jul 29, 2013 at 10:48 AM, Thomas RAFFIN traf...@sirap.fr wrote:
Hi,
Try to inactivate the compression (debug level = 5 I think) and tell us
if the custom.js is before or after the plugins files please?
AFAIK I don't use the same compression functions than in standard
pmapper. So all js files are compressed in the same order than if they
were included without compression. So the custom.js (and all other
config/xxx/yyy.js files) is included AFTER all the plugins js files.
Thomas
Le 29/07/2013 09:53, Chris forum a écrit :
Ok I see.
Thanx for the tips, I am going to try adding a custom_plugin.js file.
I will also check if the plugins I modified are available as a class.
On Fri, Jul 26, 2013 at 7:04 PM, Armin Burger armin.bur...@gmail.com
wrote:
The problem is that the custom.js file from your config directory is
loaded before the plugin JS files, so they will not have any effect
The cleanest way would be to separate the custom JS files from the
default JS files. Currently there is a a single check and all are
referenced at the same time. Since Thomas is probably using this
functionality more often I leave it to him to decide if the main code
should be changed accordingly.
A fast workaround would be to use something like a custom_plugin.js
and reference this in the classical way (script type=text/javascript
) in the map_whatever.phtml file's head section just before
the large link... / block.
There is no golden way of modifying the plugin PHP code. If the plugin
is written as a class you can create a new plugin that inherits from the
default plugin class. Otherwise you will need to check modifications in
the default plugin with you version, using whatever diff-like tool.
armin
On 07/26/2013 11:50 AM, Chris forum wrote:
Hi all,
Now that Thomas has updated several plugins, I realise I shouldn't have
customized them in their own directories.
I am now trying to put my changes back into custom.css and custom.js,
in
order to not loose them at the next general update.
I am first trying to do that with the Coordinates plugin where I have
done
some modifications into coordinates.js.
So now there is a modded
*$.extend(PM.Plugin,
{
Coordinates:
{*
into my custom.js file, but it is not used/read by pmapper.
In order to have it taken into account, I have to delete that part in
coordinates.js
Am I doing this correctly?
Is there a way to have custom.js 'taking the lead' over the plugins
files?
What if a PHP file of a plugin needs to be modified?
Cheers,
Chris
--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
___
pmapper-users mailing list
pmapper-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pmapper-users
--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
___
pmapper-users mailing list
pmapper-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pmapper-users
--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
___
pmapper-users mailing list
pmapper-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pmapper-users
--
Thomas RAFFIN
Chef de Projet Internet
traf...@sirap.fr mailto:traf...@sirap.fr Sirap http://sirap.fr
Tel
: 04 75 72 84 10
Fax : 04 75 70 07 98
Rue Paul Louis Héroult - BP 253
26106 Romans cedex
--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application
Re: [pmapper-users] Plugins modifications
Indeed I've modified the core code to compress files in the same order than if they were included without compression (in my version js files are not included in js_session.php). It is complicated to compare with the clean pmapper code, because 1) my version is using differently the configuration directory - common directory : /pmapper/config/common/js_config.php *.js *.css - optionally defined in the final configuration in pm_config_location_commonXXX/pm_config_location_common : /pmapper/config/XXX/js_config.php *.js *.css - optionally defined in the final configuration in pm_config_locationYYY/pm_config_location : /pmapper/config/YYY/js_config.php *.js *.css 2) I have modified the behaviour of pm_config_commonYYY/pm_config_common to include an intermediate configuration 3) the compressed js are not included at the same place in the 2 versions 4) I've added parameters in the config.xml to indicates what have to be compressed: js_base, js_plugins, js_config, js_config_reference, css_plugins_files, css_config_files To illustrate points 1 and 2, for instance I'm using configurations like that : - config_XX-01.xml (with pm_config_common = XX-common and pm_config_location = XX-01) = merged with config_XX-common.xml (with pm_config_location_common = XX-common) = merged with config_common.xml = merged with common/._startup_/.defaults.xml So the XML is the compilation of defaults + common + XX-common + XX-01 and the directories : common + XX-common + XX-01 - config_XX-02.xml : same as CC-01, but with pm_config_location = XX-02 and different parameters in the XML ... - config_YY-01.xml : So the XML is addition of defaults + common + YY-common + YY-01 and the directories : common + YY-common + YY-01 NB: config_XX-01 and config_YY-01 could use the same pm_config_location (01): - config_XX-01 = common + XX-common + 01 - config_YY-01 = common + YY-common + 01 or don't define pm_config_location at all (just change the logo, title, mapfile, ... define in the xml): - config_XX-01, 02, 03, ... = common + XX-common - config_YY-01, 02, 03, ... = common + YY-common I didn't add it in pmapper, because it will change the way to define the configs files. Thomas Le 29/07/2013 11:37, Chris forum a écrit : Hi Thomas, Just checked, even with debugLevel5/debugLevel the custom.js is still read before the plugins JS file What compression function are you using and where? On Mon, Jul 29, 2013 at 10:48 AM, Thomas RAFFIN traf...@sirap.fr mailto:traf...@sirap.fr wrote: Hi, Try to inactivate the compression (debug level = 5 I think) and tell us if the custom.js is before or after the plugins files please? AFAIK I don't use the same compression functions than in standard pmapper. So all js files are compressed in the same order than if they were included without compression. So the custom.js (and all other config/xxx/yyy.js files) is included AFTER all the plugins js files. Thomas Le 29/07/2013 09:53, Chris forum a écrit : Ok I see. Thanx for the tips, I am going to try adding a custom_plugin.js file. I will also check if the plugins I modified are available as a class. On Fri, Jul 26, 2013 at 7:04 PM, Armin Burger armin.bur...@gmail.com mailto:armin.bur...@gmail.comwrote: The problem is that the custom.js file from your config directory is loaded before the plugin JS files, so they will not have any effect The cleanest way would be to separate the custom JS files from the default JS files. Currently there is a a single check and all are referenced at the same time. Since Thomas is probably using this functionality more often I leave it to him to decide if the main code should be changed accordingly. A fast workaround would be to use something like a custom_plugin.js and reference this in the classical way (script type=text/javascript ) in the map_whatever.phtml file's head section just before the large link... / block. There is no golden way of modifying the plugin PHP code. If the plugin is written as a class you can create a new plugin that inherits from the default plugin class. Otherwise you will need to check modifications in the default plugin with you version, using whatever diff-like tool. armin On 07/26/2013 11:50 AM, Chris forum wrote: Hi all, Now that Thomas has updated several plugins, I realise I shouldn't have customized them in their own directories. I am now trying to put my changes back into custom.css and custom.js, in order to not loose them at the next general update. I am first trying to do that with the Coordinates plugin where I have done some modifications into coordinates.js.
Re: [pmapper-users] Plugins modifications
Thx a lot for the detailed info! I think I will keep it simple though and try what Armin has suggested with another custom.js dedicated for the plugins. On Mon, Jul 29, 2013 at 12:19 PM, Thomas RAFFIN traf...@sirap.fr wrote: Indeed I've modified the core code to compress files in the same order than if they were included without compression (in my version js files are not included in js_session.php). It is complicated to compare with the clean pmapper code, because 1) my version is using differently the configuration directory - common directory : /pmapper/config/common/js_config.php *.js *.css - optionally defined in the final configuration in pm_config_location_commonXXX/pm_config_location_common : /pmapper/config/XXX/js_config.php *.js *.css - optionally defined in the final configuration in pm_config_locationYYY/pm_config_location : /pmapper/config/YYY/js_config.php *.js *.css 2) I have modified the behaviour of pm_config_commonYYY/pm_config_common to include an intermediate configuration 3) the compressed js are not included at the same place in the 2 versions 4) I've added parameters in the config.xml to indicates what have to be compressed: js_base, js_plugins, js_config, js_config_reference, css_plugins_files, css_config_files To illustrate points 1 and 2, for instance I'm using configurations like that : - config_XX-01.xml (with pm_config_common = XX-common and pm_config_location = XX-01) = merged with config_XX-common.xml (with pm_config_location_common = XX-common) = merged with config_common.xml = merged with common/._startup_/.defaults.xml So the XML is the compilation of defaults + common + XX-common + XX-01 and the directories : common + XX-common + XX-01 - config_XX-02.xml : same as CC-01, but with pm_config_location = XX-02 and different parameters in the XML ... - config_YY-01.xml : So the XML is addition of defaults + common + YY-common + YY-01 and the directories : common + YY-common + YY-01 NB: config_XX-01 and config_YY-01 could use the same pm_config_location (01): - config_XX-01 = common + XX-common + 01 - config_YY-01 = common + YY-common + 01 or don't define pm_config_location at all (just change the logo, title, mapfile, ... define in the xml): - config_XX-01, 02, 03, ... = common + XX-common - config_YY-01, 02, 03, ... = common + YY-common I didn't add it in pmapper, because it will change the way to define the configs files. Thomas Le 29/07/2013 11:37, Chris forum a écrit : Hi Thomas, Just checked, even with debugLevel5/debugLevel the custom.js is still read before the plugins JS file What compression function are you using and where? On Mon, Jul 29, 2013 at 10:48 AM, Thomas RAFFIN traf...@sirap.fr mailto:traf...@sirap.fr wrote: Hi, Try to inactivate the compression (debug level = 5 I think) and tell us if the custom.js is before or after the plugins files please? AFAIK I don't use the same compression functions than in standard pmapper. So all js files are compressed in the same order than if they were included without compression. So the custom.js (and all other config/xxx/yyy.js files) is included AFTER all the plugins js files. Thomas Le 29/07/2013 09:53, Chris forum a écrit : Ok I see. Thanx for the tips, I am going to try adding a custom_plugin.js file. I will also check if the plugins I modified are available as a class. On Fri, Jul 26, 2013 at 7:04 PM, Armin Burger armin.bur...@gmail.com mailto:armin.bur...@gmail.comwrote: The problem is that the custom.js file from your config directory is loaded before the plugin JS files, so they will not have any effect The cleanest way would be to separate the custom JS files from the default JS files. Currently there is a a single check and all are referenced at the same time. Since Thomas is probably using this functionality more often I leave it to him to decide if the main code should be changed accordingly. A fast workaround would be to use something like a custom_plugin.js and reference this in the classical way (script type=text/javascript ) in the map_whatever.phtml file's head section just before the large link... / block. There is no golden way of modifying the plugin PHP code. If the plugin is written as a class you can create a new plugin that inherits from the default plugin class. Otherwise you will need to check modifications in the default plugin with you version, using whatever diff-like tool. armin On 07/26/2013 11:50 AM, Chris forum wrote: Hi all, Now that Thomas has updated several plugins, I realise I shouldn't have
