[Mapbuilder-devel] a PHP interface to wms1.html?

[Nedjo R. <ne...@gw...>]

Some quick thoughs/suggestions

1. parsing name-value pairs from javascript

Reading a get-style variable like this doesn't necessarily require PHP (or
another scripting language) as url-encoded name-value pairs (get variables)
can be read by the javascript.  I've done this, e.g., in GeoClientX, where
an onlineresource can be passed through the url.  I've put a relevant method
in Util.js: function getArgs().  I'll put in reading of a get-encoded
onlineresource when I get a chance.  Meantime, you could have a look at
GeoClientX for usage.

2. sticking to HTML/XML

In general, I'm assuming we want to keep our main client file types free
from any server-side pre-processing (and hence free from any particular
server software, e.g., PHP or JSP).  Any server-side functionality would be
through calling secondary files/scripts on the server.  The exception would
be versions where we are doing server-side XSLT for, e.g., performance
benefits or browser backward compatibility.

3. using PHP

In which case, I'd support PHP as our primary scripting language.  Okay,
that might be partly because it's the only server-side scripting language
I'm comfortable in!  But there are other reasons to recommend it:

* It's widely available (more so than e.g. JSP, which I think tends to be
limited to more high end/costly hosting packages)
* It's the tool of choice for many of the leading open source content
management systems that we may wish to integrate with (e.g. Drupal, which
I'm developing for and would like to adapt the PHP WMS/WFS components of
GeoClient for).

In particular, I'd like to see if we could do the XSLT with PHP (rather
than, or else in addition to, the Perl that Cameron has started).  Thoughts?

4.  handling "non-originating server" issues

Beyond reading in a context document URL, the more tricky issue is how to
allow the referenced CML doc to be loaded if it's not from the "originating
server" (the server the Mapbuilder client is on).  This usually provokes
browser security restrictions.  I suggest we define (probably for now in the
Context object, like some other properties awaiting a better place!) a
"proxyScript" property.  If we could use the proxy scripts from XML for
<script> that would be ideal, since they've already covered off several
scripting languages.  But when I was working on GeoClientX I found that I
wanted to pass in some custom variables that might not be available in the
XML for <script> versions.  My several drafts of a proxy script can be found
in /mapbuilder/client/geoclientx/ as:

* translate.php: accepts url encoded name-value pairs for "onlineresource"
and "contenttype", and fetches XML file from onlineresource, passing back to
client
* query.php: this was designed with two purposes: (a) to pass a
GetFeatureInfo request and parse the results before passing back to the
browser, and (b) to fetch an ID value from the (WMS) GetFeatureInfo response
and issue a (WFS) GetFeature request for the feature with that ID (this
latter functionality only sketched in)
* postxml.php: of the three, this is the only one to handle XML as the
input.  Receives XML from client, passes it to external server, relays XML
response back to client.

I suggest we look first to XML for <script>.  If those proxy scripts don't
do what we need we could look at adapting them, possibly drawing on one or
another of the scripts I drafted.

Nedjo
----- Original Message -----
From: Cameron Shorter <ca...@sh...>
To: mapbuilder <map...@li...>
Sent: Thursday, January 29, 2004 12:44 PM
Subject: [Mapbuilder-devel] a PHP interface to wms1.html?


> I have not used PHP before, but I was wondering how hard it would be to
write
> a page which takes a URL like:
>
> http://mapbuilder.sf.net/demos/wms.php?context=http://someurl/context.xml
>
> and replaces the context variable in the javascript to point to the
context
> passed in.  Is this possible?
>
> --
> Cameron Shorter              http://cameron.shorter.net
> Open Source Developer        http://generguide.sourceforge.net
>                              http://mapbuilder.sourceforge.net
>                              http://geotools.org
> Senior Software Engineer     http://www.adi-limited.com
>
>
>
>
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> mapbuilder-devel mailing list
> map...@li...
> https://lists.sourceforge.net/lists/listinfo/mapbuilder-devel