[mapguide-internals] Session-MapName-Map
Haris Kurtagic
haris at sl-king.com
Fri Aug 31 15:43:30 EDT 2007
Perhaps little too philosophical in this moment but that approach could
have a hole in some scenarios. One of them would be when you would have
three MG sites and application opens one MAP from first server and
second MAP from second server (MapDefinition have same library id) and
saves them in session repository of a third MG site ( I believe you can
not do that right now ? ).
Haris
-----Original Message-----
From: mapguide-internals-bounces at lists.osgeo.org
[mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Trevor
Wekel
Sent: Friday, August 31, 2007 9:27 PM
To: MapGuide Internals Mail List
Subject: RE: [mapguide-internals] Session-MapName-Map
I just checked with Steve. We do support folders in the session
repository. There is no "id" in MapGuide currently so it will be a pain
to introduce one. However, we could remap the entire Library based
resource identifier into a session resource identifier.
"Library://Samples/Sheboygan/MyMap.MapDefinition"
would become
"Session:xx-yy-zz://Samples/Sheboygan/MyMap.Map"
And we could add an MgResourceIdentifier return value to MgMap.Save
although it may break existing apps. Using "non-deprecated" API we
would then have:
$resourceId = new MgResourceIdentifier($mapid);
$map = new MgMap($siteConnection);
$map->Create($resourceId);
$mgMapResourceId = $map->Save();
and then to recover the runtime map:
$map = new MgMap($siteConnection);
$map->Open($mgMapResourceId);
It is easy to construct the $mgMapResourceId from the $resourceId by
calling MgResourceIdentifier.SetRepositoryType(MgRepositoryType.Session)
and SetRepositoryName($session)
This does reduce some of the API flexibility because it enforces a one
to one correspondence between a map definition and a runtime map. but
it is less "wordy". I have not looked at all the API impacts but this
would require an RFC. We could add a second
MgMap.Create($mapDefinitionResourceId, $mgMapResourceId) to make it a
little more flexible.
Thanks,
Trevor
-----Original Message-----
From: mapguide-internals-bounces at lists.osgeo.org
[mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Haris
Kurtagic
Sent: Friday, August 31, 2007 12:58 PM
To: MapGuide Internals Mail List
Subject: RE: [mapguide-internals] Session-MapName-Map
Yes, that is a way I was thinking about.
Thanks,
Haris
-----Original Message-----
From: mapguide-internals-bounces at lists.osgeo.org
[mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Paul
Spencer
Sent: Friday, August 31, 2007 8:50 PM
To: MapGuide Internals Mail List
Subject: Re: [mapguide-internals] Session-MapName-Map
So the logic (in PHP anyway) could be:
$resourceID = new MgResourceIdentifier($mapid);
$map = new MgMap();
$map->Create($resourceService, $resourceID);
$mapStateId = $map->Save($resourceService);
and then to recover the runtime map:
$map = new MgMap();
$map->Open($resourceService, $mapStateId);
Where mapStateId is returned from Save (or obtained in some other
way) and is automagically created from the resourceId in such a way
as to guarantee uniqueness for maps with the same name in different
folders.
I like this. One thing that I find about the MapGuide APIs is that
using them is often quite verbose. Over time, I would like to see
common patterns that require a lot of code be moved into API
convenience functions so that it is easier for folks to accomplish
basic programming tasks.
Paul
On 31-Aug-07, at 2:40 PM, Haris Kurtagic wrote:
> I am thinking that instead client application figure out what to
> use for
> MapName, unique name would be returned from server after saving Map
> into
> session repository.
> Benefits would be that we wouldn't need to implement unique
> algorithm in
> every client application/viewer.
>
> Haris
>
> -----Original Message-----
> From: mapguide-internals-bounces at lists.osgeo.org
> [mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Paul
> Spencer
> Sent: Friday, August 31, 2007 8:35 PM
> To: MapGuide Internals Mail List
> Subject: Re: [mapguide-internals] Session-MapName-Map
>
> I'm confused about what supporting this in the server would mean.
> Would this impact the scripting APIs at all? What would it make
> easier?
>
> Paul
>
> On 31-Aug-07, at 2:27 PM, Trevor Wekel wrote:
>
>> Hi Haris,
>>
>> The resource identifier is the Berkeley DBXML "key" for both the
>> Library:// and Session:// repositories.
>>
>> Thanks,
>> Trevor
>>
>> -----Original Message-----
>> From: mapguide-internals-bounces at lists.osgeo.org
>> [mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of
>> Haris
>> Kurtagic
>> Sent: Friday, August 31, 2007 12:21 PM
>> To: MapGuide Internals Mail List
>> Subject: RE: [mapguide-internals] Session-MapName-Map
>>
>> Hi Trevor,
>>
>> Yes leading path from Library is stripped (changed with Session ) and
>> Name part is given by application like MapGudie Viewer for example.
>> As you suggested application can use full name ( with folders ) or as
>> Paul suggested hash the name or ..
>> I have a feeling that server should return the key from db. In
>> Map.cpp
>> MapName is input parameter for creating entry in db.
>>
>> Haris
>>
>> -----Original Message-----
>> From: mapguide-internals-bounces at lists.osgeo.org
>> [mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of
>> Trevor
>> Wekel
>> Sent: Friday, August 31, 2007 8:08 PM
>> To: MapGuide Internals Mail List
>> Subject: RE: [mapguide-internals] Session-MapName-Map
>>
>> Hi Haris,
>>
>> If you have the map definition
>> Library://Samples/Sheboygan/Test.MapDefinition then the MgMap
>> resourceid
>> be default will be Session:xx-yy-zz//Test.MgMap. The leading path is
>> stripped.
>>
>> I don't know if we have folder support in the session repository
>> but it
>> would probably be better to construct the MgMap session using the
>> full
>> path. Something like this might work:
>>
>> Session:xx-yy-zz//Samples_Sheboygan_Test.MgMap
>>
>>
>> This would be an appropriate enhancement/bugfix request. A search
>> for
>> MgResourceType::Map should take you to most of the code that would
>> require change - DwfController.cpp and Map.cpp I believe.
>>
>>
>>
>> Thanks,
>> Trevor
>>
>>
>> -----Original Message-----
>> From: mapguide-internals-bounces at lists.osgeo.org
>> [mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of
>> Haris
>> Kurtagic
>> Sent: Friday, August 31, 2007 11:40 AM
>> To: MapGuide Internals Mail List
>> Subject: RE: [mapguide-internals] Session-MapName-Map
>>
>> Thank you, you are right on the track.
>>
>> Yes, you could change name as you suggested or use different sesion
>> for
>> every map or ...
>> I would prefer to have a in server solution for this (and to be
>> able to
>> work with multiple maps in one session).
>> Perhaps server could return DataKey from DB after creating new Map in
>> it?
>>
>> Haris
>>
>> -----Original Message-----
>> From: mapguide-internals-bounces at lists.osgeo.org
>> [mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Paul
>> Spencer
>> Sent: Friday, August 31, 2007 7:23 PM
>> To: MapGuide Internals Mail List
>> Subject: Re: [mapguide-internals] Session-MapName-Map
>>
>> Haris,
>>
>> I'm not sure if I really know what I am talking about here, but my
>> understanding is that when you start up a session with a
>> MapDefinition, you can save the runtime MgMap object to the session
>> repository as a Map resource and give it a name at that time. The
>> name is arbitrary, but in the case of the AJAX viewer it is
>> predictable from the MapDefinition name and I think you are right
>> that it would either blow away the existing Map or conflict in some
>> way.
>>
>> I'm not sure how the existing viewer works, but it doesn't contain
>> the capability to change maps at run time so it would never run into
>> this issue. In Fusion, we can load different MapDefinitions at run
>> time and we do something like this when the user wants to load the
>> map:
>> /* $mapid is a string resource id Library://... */
>> $resourceID = new MgResourceIdentifier($mapid);
>> $map = new MgMap();
>> $mapName = $resourceID->GetName();
>> $map->Create($resourceService, $resourceID, $mapName);
>> $mapStateId = new MgResourceIdentifier("Session:" . $sessionID .
>> "//" . $map->GetName() . "." . MgResourceType::Map);
>> $map->Save($resourceService, $mapStateId);
>>
>> (NB: there is a potential problem here if the map name is the same as
>> one already in the session. I will need to fix this potential bug in
>> Fusion - I will probably use an md5 hash of the string version of the
>> full Library:// path to the original map. This would probably look
>> like:
>>
>> $mapName = md5($mapid);
>>
>> and the rest of the code would look the same.
>> )
>>
>> We return the $mapName to the client so that subsequent requests can
>> operate on the the appropriate Map object on the server side using
>> something like this:
>>
>> $map = new MgMap();
>> $map->Open($resourceService, $mapName);
>>
>> The mapagent rendering operations take the session id and the map
>> name to render map images and dynamic map overlays.
>>
>> Does that help?
>>
>> Cheers
>>
>> Paul
>>
>> On 31-Aug-07, at 1:05 PM, Haris Kurtagic wrote:
>>
>>> I would appreciate if someone could help me to clarify
>>> Session-MapName-Map interaction.
>>>
>>>
>>>
>>> Now how MG Viewer-Server is working is that it will create new
>>> session
>>> and read web layout and create a runtime map in session repository.
>>>
>>> Later runtime map is accessed by name (only name part of it) from
>>> the
>>> session repository.
>>>
>>> So, if I would have two Maps created in Library in separate folders
>>> with
>>> same name and if I would add the second map to session repository I
>>> could not access both Maps ( because Session Id and MapName are
>>> used to
>>> identify it - and they are same).
>>>
>>>
>>>
>>> Am I right about this ?
>>>
>>>
>>>
>>> Thanks,
>>>
>>> Haris
>>>
>>> _______________________________________________
>>> mapguide-internals mailing list
>>> mapguide-internals at lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>>
>> +-----------------------------------------------------------------+
>> |Paul Spencer pspencer at dmsolutions.ca |
>> +-----------------------------------------------------------------+
>> |Chief Technology Officer |
>> |DM Solutions Group Inc http://www.dmsolutions.ca/ |
>> +-----------------------------------------------------------------+
>>
>>
>>
>>
>>
>> _______________________________________________
>> mapguide-internals mailing list
>> mapguide-internals at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>> _______________________________________________
>> mapguide-internals mailing list
>> mapguide-internals at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>>
>> _______________________________________________
>> mapguide-internals mailing list
>> mapguide-internals at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>> _______________________________________________
>> mapguide-internals mailing list
>> mapguide-internals at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>>
>> _______________________________________________
>> mapguide-internals mailing list
>> mapguide-internals at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>
> +-----------------------------------------------------------------+
> |Paul Spencer pspencer at dmsolutions.ca |
> +-----------------------------------------------------------------+
> |Chief Technology Officer |
> |DM Solutions Group Inc http://www.dmsolutions.ca/ |
> +-----------------------------------------------------------------+
>
>
>
>
>
> _______________________________________________
> mapguide-internals mailing list
> mapguide-internals at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
> _______________________________________________
> mapguide-internals mailing list
> mapguide-internals at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
+-----------------------------------------------------------------+
|Paul Spencer pspencer at dmsolutions.ca |
+-----------------------------------------------------------------+
|Chief Technology Officer |
|DM Solutions Group Inc http://www.dmsolutions.ca/ |
+-----------------------------------------------------------------+
_______________________________________________
mapguide-internals mailing list
mapguide-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapguide-internals
_______________________________________________
mapguide-internals mailing list
mapguide-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapguide-internals
_______________________________________________
mapguide-internals mailing list
mapguide-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapguide-internals
More information about the mapguide-internals
mailing list