[Chameleon] Chameleon installation woes

Tue Mar 8 17:48:22 EST 2005

Argh. My sincerest apologies for wasting everyones time. The problem I was
having with the App Dev Guide sample code was just caused a simple typo -
the include in my index.phtml should have been "template.html" not the
"templale.html" I had...

Regards,

Rhys

----- Original Message ----- 
From: "Paul Spencer" <pspencer at dmsolutions.ca>
To: "Rhys Ickeringill" <rhysi at omnilink.com.au>
Sent: Wednesday, March 09, 2005 4:39 AM
Subject: Re: [Chameleon] Chameleon installation woes

> Rhys,
>
> the App Dev Guide sample code should work, perhaps there is something
> wrong with the sample ... you can send me your files that you made from
> the App Dev Guide and I will try them.
>
> Paul
>
> Rhys Ickeringill wrote:
> > Hi Paul,
> >
> > Is it safe for me to assume that if all the demo pages are working
correctly
> > that I have Chameleon configured correctly? Or is the problem I have
with
> > the "Application Developers Guide" sample application code something I
> > should still be worring about?
> >
> > Thanks
> >
> > - Rhys
> >
> >
> > ----- Original Message ----- 
> > From: "Paul Spencer" <pspencer at dmsolutions.ca>
> > To: "Rhys Ickeringill" <rhysi at omnilink.com.au>;
> > "chameleon at lists.maptools.org" <chameleon at maptools.org>
> > Sent: Tuesday, March 08, 2005 2:25 PM
> > Subject: Re: [Chameleon] Chameleon installation woes
> >
> >
> >
> >>Rhys,
> >>
> >>Rhys Ickeringill wrote:
> >>
> >>>G'day Paul, thanks for the speedy response. My comments inline as well
> >>>
> >>>
> >>>
> >>>>Rhys, comments inline ...
> >>>>
> >>>>Rhys Ickeringill wrote:
> >>>>
> >>>>
> >>>>>Hi All,
> >>>>>
> >>>>>I'm unsucessfully trying to get Chameleon working on my linux system.
> >>>>>Presently I'm close, but not quite there. All the "Basic Widget"
sample
> >>>>>pages are working correctly bar the reference map not displaying. I
> >>>
> >>>*think*
> >>>
> >>>
> >>>>>I have traced that to the fact that I've disabled all projection
> >
> > related
> >
> >>>>>keywords in the chameleon.map file (I don't have the Canadian
> >>>
> >>>projections
> >>>
> >>>
> >>>>>which is used in this map file - what's 42304's projection type and
> >>>>>parameters?).
> >>>>
> >>>>um ... this is a bit of a problem, in the future I'm going to remove
> >>>>projections from the distributed data.  In the mean time, you can get
an
> >>>>updated epsg file from:
> >>>>
> >>>
> >>>Could you not replace the init='epsg:42304' in the distributed map
files
> >>>with the actual parameters of the projection (thereby removing the
proj4
> >>>default package dependency)?
> >>
> >>yes ... or it can be removed entirely since all the data is in the same
> >>projection.  Projections are only really needed when the data is not all
> >>in the same projection or you want a differently projected output.
> >>
> >>To support changing output projections, however, Chameleon must know the
> >>starting projection.
> >>
> >>
> >>>
> >>>>>The "Enhanced Widgets" sample "Widgets from the Enhancesd Widget
Group"
> >>>>>fails to work at all. I get the message:
> >>>>>"Fata error: [MapServer Error]: msProcessProjecrtion(): projection
not
> >>>
> >>>named
> >>>
> >>>
> >>>>>in /usr/local/chameleon/htdocs/widgets/TrueNorth/TrueNorth.widget.php
> >
> > on
> >
> >>>>>line 124
> >>>>>
> >>>>>Looking at the code in TrueNorth.widget.php, I'm guessing line 121 is
> >>>
> >>>meant
> >>>
> >>>
> >>>>>to catch this error, but isn't.
> >>>>
> >>>>this could be a bug.  Try the epsg file first and if this persists,
> >>>>please report again :)
> >>>>
> >>>
> >>>Acquiring the extended epsg file has solved this. Probably something
> >
> > along
> >
> >>>the chain Chameleon > PHP_MapScript > MapServer > Proj4 should handle
> >
> > this
> >
> >>>[essentially invalid input] more gracefully. I'll send the appropriate
> >
> > party
> >
> >>>a diff when (if?) I get my head around PHP and MapScript.
> >>
> >>Please file a bug for this.
> >>
> >>
> >>>
> >>>>>The "Bilingualisation" and "XML Theme Legend" samples work as they
> >>>
> >>>should,
> >>>
> >>>
> >>>>>bar the reference map problem outlined above.
> >>>>>
> >>>>>But most puzzling of all, I've followed the instructions in the
> >>>
> >>>Chameleon
> >>>
> >>>
> >>>>>online help "Installation Guide" and set up the sample page from the
> >>>>>"Application Developers Guide"  to test everything is working
properly
> >>>>>(actually this is the first thing I did, I tried the sample pages
> >>>>>afterwards, but I digress). Sadly all I get is an empty document -
> >>>>>specifically a pair of HTML and BODY tags. The only changes I've made
> >
> > to
> >
> >>>the
> >>>
> >>>
> >>>>>samples provided are to update the include path for chameleon.php and
> >>>>>commenting out the projection related keywords from the map file.
> >>>>
> >>>>depending on how you have configured PHP, your error messages may be
> >>>>going into the apache error log.  We need an error message somewhere
to
> >>>>figure this out.
> >>>>
> >>>
> >>>The reference map issues on the sample pages have been solved by the
> >
> > updated
> >
> >>>epsg file as expected. Is it a requirement that a projection must be
> >
> > defined
> >
> >>>for the reference map to work? To be honest I was quite surprised that
> >
> > any
> >
> >>>map images were generated after I commented out every reference I could
> >
> > find
> >
> >>>to projections in the map file...
> >>>
> >>>Unfortunately I'm still just getting an empty page by the code
> >
> > essentially
> >
> >>>cut-n-paste from the Application Developers Guide. My apologies, I
> >
> > forgot to
> >
> >>>mention that there's nothing in the apache logs other than that the
page
> >
> > was
> >
> >>>accessed (no corresponding message in the error log). PHP is configured
> >
> > to
> >
> >>>display error messages inline in the generated page, hence why I am
> >
> > stumped
> >
> >>>by the completely emtpy document. My main concern in all of this is to
> >>>ensure Chameleon / MapScript / MapServer is functioning as it should
> >
> > before
> >
> >>>I start development - this way I'll know I've only got myself to blame
> >
> > if
> >
> >>>things aren't working ;-) . Should I be concerned that this page is not
> >>>functioning? Or is having the other sample pages fully functioning good
> >>>enough to prove everything is as it should be?
> >>
> >>um.  The reference object in mapscript doesn't support a projection so
> >>we have a method of doing this in php.  I'm guessing that it assumes
> >>that there will always be a valid projection defined.
> >>
> >>
> >>>
> >>>>>On an asside, I've noticed in my peeking around in the Chameleon code
> >>>
> >>>that
> >>>
> >>>
> >>>>>many of the modules are incorrectly named (or my system is strange).
> >
> > eg.
> >
> >>>>>there is code to test whether the "gd" PHP module is loaded, and if
it
> >>>>>isn't, Chameleon attempts to load module "php_gd.so". On my system at
> >>>
> >>>least,
> >>>
> >>>
> >>>>>this module is called just "gd.so"...
> >>>>
> >>>>sadly this is true.  On windows, all extensions are built as modules
and
> >>>>named 'php_xxxx.dll'.  On linux, extensions are normally built into
php.
> >>>> I have recently discovered that on linux, if you build extensions as
> >>>>modules, the names will be without the leading 'php_'
> >>>>
> >>>>I had hoped to keep the code to ensure modules are loaded fairly
tight,
> >>>>hence:
> >>>>
> >>>>if (!extension_loaded('gd'))
> >>>>  dl( 'php_gd.'.PHP_SHLIB_SUFFIX);
> >>>>
> >>>>now I will have to look into trying both the php_gd.so and gd.so
> >
> > versions
> >
> >>>:(
> >>>
> >>>
> >>>Why not
> >>>
> >>>if( !extension_loaded('gd'))
> >>>   dl( PHP_SHLIB_PREFIX.'gd'.PHP_SHLIB_SUFFIX );
> >>>
> >>>I agree, its' not a clean as before, but once you've gone and done the
> >>>suffix, you might as well go all the way, no? I guess the other option
> >
> > is to
> >
> >>>publish a list of PHP extensions which must be either compiled in or
> >
> > loaded
> >
> >>>via php.ini "extension=<module_name>.<module_suffix>" in the install
> >>>instructions and not concern yourself at all with extension loading.
The
> >>>latter is how I've worked around the problem...
> >>
> >>we could use something like this I guess ...
> >>// some constanst for pre php4.3
> >>if (!defined('PHP_SHLIB_SUFFIX'))
> >>{
> >>     define('PHP_SHLIB_SUFFIX',strtoupper(substr(PHP_OS, 0,3)) == 'WIN'
> >>? 'dll' : 'so');
> >>}
> >>if (!defined('PHP_SHLIB_PREFIX'))
> >>{
> >>     define('PHP_SHLIB_PREFIX',PHP_SHLIB_SUFFIX == 'dll' ? 'php_' : '');
> >>}
> >>
> >>but mapscript is built as php_mapscript.so (for example) so the rule is
> >>not universal (or mapscript doesn't adhere to the convention, is more
> >>likely).
> >>
> >>I agree with publishing a list, although one of our goals is to make the
> >>software independent (as much as possible) of client configuration of
> >>PHP.  There are certain required values that we just cannot work around,
> >>but most of the rest we can.  In this case, I think we'll probably
> >>implement a helper function to load modules.
> >>
> >>
> >>>Thanks for you support.
> >>>
> >>>Rhys
> >>>
> >>>
> >>
> >>Cheers
> >>
> >>Paul
> >>
> >>-- 
> >>+-----------------------------------------------------------------+
> >>|Paul Spencer                           pspencer at dmsolutions.ca   |
> >>+-----------------------------------------------------------------+
> >>|Applications & Software Development                              |
> >>|DM Solutions Group Inc                 http://www.dmsolutions.ca/|
> >>+-----------------------------------------------------------------+
> >>
> >>
> >
> >
> >
>
> -- 
> +-----------------------------------------------------------------+
> |Paul Spencer                           pspencer at dmsolutions.ca   |
> +-----------------------------------------------------------------+
> |Applications & Software Development                              |
> |DM Solutions Group Inc                 http://www.dmsolutions.ca/|
> +-----------------------------------------------------------------+
>
>