[Geoprisma-users] GeoPrisma and existing application

[Gabriel Vatin]

Thank you Alexandre. I think I will try your 2nd option, knowing that 
most of my tools have their specific JavaScript file.

Gabriel

On 16/01/2012 15:23, Alexandre Dube wrote:
> Hi Gabriel,
>
>   There is currently no easy way to accomplish that in GeoPrisma.  It 
> would be possible with some modifications to the server 'core'.  
> Here's some ideas :
>
> === Use proxy only ===
>
>   In GeoPrisma, there are 2 main parts : the proxy (server) and the 
> templating system (auto-builds the client app).  In your case, you 
> could only pick the server part.  You would only need to setup the php 
> files and config and instead of using the UI auto-generation (see an 
> index.php in any sample), you would only setup a proxy.php.
>
>   In your client application, change the hosts of your layers to point 
> to proxy.php and by adding "osmservice" and "osmresource" parameters.  
> Using firebug, look at any layer generated url to see an example of a 
> call using the proxy.
>
>   Then, the only thing remaining would be to add/remove tools 
> depending on the user rights.  You could create a small php file that 
> would read the config and acl, browse them and return a JSON 
> representing the rights of the currently logged user.  You'd need to 
> look at the core php files to see how they work.  You would then use 
> that JSON in your app to add/remove wanted/unwanted tools.
>
> === Create a new "box" widget ===
>
>   This idea would focus more in using both parts : proxy and 
> templating system.
>
>   There is currently no widget in GeoPrisma that has the purpose of 
> loading complete external files and treat them as widgets.  It could 
> be a good idea to create one that would do the following :
>
>  * manually list the resources needing it
>  * in xslt, it would check if the resource is existant in the config 
> (has the ACL rights) and execute the included code for it
>  * each resource+widget could have a unique js file to include
>  * it could also be unbound, i.e. could simply load source not related 
> to resource (like a widget adding some static feature in the app)
>
>   In my opinion, this would be a simpler idea than the first one.
>
> ======
>
>
>   Anybody else have other ideas ?
>
> Kind regards,
>
> Alexandre
>