[mapguide-internals] Session-MapName-Map

[Trevor Wekel]

Yes.  This would work and would not break existing scripts.  The other
alternative I suggested below is more invasive and would break API.

You don't actually need to create the UUID until you Save() the MgMap.
That's why I put the return value on the Save() instead of the Create().
The Save() would return the name regardless of whether it was
auto-generated or not.  Either would be ok but you may not want to
generate the UUID if you are passing the MgMap to a GeneratePlot API.  

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 2:40 PM
To: MapGuide Internals Mail List
Subject: Re: [mapguide-internals] Session-MapName-Map

I would hope it wouldn't break existing code at all.  The way I see  
it, if you call Create without a second parameter, a uuid is  
automatically created (and perhaps it should be returned from Create  
instead of Save).  Having a return value where once it was void  
should be ignored in all scripting languages - the return value is  
just discarded.  This is fine for existing code that already creates  
a name and passes it in, because they don't need the return value to  
find out the name that was assigned.

Trevor, would it work to support:

$map->Create($resourceId, $name);
$name = $map->Create($resourceId);

where both cases return $name, but in the second case a uuid is  
automatically created by the server?

This would still result in the map being saved in

Session:...//name.Map

and the existing mapagent calls would work as is?

This seems like a fairly trivial change, actually.

Paul

On 31-Aug-07, at 4:27 PM, Jason Birch wrote:

>
> I like that, if the second part is implemented.  It gets away from the
> runtime map name being associated with the source map altogether.
>
> Am I right that it would still breaking the existing code (because
> you're returning a string rather than a void), but it doesn't  
> affect the
> MapAgent at all because the name is automatically set to the UUID?
>
> -----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 13:11
> To: MapGuide Internals Mail List
> Subject: RE: [mapguide-internals] Session-MapName-Map
>
>
> 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
> _______________________________________________
> 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