[mapguide-internals] Session-MapName-Map

Trevor Wekel trevor.wekel at autodesk.com
Fri Aug 31 16:10:46 EDT 2007


Auto generating a UUID for the map name would be less of an API impact.
If you are willing to generate the UUID yourself, you can use the
existing API.

$uuid = uniqid("map",true);  // not really a GUID, just a unique ID
$map1 = new MgMap($siteConnection);
$map1->Create($resourceId, $uuid);
$map1->Save();

$map2 = new MgMap($siteConnection);
$map2->Open($uuid);


We may also be able to generate a unique id internally on the Save() if
a map name is not passed into the Create()

$map1 = new MgMap($siteConnection);
$map1->Create($resourceId);
$mapid = $map1->Save();  // generates a UUID internally


Much less API change this way...

Thanks,
Trevor

-----Original Message-----
From: mapguide-internals-bounces at lists.osgeo.org
[mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Paul
Spencer (External)
Sent: Friday, August 31, 2007 1:49 PM
To: MapGuide Internals Mail List
Subject: Re: [mapguide-internals] Session-MapName-Map

Good point Jason.  A quick solution to that would be to assign a UUID  
to each Map as it is created, and use that as the map 'name' when  
restoring it or requesting it through the mapagent.

Paul

On 31-Aug-07, at 3:46 PM, Jason Birch wrote:

>
> Just to confirm, you're saying that it would be impossible to have two
> runtime maps of the same map definition in the same session?
>
> I think that this would get in the way of some of my planned features,
> such as displaying multiple versions of the same map image on a  
> property
> report with different layers active and different zoom levels (nearby
> schools, nearby parks, etc...)
>
> I think that your last suggestion is something that allows users to
> override the runtime resource identifier if they want to.  Would it  
> also
> be possible for the runtime map creation routine to check if the
> resource already exists and, if it does, just add a sequential  
> number to
> it and return that value from the Create?
>
> For instance (bugs galore I'm sure)
>
> $resourceId = new
> MgResourceIdentifier("Library://Samples/Sheboygan/ 
> MyMap.MapDefinition");
>
>
> $map1 = new MgMap($siteConnection);
> $map1->Create($resourceId);
> $mgMapResourceId1 = $map1->Save();
>
> $map2 = new MgMap($siteConnection);
> $map2->Create($resourceId);
> $mgMapResourceId2 = $map2->Save();
>
> print ($mgMapResourceId1 . "\n");
> print ($mgMapResourceId2 . "\n");
>
> Output:
>
> Session:xx-yy-zz://Samples/Sheboygan/MyMap.Map
> Session:xx-yy-zz://Samples/Sheboygan/MyMap-1.Map
>
>
> Of course, I guess if you're doing this then there is no need for the
> directory structure? :)
>
> Jason
>
>
> -----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 12:27
> 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
> _______________________________________________
> 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



More information about the mapguide-internals mailing list