Recently, my twitter buddy ruprictGeek developed a Legend Resource Application using Sinatra that would generate an image of Legend for a map service using Ruby. This is a pretty awesome tool, and something that I think could prove useful for things like simplified metadata pages of available map services fr organizations, or bringing a quick legend into a web application. It also taught me a little Ruby and how if you are going to do some Ruby dev, you’re better off not using Windows for it, just my opinion. But I digress, it got me started down a path to build something a little more robust for my Flex Applications.

I had put this implementation on the back burner when I realized how involved creating the symbology in the application would be. Then lo and behold a few weeks back, Mr. Robert Scheitlin released a Dynamic Legend Widget for FlexViewer 2.0. Robert has been a big contributor on the ESRI Flex forums and is a wizard of the ESRI Flex API and ESRI FlexViewer. Now, I don’t use the FlexViewer for various reasons, but he did all of the leg work in his widget that was needed to actually translate the Map Service symbology into something that could be used in Flex. I already had a component that would pull Layers from a Map and allowed you to turn services on and off, as well as individual sub layers. I was pretty happy with it. But the one question I always get asked by my users is, Where’s the legend? We can’t release without a legend. As a side note, most developers might have a project with one or two core stakeholders that steer the project, my main project has about a dozen and if I have a dozen people asking for a legend, I listen.

So what I did was incorporate the work done by Mr. Scheitlin into my current Layer Control tool and created a LegendManager component that will display all symbology and allow you to turn layers on and off. I’m pretty happy with it. This component is part of my FlexMapTools library on github. I’ve included skins and itemRenderers in FlexMapTools, but feel free to modify these to meet your needs. Skin them up and make them as pretty as you’d like. You’ll notice I have not built a skin for the button to expand sub layer details.

An example of the tool in action can be found here.

If you have some trouble using the component if you set up your visible layers using a config.xml file, please read the notes in LayerInfoDetails. You may need to search your visible layers using a string and not an int. It was an odd issue I ran into porting this tool to FlexMapTools.

As always, I am always looking for comments/critiques. I’m more intermediate, so I’m always looking to learn more and see how what Ive done stands up to the pros. Thanks again to Robert Scheitlin for tackling how to draw the legend symbology in Flex and thanks to Glenn Goodrich (ruprictGeek) for inspiring me to get this component off the ground.

Edit: Apparently there is already a MapToolkit product that I didn’t see in my previous searches. I’ll change the repo back to FlexMapTools tonight. My apologies to the MapToolkit folks.

Test-Driven Development is exactly what it says it is. You develop your project with the tests driving you in the desired direction. There’s tons of material on TDD out there, so I won’t cover too many details.

The screencasts offered by The Pragmatic Bookshelf are done by Mr. Kent Beck himself. Go read about him, he knows a thing or two about this kind of stuff.

A great message I got from the screencasts is that your tests should tell a story. You compose that narrative in steps, so as to not trip yourself up. Many times you are probably required to develop against a backend service or directly with a database. So that’s how the story starts. Hello Mr. Database, are you there? May I put something in you?

In this case, Mr. Beck is using Tokyo-Tyrant as the database for this example. By the way, my OCD kicked in 5 minutes into the first screencast and I fired up my Ubuntu server, and spent a good 30-45 minutes toying with installing Tokyo-Tyrant. As there is no debian package that I could find and if you are so inclined, follow these instructions which are good for TokyoCabinet and Tokyo-Tyrant. Or you could not worry about it and just watch the videos like a sensible person might.

Back to our regularly schedule ramblings. I have read a few of the TDD books out there and I try to be a good TDD’er in my Flex Projects, but I happen to be the type of person that does well with visual aids. I can do all the reading in the world, but something about reinforcing that reading by actually watching someone do it just makes it click. This is probably why pair-programming is such an effective tool (I should try it sometime if I ever meet another Flex developer in person and can trick… I mean convince them to show me how a pro does it). It also helps that although the tutorial is done in Java, the syntax is similar enough to Actionscript that I was pretty comfortable following along. If at first you’re wondering why in the video when tests are run, the video kind of fades, they are trying to highlight the JUnit results in the lower-left hand corner. I didn’t figure this out until the second screencast, but chances are you’re not as slow as I am.

