Originally Posted by
geoffrey.mcgill
#1. Shea did a great job on the original Ext JS UX version, but the component needed a good overhaul by the time Ext.NET 2 rolled around. I'm not sure the original code was ported to Ext JS 4.x either. I did contemplate taking on the updates and contributing back to Shea, but (see next)
The link I shared seems to suggest that it has been updated to extjs 4 and supports both static and dynamic (which is GREAT). I haven't tried it though and I'm still not too sure how to use general extjs extensions in extnet or else I'd confirm.
Originally Posted by
geoffrey.mcgill
#2. There was very little demand for the component. Even though there were some issues and limited functionality with the component, we received very few support requests, or feature requests. Since dropping the component, I think you were the first to bring up the topic.
I'm pretty confident there is demand. There seem to be plenty of users on the forums who've mentioned it at least, though as stated, I think the reason it might be light is most of us have already rolled our own. I know I did before it was available in v1.x and because of that didn't need it when I upgraded to v2. I'd have had to mention it sooner for sure if I had used the one in v1 when upgrading.
The only reason I thought about it again is because I'm building a totally new mapping page and thought it would be nice to try the built in one, then realized there wasn't one. It sure would be nice to have one that resizes with Flex in panels as that was my primary consideration to look. The problem though is that the mapping source from google does require a height and a width as part of the initialization. I'm not sure how well that translates into resize updates or even if it can. I'll keep you posted if you're interested, but that was my biggest reason for wishing for the implementation. That, and markers, as I'm about to have to roll my own again that supports more than one.
Originally Posted by
geoffrey.mcgill
It's something we could certainly support in the future, and I would love to build a robust Mapping component. I will review the idea.
Keep me posted. From a marketing standpoint, I think it would just enrich the robustness perception of the toolkit, especially with an example in the explorer. It's one of those components that users considering the kit might think, "nice, and now I know that if we move in that direction, we have that too." But its true, it is still sort of specialized, though in my opinion, no more specialized than say the calendar control is.