MapFishPrint service and proxy

[adube]

the task

Create a new service with the according proxy for the MapFish print module. The names would be : MapFishPrint (+Service and +Proxy).

no DataStore for this Service

That service would be kinda unique in a way since you don't need to specify any layer in order to work. To be more clear : in the config.yaml config file used by the MapFishPrint module, there is no such thing as a list of layers. The only things that matters are the list of allowed hosts, scales, layouts and dpis. That means that in GeoPrisma, the new MapFishPrintService won't need any DataStore nor Resources in order to work.

getDatastore using the MapFishPrint service, a new Resource object

We'll still need to validate and check the authorizations using the 'spec' parameter of the print request. Each layer defined would need find the according Resource using which Service to print the layer. In order to do so, the 'getDatastore' method of the resource object will need to be extended to receive the 'printService'. We could create a new 'MapFishPrintResource' object that would extend the ordinary resource object in order to be able to do so.

Service specifications

The 'url' parameter of a MapFishPrintService would need to point to the 'info.json' request :

  <mapfishprint>
    <name>S_MapFishPrint</name>
    <url>http://host/print/info.json</url>
    <options/>
  </mapfishprint>

That means that the info from this type of service would be automatically generated form the 'info.json' request when it is needed :

• (1) when the page initially loads in order to let the client-side know about the server configurations (dpis, layouts, scales, printURL and createURL). At this point, both the 'URL' options must be overwritten to point the the GeoPrisma proxy instead since the client must always go through the proxy first. This would be done once during the 'insertIntoXML' call of the service. The info would be put inside a 'printInfo' node of the service. If any widget needs info about the print service, it would need to look at this node.

• (2) when a print action is made. That would be done inside the MapFishPrintProxy class. There, no overwriting needs to be done.

PGSQLMapContextConfig

Since this driver only loads the services using a list of resources (coming from a mapcontext or the list inside the url of the request), the 'MapFishPrintService' wouldn't be loaded at all unless we do it manually. A simple fix to the "getService" method would do the trick : if we don't find the service in the array, create a .sql request to get it from the database. If found, add it and use it.

[adube]

I just attached a patch adding the following features :

• new "MapFishPrint" service and proxy
• major changes to the ProxyFactory. The validation is now made by the proxy object itself instead of the factory since the new print service had a very different way validate its query elements.
• the pdf file returned is not opened by the browser. An alert message pops asking the user to open or save the file.
• the name of the file is 'map.pdf'. Is that okay ?

remaining to do

• service documentation
• test and support with the new PGSQLMapContextConfig driver

[adube]

I would like to add the following points :

• ISSUE : printing tiles from a 'tilecache' service that doesn't use the 'staticCache=true' option doesn't work. This is a problem that is reproducible outside geoprisma. That happens if you try to create a OpenLayers.Layer.WMS object pointing to the tilecache service. The tile extents created from the mapfishprint module are wrong and always return errors. There's a thread mentioning that on the mapfish users mailing list :

​http://old.nabble.com/Print-and-TileCache-serving-WMS-to29739566.html

• ISSUE : in the 'GeoExtPrintForm' widget ( #148 ), I was forced to use 'GET' instead of 'POST'. When using 'POST', there was no way to use anything returned by the $_REQUEST object. The 'spec' parameter is broken all over the place !

• TEST : make more tests with different service types and also a vector layer (we could use the RedLining widget for that).

[adube]

Working prototype of the new service with its according proxy (I had forgotten to add the proxy in the last patch, sorry)

[adube]

r901, featuring :

• new MapFishPrint service and proxy

The list of "remaining things to do" still counts, and the issues mentioned above as well.

[adube]

There was already a ticket opened with that task : #5. It slipped my mind to check the existing tickets first. Could I close it as a duplicate of this one ?

[yvesm]

Yes go ahead.

Thanx.

[adube]

#5 closed as duplicate of this one.

[adube]

r1005, featuring :

• Vector layers now supported in print. They are not checked by the ACL by the MapFishPrint proxy.
• All other layers are validated by comparing the url being accessed with the url of all proxy and proxy aliases.
• Important : More about the proxy url validation :
  • Code supported by all configs
  • Used by the MapFishPrint proxy to validate if the url accessed is a proxy url or not. That means that from now on it is mandatory to define the proxy url and/or proxyAliases in common.php instead of index.php for the config to have access to it. An error is thrown if no proxy was set.
• GeoExtPrintForm : now checks if an OpenLayers.Control.DrawFeature is currently active before printing. That makes sure that the feature geometries sent to be printed are always valid.

note

• not all samples were modified to have their proxyURL set in common.php instead of index.php. Only those using the GeoExtPrintForm widget.

[adube]

Only remaining issue moved to a new ticket : #200. I'm closing this ticket.