Episode 1: Starter Tests , is a good intro to the adage of TTD, Red, Green, Refactor, which you get to see in action in the screencasts. You write out a test, it fails. You write just enough code to get the test to pass, then you refactor to remove that nasty code smell. For me, the snag is usually in writing a meaning full test. We get to see first-hand how a simple test of connecting and writing to a database clarifies the intent and drives the narrative of the story being told. I know I have some tests that just check to make sure a function accepted an argument, but I don’t test what happens when it does not. I think everyone can take something away from the first screencast alone, and it gets better with each installment.

Episode 2: Isolated Tests, this is where the motto of the game is leave the world in the same state as you found it. If you’re going to test against a database, it should look exactly the same after your test as it did before you test. After all, you’re going to ideally run your tests for every refactor, so you’d hate to get a nasty phone call from your DB administrator wondering why you populated the database with hundreds of entries of a testDEEZNUTZ value (never happened to me and you can’t prove it). In this video, Kent Beck gives a good demonstration of building on your current tests, refactoring out the naughty bits and you get to see a Java Class take shape, fully supported by those tests.

Episode 3: Big Feature is all about building some complex functionality by using TDD to break it down into fun size bites. You start to get some real meat in this screencast and see how Kent Beck handles building on top of tests and the logic behind his decisions.

Episode 4: Finishing is where we clean up the code and make it presentable. This is also where Kent Beck provides a review of previous screencasts. In the first half of the video you end up with a functional map for Tyrant. The last half of the video is a summary of the series and you get some great insight and tips from a pro point of view on design decisions. Pros always make it seem so easy.

Even if you’re familiar with TDD and have been using it in your projects, I think you’d probably still be able to find some gems of information in these screencasts. You might be able to pick up some tips from Kent Becks style (the guy’s got style) and I would even say there are some great tips in these videos on refactoring your code and cleaning it up.

If you’re new to TDD, you have to start somewhere and I think these videos would be a great starting point before diving into the written material that’s available out there. I’m a kid of the 80′s, I was raised on visual aids.

One of the best things about the videos is that you get the sense that it’s not just a scripted screencast. I’m sure Mr. Beck had an outline, but as he’s writing the tests and implementations you can tell he’s working through problems in his head and is probably crossing his fingers for a passing test as much as you might. This makes the videos very personable and you almost feel like you’re sitting in the chair next to him just trying to soak in the knowledge via proximity osmosis.

The screencast are available for a reasonable price as a package deal or separately, but why bother buying just one, gotta catch them all.

The first is the FMap component, which extends the ESRI Map component. This component started as a way to control the position of the ESRI logo in the application. In previous releases the ESRI Flex API and even the beta version of 2.0, the logo fit just perfectly in the layout of one of the main projects I am working on, but in the final 2.0 release it was moved slightly to fit in with the FlexViewer layout. Now, it’s easy enough to set the logo visibility to false, ESRI provides this out of the box, but I kind of like the look of the new logo. Being a little annoyed that this little bit in the API was catered to the FlexViewer rather than the other way around, I decided to just extend the Map component and move it myself.

Default logo position blocked by a toolbar in my application.

Logo position set to fit application layout.

ESRI was kind enough to give us access to a staticLayer Group component in the Map that is used to hold the navigation tool, scalebar and the logo. You could pretty much add what you want in here. So all FMap does is add a Number property called logoToBottom that will be used to position the logo.

That’s pretty simple.

The next thing I decided to do that is pretty common in a lot of applications was to display coordinates. The FMap component assumes you are working with the WebMercator coordinate system that is all the rage these days and also that you want to display normal WGS1984 coordinates, because you do not want a user filling out some permit paperwork using WebMercator coordinates, so be aware of this. If you would like to convert to a different coordinate system, you’re going to have to handle the math in your application. Sending them to a Geometry Service to process on a MouseMove event will bring your application to a crawl.

I add a showLatLong Boolean property the Map and check that in an override of createChildren.

Notice that the group has a styleName defaulted to “latLongText”. This allows you to set the style in your stylesheet. If you have not looked into really using css with your Flex 4 applications, you owe it to yourself to look some stuff up. I’ve gotten quite a bit of use out of it recently. This allows me to do something like this in my css.

Coordinates positioned under scalebar.

