Hi All,
Trying to figure out how to set the zindex on my markers with googlev3. This
doesn''t seem to work, not sure why. The southernmost markers are
always on top.
function addMarker(...., zindex) {
...
var data = {
...
zIndexProcess: function(marker, b) { return zindex; },
zIndex: zindex
};
...
mps.addMarkerWithData(new mxn.Marker(point), data);
}
-Mike
Hi Mike, Le mar. 16 ao?t 2011 00:18:55 CEST, Mike Miller a ?crit :> Hi All, > > Trying to figure out how to set the zindex on my markers with googlev3. > This doesn''t seem to work, not sure why. The southernmost markers are > always on top.I''m not sure this is possible. I don''t see any occurence of zIndex property in the code of mapstraction. https://github.com/mapstraction/mxn/blob/master/source/mxn.core.js#L1515 The documentation only talk about these attributes for addData on a marker : Keys are: label, infoBubble, icon, iconShadow, infoDiv, draggable, hover, hoverIcon, openBubble, groupName. http://mapstraction.github.com/mxn/build/2.0.17/docs/symbols/mxn.Marker.html#addData All other keys passed to addData are added to the marker as attribute, so your markers should have a zIndex attributes (but this wiil do nothing by defalut). ++ b_b
Hi, thanks for the reply. I lost it for a few days, my apologies... So, it looks like I can patch in my own "this.setzIndex(...)" into the code below and it should work? Gonna give it a try, if it works I imagine others would appreciate it. -Mike> ------------------------------ > From: Bruno Bergot<brunobergot at gmail.com> > Subject: Re: [Mapstraction] Setting marker zindex > Message-ID:<4E4A7175.60202 at gmail.com> > > Hi Mike, > I''m not sure this is possible. I don''t see any occurence of zIndex > property in the code of mapstraction. > > https://github.com/mapstraction/mxn/blob/master/source/mxn.core.js#L1515>> All other keys passed to addData are added to the marker as attribute, > so your markers should have a zIndex attributes (but this wiil do > nothing by defalut).
Ok, I found a way to do it after several hours of hacking.
Unfortunately adding the code to handle the attribute didn''t work as it
didn''t
get set in the actual (proprietary) marker. It wasn''t getting copied
or
transferred and would also be clobbered if I set it beforehand.
Eventually I gave up and tried setting it directly and it worked:
function addMarker(...., zindex) {
...
var mkr = new mxn.Marker(point);
mps.addMarkerWithData(mkr, data);
mkr.proprietary_marker.zIndex = zindex; // must be done afterwards
}
While mapstraction is a great idea and I like that the code is more concise it
suffers from a lack of docs and missing trivial features such as this. I know
those things are hard, but as I''ve had to hack the internals on more
than one
occasion I''ve now broken the abstraction part of it. I''m
starting to regret
choosing it as my code is now dependent but isn''t really abstracted.
Also, I''ve
now spent more time than I''ve saved, and when I have a problem it feels
like I''m
on my own, despite the helpful tips from Bruno which I appreciate.
-Mike
Throwing this out for general discussion, can a "trivial feature" be successfully implemented across all the APIs? If it can, then it should be and I''ll be looking at my Ovi Maps code to see if it can be done once I return from summer vacation. But a cautionary note ... each API has unique features, a USP if you will. Mapstraction''s strength is the ability to abstract across all of the APIs with a common interface and feature set. I''d hate to see this strength diluted if we choose the path where we base and judge on a single API vendors feature set. Then Mapstraction becomes just another rewrite of a wrapper around a single API, which supports other APIs to a lesser degree. Personally, I don''t want to see that happen. On the other hand, yes, the documentation needs some love. That''s the case with a lot of open source projects, though it doesn''t excuse it, but technical authoring is a rare skill set. G Mike Miller <mapstraction at mgmiller.net> wrote:>Ok, I found a way to do it after several hours of hacking. > >Unfortunately adding the code to handle the attribute didn''t work as it didn''t >get set in the actual (proprietary) marker. It wasn''t getting copied or >transferred and would also be clobbered if I set it beforehand. > >Eventually I gave up and tried setting it directly and it worked: > >function addMarker(...., zindex) { > ... > var mkr = new mxn.Marker(point); > mps.addMarkerWithData(mkr, data); > mkr.proprietary_marker.zIndex = zindex; // must be done afterwards >} > >While mapstraction is a great idea and I like that the code is more concise it >suffers from a lack of docs and missing trivial features such as this. I know >those things are hard, but as I''ve had to hack the internals on more than one >occasion I''ve now broken the abstraction part of it. I''m starting to regret >choosing it as my code is now dependent but isn''t really abstracted. Also, I''ve >now spent more time than I''ve saved, and when I have a problem it feels like I''m >on my own, despite the helpful tips from Bruno which I appreciate. > >-Mike > >_______________________________________________ >Mapstraction mailing list >Mapstraction at lists.mapstraction.com >http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com
2011/8/22 Gary Gale <gary at vicchi.org>:> Throwing this out for general discussion, can a "trivial feature" be successfully implemented across all the APIs? > > If it can, then it should be and I''ll be looking at my Ovi Maps code to see if it can be done once I return from summer vacation. > > But a cautionary note ... each API has unique features, a USP if you will. Mapstraction''s strength is the ability to abstract across all of the APIs with a common interface and feature set. I''d hate to see this strength diluted if we choose the path where we base and judge on a single API vendors feature set. Then Mapstraction becomes just another rewrite of a wrapper around a single API, which supports other APIs to a lesser degree. Personally, I don''t want to see that happen. >+1 less is more. keep the core library clean and simple.> On the other hand, yes, the documentation needs some love. That''s the case with a lot of open source projects, though it doesn''t excuse it, but technical authoring is a rare skill set. > > G > > Mike Miller <mapstraction at mgmiller.net> wrote: > >>Ok, I found a way to do it after several hours of hacking. >> >>Unfortunately adding the code to handle the attribute didn''t work as it didn''t >>get set in the actual (proprietary) marker. ?It wasn''t getting copied or >>transferred and would also be clobbered if I set it beforehand. >> >>Eventually I gave up and tried setting it directly and it worked: >> >>function addMarker(...., zindex) { >> ? ? ?... >> ? ? ?var mkr = new mxn.Marker(point); >> ? ? ?mps.addMarkerWithData(mkr, data); >> ? ? ?mkr.proprietary_marker.zIndex = zindex; ?// must be done afterwards >>} >> >>While mapstraction is a great idea and I like that the code is more concise it >>suffers from a lack of docs and missing trivial features such as this. ?I know >>those things are hard, but as I''ve had to hack the internals on more than one >>occasion I''ve now broken the abstraction part of it. ?I''m starting to regret >>choosing it as my code is now dependent but isn''t really abstracted. ?Also, I''ve >>now spent more time than I''ve saved, and when I have a problem it feels like I''m >>on my own, despite the helpful tips from Bruno which I appreciate. >> >>-Mike >> >>_______________________________________________ >>Mapstraction mailing list >>Mapstraction at lists.mapstraction.com >>http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com > _______________________________________________ > Mapstraction mailing list > Mapstraction at lists.mapstraction.com > http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com >
I''m also in favor of keeping the library to a minimum, but I want to be
able
to add features for an API sometimes. I came up with the idea of including
an ''extras'' script for the API when I want to do this. As an
example, here
is my extra code to add a marker ''dragend'' event for the
Google V3 API:
mxn.addProxyMethods( mxn.Mapstraction, [ ''enableMyExtras'' ]);
mxn.register( ''googlev3'', {
Mapstraction: {
enableMyExtras: function() {
var me = this;
me.markerAdded.addHandler( function( name, source, args ) {
if ( args.marker.draggable ) {
// add marker dragend event
args.marker.dragend = new mxn.Event( ''dragend'', args.marker );
google.maps.event.addListener( args.marker.proprietary_marker,
''dragend'',
function( mouse ) {
args.marker.dragend.fire( { location: new mxn.LatLonPoint(
mouse.latLng.lat(), mouse.latLng.lng() ) } );
});
}
});
}
}
});
Then, when I create an instance of Mapstraction I do this:
var map = new mxn.Mapstraction( container, ''googlev3'' );
if ( map.enableMyExtras ) {
map.enableMyExtras();
}
That works, but relies on the ''markerAdded'' event in the core
library. This
pattern should work for setting the marker zIndex also. I think if
we''re a
little more liberal with events in the core library, more extensions like
this would be possible. Firing an event when a proprietary object is created
might be a good start.
Anyone else like that idea?
cheers,
-dylan-
On Tue, Aug 23, 2011 at 1:18 AM, Ed Freyfogle <edf at sloan.mit.edu>
wrote:
>
> +1
> less is more. keep the core library clean and simple.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.mapstraction.com/pipermail/mapstraction-mapstraction.com/attachments/20110823/4002c5a9/attachment.htm>
Total and utter +1 from me on that. Not to be cute or anything but this extras or extensions mechanism could be abstracted and formalised across all supported APIs methinks while still being true to the less is more ethos Ed alluded to earlier in the thread. G Sent from one of my mobile gadgets ... On 23 Aug 2011, at 15:37, Dylan Kuhn <dylan.k.kuhn at gmail.com> wrote:> I''m also in favor of keeping the library to a minimum, but I want to be able to add features for an API sometimes. I came up with the idea of including an ''extras'' script for the API when I want to do this. As an example, here is my extra code to add a marker ''dragend'' event for the Google V3 API: > > mxn.addProxyMethods( mxn.Mapstraction, [ ''enableMyExtras'' ]); > > mxn.register( ''googlev3'', { > Mapstraction: { > enableMyExtras: function() { > var me = this; > me.markerAdded.addHandler( function( name, source, args ) { > if ( args.marker.draggable ) { > // add marker dragend event > args.marker.dragend = new mxn.Event( ''dragend'', args.marker ); > google.maps.event.addListener( args.marker.proprietary_marker, ''dragend'', function( mouse ) { > args.marker.dragend.fire( { location: new mxn.LatLonPoint( mouse.latLng.lat(), mouse.latLng.lng() ) } ); > }); > } > }); > } > } > }); > > Then, when I create an instance of Mapstraction I do this: > > var map = new mxn.Mapstraction( container, ''googlev3'' ); > if ( map.enableMyExtras ) { > map.enableMyExtras(); > } > > That works, but relies on the ''markerAdded'' event in the core library. This pattern should work for setting the marker zIndex also. I think if we''re a little more liberal with events in the core library, more extensions like this would be possible. Firing an event when a proprietary object is created might be a good start. > > Anyone else like that idea? > > cheers, > -dylan- > > On Tue, Aug 23, 2011 at 1:18 AM, Ed Freyfogle <edf at sloan.mit.edu> wrote: > > +1 > less is more. keep the core library clean and simple. > > _______________________________________________ > Mapstraction mailing list > Mapstraction at lists.mapstraction.com > http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mapstraction.com/pipermail/mapstraction-mapstraction.com/attachments/20110823/25fc987b/attachment.htm>
Following up on this ... a non scientific and incomplete review of the underlying JS Maps API that MXN supports shows that a zIndex for Markers is by no means supported across all platforms ... Google v3 - yes - http://code.google.com/apis/maps/documentation/javascript/reference.html#Marker Nokia - yes - http://api.maps.ovi.com/apireference/symbols/ovi.mapsapi.map.StandardMarker.html Bing - yes - http://msdn.microsoft.com/en-us/library/gg427629.aspx CloudMade - no - http://developers.cloudmade.com/wiki/web-maps-api/CMMarker Yahoo! - no - http://developer.yahoo.com/maps/ajax/V3.8/index.html#YMarker (and a moot point as the Y! Maps API goes bye-bye on 13/9/11) ... given the lack of support for zIndex across this sample I don''t see that we can make zIndex for Markers part of the main MXN API ... with this in mind, is someone up for trying to formalise the "extras" approach that Dylan outlined below? Maybe even Dylan? :-) G On Aug 23, 2011, at 3:42 PM, Gary Gale wrote:> Total and utter +1 from me on that. > > Not to be cute or anything but this extras or extensions mechanism could be abstracted and formalised across all supported APIs methinks while still being true to the less is more ethos Ed alluded to earlier in the thread. > > G > > Sent from one of my mobile gadgets ... > > On 23 Aug 2011, at 15:37, Dylan Kuhn <dylan.k.kuhn at gmail.com> wrote: > >> I''m also in favor of keeping the library to a minimum, but I want to be able to add features for an API sometimes. I came up with the idea of including an ''extras'' script for the API when I want to do this. As an example, here is my extra code to add a marker ''dragend'' event for the Google V3 API: >> >> mxn.addProxyMethods( mxn.Mapstraction, [ ''enableMyExtras'' ]); >> >> mxn.register( ''googlev3'', { >> Mapstraction: { >> enableMyExtras: function() { >> var me = this; >> me.markerAdded.addHandler( function( name, source, args ) { >> if ( args.marker.draggable ) { >> // add marker dragend event >> args.marker.dragend = new mxn.Event( ''dragend'', args.marker ); >> google.maps.event.addListener( args.marker.proprietary_marker, ''dragend'', function( mouse ) { >> args.marker.dragend.fire( { location: new mxn.LatLonPoint( mouse.latLng.lat(), mouse.latLng.lng() ) } ); >> }); >> } >> }); >> } >> } >> }); >> >> Then, when I create an instance of Mapstraction I do this: >> >> var map = new mxn.Mapstraction( container, ''googlev3'' ); >> if ( map.enableMyExtras ) { >> map.enableMyExtras(); >> } >> >> That works, but relies on the ''markerAdded'' event in the core library. This pattern should work for setting the marker zIndex also. I think if we''re a little more liberal with events in the core library, more extensions like this would be possible. Firing an event when a proprietary object is created might be a good start. >> >> Anyone else like that idea? >> >> cheers, >> -dylan- >> >> On Tue, Aug 23, 2011 at 1:18 AM, Ed Freyfogle <edf at sloan.mit.edu> wrote: >> >> +1 >> less is more. keep the core library clean and simple. >> >> _______________________________________________ >> Mapstraction mailing list >> Mapstraction at lists.mapstraction.com >> http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com > _______________________________________________ > Mapstraction mailing list > Mapstraction at lists.mapstraction.com > http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com-- gary at vicchi.org | twitter.com/vicchi | www.linkedin.com/in/garygale | www.garygale.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mapstraction.com/pipermail/mapstraction-mapstraction.com/attachments/20110830/37d0d6fd/attachment.htm>
Good research. If a capability is present in all the providers, I think that would be a good argument for adding it to the MXN core. My "extras" pattern can be used in other cases. I''m not sure it''s appropriate to include any specific "extras" in MXN, but I would like to do two things: 1. Add an example use of the pattern to the sandbox. 2. Increase the utility of the pattern by adding some more events along the lines of ''markerAdded'' to the MXN core. I''m game to do both of these as my time permits. -dylan- On Tue, Aug 30, 2011 at 8:20 AM, Gary Gale <gary at vicchi.org> wrote:> Following up on this ... a non scientific and incomplete review of the > underlying JS Maps API that MXN supports shows that a zIndex for Markers is > by no means supported across all platforms ... > > Google v3 - yes - > http://code.google.com/apis/maps/documentation/javascript/reference.html#Marker > Nokia - yes - > http://api.maps.ovi.com/apireference/symbols/ovi.mapsapi.map.StandardMarker.html > Bing - yes - http://msdn.microsoft.com/en-us/library/gg427629.aspx > CloudMade - no - > http://developers.cloudmade.com/wiki/web-maps-api/CMMarker > Yahoo! - no - http://developer.yahoo.com/maps/ajax/V3.8/index.html#YMarker(and a moot point as the Y! Maps API goes bye-bye on 13/9/11) > > ... given the lack of support for zIndex across this sample I don''t see > that we can make zIndex for Markers part of the main MXN API ... with this > in mind, is someone up for trying to formalise the "extras" approach that > Dylan outlined below? Maybe even Dylan? :-) > > G > > On Aug 23, 2011, at 3:42 PM, Gary Gale wrote: > > Total and utter +1 from me on that. > > Not to be cute or anything but this extras or extensions mechanism could be > abstracted and formalised across all supported APIs methinks while still > being true to the less is more ethos Ed alluded to earlier in the thread. > > G > > Sent from one of my mobile gadgets ... > > On 23 Aug 2011, at 15:37, Dylan Kuhn <dylan.k.kuhn at gmail.com> wrote: > > I''m also in favor of keeping the library to a minimum, but I want to be > able to add features for an API sometimes. I came up with the idea of > including an ''extras'' script for the API when I want to do this. As an > example, here is my extra code to add a marker ''dragend'' event for the > Google V3 API: > > mxn.addProxyMethods( mxn.Mapstraction, [ ''enableMyExtras'' ]); > > mxn.register( ''googlev3'', { > Mapstraction: { > enableMyExtras: function() { > var me = this; > me.markerAdded.addHandler( function( name, source, args ) { > if ( args.marker.draggable ) { > // add marker dragend event > args.marker.dragend = new mxn.Event( ''dragend'', args.marker ); > google.maps.event.addListener( args.marker.proprietary_marker, ''dragend'', > function( mouse ) { > args.marker.dragend.fire( { location: new mxn.LatLonPoint( > mouse.latLng.lat(), mouse.latLng.lng() ) } ); > }); > } > }); > } > } > }); > > Then, when I create an instance of Mapstraction I do this: > > var map = new mxn.Mapstraction( container, ''googlev3'' ); > if ( map.enableMyExtras ) { > map.enableMyExtras(); > } > > That works, but relies on the ''markerAdded'' event in the core library. This > pattern should work for setting the marker zIndex also. I think if we''re a > little more liberal with events in the core library, more extensions like > this would be possible. Firing an event when a proprietary object is created > might be a good start. > > Anyone else like that idea? > > cheers, > -dylan- > > On Tue, Aug 23, 2011 at 1:18 AM, Ed Freyfogle < <edf at sloan.mit.edu> > edf at sloan.mit.edu> wrote: > >> >> +1 >> less is more. keep the core library clean and simple. >> >> _______________________________________________ > Mapstraction mailing list > Mapstraction at lists.mapstraction.com > http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com > > _______________________________________________ > Mapstraction mailing list > Mapstraction at lists.mapstraction.com > http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com > > > -- > gary at vicchi.org | twitter.com/vicchi | www.linkedin.com/in/garygale | > www.garygale.com > > > _______________________________________________ > Mapstraction mailing list > Mapstraction at lists.mapstraction.com > http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mapstraction.com/pipermail/mapstraction-mapstraction.com/attachments/20110830/ab507ab9/attachment.htm>
On Aug 31, 2011, at 4:59 AM, Dylan Kuhn wrote:> Good research. If a capability is present in all the providers, I think that would be a good argument for adding it to the MXN core. My "extras" pattern can be used in other cases. I''m not sure it''s appropriate to include any specific "extras" in MXN, but I would like to do two things:Agreed; "extras" are by definition additional to the MXN core. Having said that, I do think that there''s a valid case for abstracting and formalising the "extras" hook, in the way you''ve done in the code sample below and making /that/ part of the MXN core.> Add an example use of the pattern to the sandbox.I have no experience of the hosting for the sandbox but would also like to see support for the Nokia Maps API in the sandbox ... maybe we could collaborate on this together?> Increase the utility of the pattern by adding some more events along the lines of ''markerAdded'' to the MXN core.I''d recommend we throw this out to the community to see what other events should (or shouldn''t) be added to the MXN code. Best G> I''m game to do both of these as my time permits. > > -dylan- > > On Tue, Aug 30, 2011 at 8:20 AM, Gary Gale <gary at vicchi.org> wrote: > Following up on this ... a non scientific and incomplete review of the underlying JS Maps API that MXN supports shows that a zIndex for Markers is by no means supported across all platforms ... > > Google v3 - yes - http://code.google.com/apis/maps/documentation/javascript/reference.html#Marker > Nokia - yes - http://api.maps.ovi.com/apireference/symbols/ovi.mapsapi.map.StandardMarker.html > Bing - yes - http://msdn.microsoft.com/en-us/library/gg427629.aspx > CloudMade - no - http://developers.cloudmade.com/wiki/web-maps-api/CMMarker > Yahoo! - no - http://developer.yahoo.com/maps/ajax/V3.8/index.html#YMarker (and a moot point as the Y! Maps API goes bye-bye on 13/9/11) > > ... given the lack of support for zIndex across this sample I don''t see that we can make zIndex for Markers part of the main MXN API ... with this in mind, is someone up for trying to formalise the "extras" approach that Dylan outlined below? Maybe even Dylan? :-) > > G > > On Aug 23, 2011, at 3:42 PM, Gary Gale wrote: > >> Total and utter +1 from me on that. >> >> Not to be cute or anything but this extras or extensions mechanism could be abstracted and formalised across all supported APIs methinks while still being true to the less is more ethos Ed alluded to earlier in the thread. >> >> G >> >> Sent from one of my mobile gadgets ... >> >> On 23 Aug 2011, at 15:37, Dylan Kuhn <dylan.k.kuhn at gmail.com> wrote: >> >>> I''m also in favor of keeping the library to a minimum, but I want to be able to add features for an API sometimes. I came up with the idea of including an ''extras'' script for the API when I want to do this. As an example, here is my extra code to add a marker ''dragend'' event for the Google V3 API: >>> >>> mxn.addProxyMethods( mxn.Mapstraction, [ ''enableMyExtras'' ]); >>> >>> mxn.register( ''googlev3'', { >>> Mapstraction: { >>> enableMyExtras: function() { >>> var me = this; >>> me.markerAdded.addHandler( function( name, source, args ) { >>> if ( args.marker.draggable ) { >>> // add marker dragend event >>> args.marker.dragend = new mxn.Event( ''dragend'', args.marker ); >>> google.maps.event.addListener( args.marker.proprietary_marker, ''dragend'', function( mouse ) { >>> args.marker.dragend.fire( { location: new mxn.LatLonPoint( mouse.latLng.lat(), mouse.latLng.lng() ) } ); >>> }); >>> } >>> }); >>> } >>> } >>> }); >>> >>> Then, when I create an instance of Mapstraction I do this: >>> >>> var map = new mxn.Mapstraction( container, ''googlev3'' ); >>> if ( map.enableMyExtras ) { >>> map.enableMyExtras(); >>> } >>> >>> That works, but relies on the ''markerAdded'' event in the core library. This pattern should work for setting the marker zIndex also. I think if we''re a little more liberal with events in the core library, more extensions like this would be possible. Firing an event when a proprietary object is created might be a good start. >>> >>> Anyone else like that idea? >>> >>> cheers, >>> -dylan- >>> >>> On Tue, Aug 23, 2011 at 1:18 AM, Ed Freyfogle <edf at sloan.mit.edu> wrote: >>> >>> +1 >>> less is more. keep the core library clean and simple. >>> >>> _______________________________________________ >>> Mapstraction mailing list >>> Mapstraction at lists.mapstraction.com >>> http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com >> _______________________________________________ >> Mapstraction mailing list >> Mapstraction at lists.mapstraction.com >> http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com > > -- > gary at vicchi.org | twitter.com/vicchi | www.linkedin.com/in/garygale | www.garygale.com > > > _______________________________________________ > Mapstraction mailing list > Mapstraction at lists.mapstraction.com > http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com > > > _______________________________________________ > Mapstraction mailing list > Mapstraction at lists.mapstraction.com > http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com-- gary at vicchi.org | twitter.com/vicchi | www.linkedin.com/in/garygale | www.garygale.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mapstraction.com/pipermail/mapstraction-mapstraction.com/attachments/20110831/3b540947/attachment-0001.htm>