I have just released the Proxy module:
http://drupal.org/projects/proxy

It still needs some work, most importantly getting the caching working properly. But, now we can make a call to something like this to get external data:

/proxy?proxy=http://externaldomain.com/feed.kml

The integration should just provide the correct default proxy host for the openlayers map if one is not set. Manually, it would be something like this:

  $map['proxy_host'] = 'proxy?proxy=';

I have not really tested it out with OpenLayers yet.

Comments

tmcw’s picture

tmcw commented

Note that this is already implemented in 2.x, you might want to try a backport.

zzolo’s picture

zzolo commented

@tmcw

A little confused. By implemented, do you mean:

1) There is already a proxy in 2.x (as in there is no need for the Proxy module), or
2) There is already an option in the map array to define the proxy host?

I was definitely under the impression that 1 was not true at all. As far as 2, both branches have that option as far as I know.

Clarity about integration. I would suggest that in the map rendering process, it should check to see if ['proxy_host'] is defined, and if not, and if the Proxy module is installed, it should automatically add the correct proxy host. This will make it very easy for users, as they can just add their external URL for layers, instead of having to define a URL that is formatted for the proxy.

(note that the Proxy module still needs work before we should advertise the integration)

zzolo’s picture

zzolo commented

Ah. I think you mean that there is an option in the UI for it, maybe. Yes, this is not the case in 1.x.

So, I guess the question is, do we try to automatically fill that in if the Proxy module is installed or just let the user manually do it?

I would suggest some sort of automation, as most users are not going to be too aware about proxies, but would still love to bring in external data.

tmcw’s picture

tmcw commented

Oh, I just meant the UI for it. I'd probably say that it should be left generalized, because there are lots of cases where you'd want to use a non-drupal-based proxy, and I don't know, the proxy module can generate a URL on the admin-side that you can just copy & paste into OpenLayers?

zzolo’s picture

zzolo commented
Title: Add integration with Proxy module (1.x and 2.x) » Add integration with Proxy module (2.x)

So, I put this in the 1.x version. Basically, all it does is check if the proxy module exists and that the proxy_path is not specified, and then sets it to the Proxy module settings:

http://drupalcode.org/viewvc/drupal/contributions/modules/openlayers/ope...

I think this would be even more helpful in the 2.x version because it means that users would not have to think about including a proxy path setting in all their presets, and there are plenty of people that just want to be able to put in a KML layer with some cool data and not worry about some proxy. Let alone the fact that most users are not going to know that much about proxies (I could stand to learn a thing or two). It doesn't seem like that much work to add a bit of convenience.

tmcw’s picture

tmcw commented

Whoops, I posted my commentary to this on the wrong ticket (the one for docs). It is:

"By the way, I'm not sure if I support the integration of Proxy into 1.x that was just committed to that branch in 2.x, if it's going to be automatic, I think it's more predictable for the user for the Proxy module to form_alter the preset form so that the proxy host textfield has a big, obvious suggestion that they should set it to X."

zzolo’s picture

zzolo commented
Version: 6.x-1.x-dev » 6.x-2.x-dev

A form alter is alright, but it would require someone to have to re-save all their existing presests. I think to make maps easy, people don't want to have to think about the proxy, they just want it to work, and again there is so much more reason these days to be able to bring in outside data.

If putting in proxy integration into the openlayers module itself is a problem, then proxy could have a separate proxy_openlayers module that updates all presets in the database, while doing a form alter.

This leaves out any presets in code, but since the ProxyHost is so low level, the only way to do that is through the method in 1.x, which is still what I would prefer as it is the most seamless for the user.

tmcw’s picture

tmcw commented

Yeah, I don't feel like we have many existing users who need this functionality and are unable or unwilling to resave their presets. Having the proxyhost variable automatically overridden, and a module_exists doing it, just doesn't seem like expected behavior and doesn't seem right in the exportables-space; the proxyhost setting is exportable and should be obviously set in the interface. The Proxy module can modify presets, etc., if you feel like that behavior is sorely needed, but I think this should be handled in more-obvious fashion.

tmcw’s picture

tmcw commented

Should this ticket be moved to the Proxy module itself?

zzolo’s picture

zzolo commented
Assigned: Unassigned » zzolo

Not yet, I can take care of it. I am still thinking if I want to do the integration or not, and just haven't had any time to do much coding. Soon, though.

zzolo’s picture

zzolo commented
Status: Active » Closed (fixed)

I have the perfect idea. Instead of a form alter, the Proxy module should use an openlayers_map_alter to add the proxy_host value if it is not there. This will mean that a proxy can be added to existing maps without user thinking about it. It might be a good idea for a form_alter, just to add more detail to the proxy_path field in the UI.

New issue in Proxy queue: #735392: Add OpenLayers support