As you can see, css can be a valuable tool in drilling down into the components inside components to manipulate their styles. Remember all this sits in the actual FMap component and can be used from project to project. And because it extends the default Map component, it can be passed into any component/object/function that asks for the default Map component. This should include any widgets you might use in FlexViewer. I also add an eventListener to listen for the REMOVED_FROM_STAGE event, that will handle some cleanup by setting the stuff I added to null. It may be overkill, but I’ve gotten used to doing this when dealing with custom components.

If there are certain things I did in FMap that don’t fit your needs, you could always modify it to fit your project workflow. Maybe you want the logo somewhere else, add settings to modify the top/left/right properties of the logo and go nuts.

I’ll cover some of the other tools in the FlexMapTools toolbox in future postings and if you have any questions, suggestions, critiques, please feel free to share.

So aside from posting little snippets here and there, I decided to put portions of my library file of common tools I use to develop ESRI Flex Mapping applications on github as the FlexMapTools library.

I’ll continue to build on this library and hopefully improve my own skills as well as maybe assist some other developers with their projects. There are lots of other items I use not in the library yet, mostly because I think it still needs some cleaning up. I’m also hoping for some critique. I’m pretty much flying solo in my learning path when it comes to development, so I don’t really have a mentor. I just attempt to absorb knowledge via internet osmosis and following smart people on twitter.

There is a Yahoo Finance Processor, a URLMapping Processor and even a MediateSignalProcessor. It all looked a bit in depth to me, I’m still what I would call an intermediate in my dev skills at this point, but I decided to take a crack at it.

Since most of what I do is based on the ESRI Flex API, I decided to try making a GeocodeProcessor. The idea is that you can set up a Processor that would act as your delegate to a geocoding service. This way, you could just move it around different projects using swiz and simplify the task. I pretty much just used the geocode example from the samples pages.

You can view an example here and I also put it on github here. By the way, my first github attempt, and I was quite lost for a bit. I’ll need to learn how to use it for future projects. As for the application, when you search for an address, click the Center Map button up top. This is a hurdle I’ll explain shortly.

First off, thank you to those who already created some custom processor examples. I would have been scratching my head for a while trying to find what works and what doesn’t. First, part of the need to do something like a Geocode Processor requires that you be able to send a new address request to get updated information. I thought of using the idea of copying objects from the Mediate tag that was used in the URLMapping processor, but I couldn’t figure out how to do that AND send an updated object back to the application.

I went a different route, and one that is probably not recommended and that was to make a public getter/setter in the GeocodeProcessor to hold the Address object that could be updated from my application. In my case, I added the object to my Swiz via binding as can be seen here. Then my processor would listen for changes on the object and run a new geocoding task as can be seen here.

As I mentioned before, I had an issue that required I add a Center to Map button. For the life of me, I could not figure out how to let the map know that an address had been added to the map. I’m sure this is just a matter of finding the proper events to listen to or maybe setting my Swiz initialization, but I couldn’t figure it out. I thought I should at least mention it.

I was actually a little surprised it worked, but also pretty happy with how simple the concept of using a custom processor is once you go through the process of writing one. For geogeek ESRI Flex devs, I can think of a couple of uses such as maybe a processor for creating a GraphicsLayer set that is commonly used in your organization or possible some other tasks. Like I said earlier, I’m still not completely happy with having a public variable on the processor that needs to be updated manually, but this was mostly just a proof of concept for me and a learning experience.

So if you’re interested in the idea of custom processors, I say give it a shot. Go grab your source for Swiz here. Now that I’ve done it once, I think I may like to try doing some more.

This past week, I have been tinkering around with a project that will be redone and figured out that if you create a named Bean for a regular Signal, you can then Inject/Autowire that Bean into any Signal in your application.

This turns out real nice because then all I have to do anywhere in my application is the following.

There’s no need to create a custom Signal in your application, even if you are going to dispatch a payload. No more signals folder for me. I’m not sure if there is a performance hit for not defining the type of Object that will be dispatched with your Signal, but so far this has turned out pretty well for me.

I threw together a quick example with source here. I’d also like to point out that Swiz 1.0 metadata Injecttion into view components is really nice and lets me do cool things like this.

That is so cool.

Some good resources of getting started with AS3 Signals is this video by John Lindquist. I don’t know about you, but I have found that these screencasts are a great way to get a grasp on an idea. There has also been some testing to show that Signals can actually be quicker that Events. This could appeal to you if you are writing a large application that could benefit from the increased performance.

As I see it, you would use Signals in place of creating custom events that would be dispatched to carry a payload. In trying out signals, I began to think of how much I might want a signal to do. Most examples I have seen treat them as value objects, but I suppose you could turn them into full blow mini-controllers. One area I might try playing with signals is in processing raw data from a service into something the rest of my application could use.

Joel Hooks already  put together a cool AS3 Signals/Robotlegs example that showed how you could leverage Signals with Robotlegs. So I figured, hey, I’m going to try Signals with Swiz.  I haven’t really tackled Swiz in a while as my current project uses RobotLegs, but with Swiz 1.0 Alpha out and 1.0 beta coming up, I thought I’d give it a shot as I anticipate using Swiz 1.0 in a couple of upcoming projects. I tried some stuff out in the available examples and then put together a small demo app.

Application

Source

It’s not a pretty example, but it shows a couple of ways that you can treat signals in your application.

I use a couple of value objects with signals in my application model. This way, I can Autowire (the Inject tag is supported in the latest builds, but I already had this alpha build on hand) my model into my controller and assign the listeners that way. With this method, you have the ability to keep your listeners private, which some people might find appealing. A disadvantage here is that some people might not like tying the controller in this manner. I haven’t tried unit testing a controller like this yet, so I’m not sure if it would pose a problem.

Another method is to drop a value object with a signal directly into my BeanProvider and assign a function from a Controller as the listener when you initialize the Bean. The rest is pretty simple, I added some comments where I thought they’d be useful.

Swiz 1.0 offers some cool new features like custom metadata processors and virtual beans, which may be able to manage signals is a more efficient manner, but I have not had the opportunity to dive into that much detail in Swiz to be comfortable saying if it would work or not. As for my opinion of Signals, I’m not sure I’m entirely sold yet, but as I built the example, I began to think of the possibilities of mapping them out with a decorator pattern or similar. The fact that it got me thinking about it seems like a good sign. I’m always a little hesitant to add APIs to my applications, but when it comes to being used in the context of the framework of my application, I think I’d be a bit more comfortable. I expect I’ll take AS3 Signals for a test drive in the near future.

So as I was working on some items, I remembered a 20-minute Swiz video that Joe Rinheart had posted that helped me out when I first started looking at Swiz. In that video, as a shortcut, Joe had simply binded a service to a delegate inside his BeanLoader to eliminate the need to Autowire an object in a Delegate. This got me thinking about the need to use Autowire with the metadata tag in my applications. When you Autowire an object using Swiz, the object has to be public anyway. The BeanLoader is already an IoC container. So why use it? After I had read Clean Code, I began to look at keeping my code as minimal as possible to get the job done. Although, an Autowire metadata tag was no big deal, I just felt like it was one more item I could eliminate from my code.

You could accomplish this in your BeanLoader.

Now I have eliminated the need to Autowire the mockDelegate object in my RequestController.

I have built a simple example that can be found here, with view source enabled. You’ll notice that I don’t use the Autowire metadata tag anywhere, allowing the BeanLoader to do the Autowire for me. Well . . . not quite true. I was not able to get away from using Autowire in a Mediator for my views, even if I tried to add them to my BeanLoader and bind them in there. I used a simplified version of an AbstractMediator class that Brian Riley used in his Swiz Passive View example. If anyone has any ideas as to why I had to Autowire this view, I would love to hear it, it was driving me nuts. Anyway, as you can see, all I used in my example was the Mediate metadata tag to mediate my events. That’s what I call simple and clean. As an aside, I am also using the ESRI Flex API, with some mock data that is built using the FeatureSet.convertFromJSON method, which comes in real handy. This is the main API I use for day to day work.

Now is this really necessary? Probably not, but it does keep my MVC code lean. That’s a great strength for Swiz, is the ability to adapt it to your style. This allows me to really focus on building my custom objects that will really do the grunt work that my MVC will simply delegate.

Old blog was imported from blogspot, some errors came over that will need to be fixed.
http://odoenet.blogspot.com/