Defining Object Dependencies

We’ll begin by learning how to add dependency injection into an application. First, we need to recognize our object dependencies. In the sample application below, the ContactList view requires the ContactManager model object to provide its data. In Parsley, marking that dependency as an injection point is as simple as adding the [Inject] metadata tag above the property declaration.

Parsley can also inject properties into constructors and other methods, and you can find more information on that here.

Creating the IOC Container

Next, we need to tell Parsley where to find the ContactManager class before it can inject it into the view. To do this, we need to add it to the IOC Container, which is responsible for wiring all our dependencies together. The container can be written as MXML, ActionScript, XML, or a combination of the three. For more information on using these methods you can view the documentation here. For this example, we will look at an MXML configuration. To do this, simply create an MXML file with mx:Object as the root tag, and add references to the objects that we will need to wire, like so:

Wiring the View

The framework won’t know to look in our ContactList view for injection points unless we tell it to. To do this, we need to also add the view into the IOC Container. There are two ways of doing this. We could explicitly declare it in the container like we did in the previous step for the ContactManager. But for views, Parsley allows us to dynamically wire them by simply dispatching a single configuration event like so:

The configureView event tells Parsley that the view should be added to the IOC Container at runtime.

Initializing the Framework

Finally, to put it all together, we need to initialize the framework and provide Parsley with the IOC Container we created. We want to do this as early as possible so doing this on the addedToStage event is common practice. Simply call the FlexContextBuilder.build() method and provide the IOC Container and the root DisplayObject used for wiring (typically the application root).

Here is a working example of the code. The application is very simple; when you click the button it simply populates the ContactModel object with data, which is bound to the DataGrid. The key is to notice how the ContactModel has successfully been injected into the view.

You can view the source code here.

Points to Remember

• Dependency injection takes time, and your objects might not be immediately available. In your views, even after the creationComplete event, your objects may still be null. So what you need to do is use [Init] metadata to designate a function for Parsley to run after injection is complete. Using this instead of a Flex event will ensure that your objects are all available and ready for use.
• Don’t forget to add the application root to the IOC Container, if necessary. Even though you may initialize the framework in the application root, and use it as the view root of the Context, you will still need to dispatch the configureView event if you need dependency injection to take place in the application root.

Conclusion

If you haven’t done so already, please read the Parsley Documentation for more information about dependency injection and the Parsley framework. And like I stated in the intro, I’m new to Parsley myself so if anyone would like make corrections or suggest any best practices, please feel free to do so in the comments.

The Flex framework comes with several classes to assist you in printing; however, they don’t tend to produce the greatest results. The PrintDataGrid class is probably your best option when it comes to printing data, but whenever I’ve worked with it in the past I’ve always ended up disappointed. Even after formatting, there are always issues; like rows getting cut off and pages breaks in weird places.

There have been talks about AlivePDF offering a Grid class to the library, which may be interesting, but it hasn’t been released and would probably only handle DataGrid data. So the best option I’ve found for printing data is to allow a server to generate a PDF, which can then be sent back to Flex and output however you want.

A great benefit of this option is the ability to easily format the print results. You can use simple HTML and CSS to customize the printout much easier than you could using ActionScript. You can also add custom styles, letterheads, and footers to fit your needs.

Here is an example, you can view the source here.

This will work with any server-side script that can generate PDF content. In this demo I am using a ColdFusion script which simply generates an HTML table and returns it in PDF format. You can view the ColdFusion code along with the rest of the source code here.

The data from the server is returned to Flex as a ByteArray. You can take that ByteArray and output it to the user in several different ways:

Using the Browser

Similar to the last article in this series, you can send the results to a server-side script to either display the PDF in the browser or prompt the user to open or save the document. This time, however, the AlivePDF library is no longer necessary since the PDF binary has already been created.

Save locally from Flash

Thanks to new capabilities in Flash Player 10, you can also provide users the option to save the PDF directly from Flash. This eliminates the need for the second server-side script.

If you plan to use the save functionality you’ll need to set the “Required Flash Player version” in your project preferences to 10.0.0 or higher or else Flex Builder will complain. You have to remember that only users with Flash Player 10 or above will be able to use this functionality, so some type of version validation is a necessity.

Another caveat is that the save method must be triggered by some type of user interaction, that’s why the sample application prompts for system access before saving. Although the user has clicked the “Print Data” button, that event is lost when the server call is made, so we need another interaction from the user.

In this article I will demonstrate how to print and save any part of your application by utilizing the AlivePDF library. AlivePDF is an ActionScript 3 open-source PDF library that easily creates PDF documents from your Flex application. The library is pretty robust and offers much more functionality than I will be able to cover here. In this article I want to demonstrate how simple it is to dynamically generate PDF documents using ActionScript and AlivePDF.

To give you a better understanding of what can be done with AlivePDF, let’s revisit one of the printing examples that was used in part 1 of the series. The two images below are printouts of the The Flex Store – one printed with Flash’s default print option and the other with AlivePDF.

Flex Store printed using Flash’s default print option

Flex Store printed using AlivePDF

In addition, here is a sample application for you to play with some of AlivePDF’s options. You can view the source here.

So now that you’ve had a taste of what AlivePDF can do, lets look at how it works:

Adding AlivePDF to your project

First, download the library from www.AlivePDF.org, and then add it to your project in one of two ways. The easiest way is to copy the AlivePDF.swc into your project’s lib folder. Flex Builder should automatically detect the swc and add it to the compile settings. The second approach is to add it manually in Flex Builder, by clicking Project >> Properties >> Flex Build Path >> Library Path >> Add SWC… and selecting the swc from the file system.

Displaying PDFs in the Browser

After the swc has been added to your project you can begin working with the AlivePDF library. The sample code below could be used to generate a PDF document from any UI component in your application. We simply turn it into an image (think of it as a screenshot) and publish it to a PDF for the user to save or print.

The code is fairly simple, we start by creating a new instance of the PDF class and adding a page to it. Then we add our UIComponent to the document as an image. Finally, we tell AlivePDF how we want to generate the PDF with the save() method. In this example, the third argument of the method, Download.INLINE, specifies that we want the PDF to be displayed in the browser instead of prompting the user to save (that will be covered in the next section).

Prompting Users to Save

Now that works great and all… but what if you want to prompt the user to save or open in Adobe Reader? Fortunately, AlivePDF makes that easy; all you have have to do is change Download.INLINE to Download.ATTACHMENT.

Using AlivePDF with ColdFusion

A PHP script is provided with the download of the AlivePDF library, but if you don’t like PHP you can use any other server-side language that can generate PDF content. For those of you who are ColdFusion fans, like myself, here is a basic example of a ColdFusion script that can be used.

AlivePDF has a wide range of capabilities and we’ve barely scratched the surface here. I encourage you to take a good look at the library and utilize it to its full potential.

In the next article in this serious we will discuss how to print data from Flex. See you soon!

By default, when users right-click on a SWF file, they receive the default context menu, which provides them several options, and one of which is the ability to print. However, in my experience, using this option for printing returns horrible results. Below are two examples of this, the first is the The Flex Store, a sample application from Adobe, and the second is the Verizon Media Store. On the left is a screenshot of each and on the right is a capture of the print results that were produced by using the default print option.

The Flex Store application:	Printing the Flex Store:
The Verizon Media Store:	Printing the Verizon Media Store:

As you can see, the results were less than satisfactory. I would consider this unacceptable for my applications. So, the question arises: “How do you prevent users from printing from the context menu?”

The answer is simple – override Flash’s built-in context menu with your own. This is how you do it:

Okay, so let’s review the code. The first thing you need to do is to create a new ContextMenu and then call its hideBuiltInItems menthod to disable the built-in options (forwardAndBack, loop, play, print, quality, rewind, save, and zoom). This hides the print option and prevents the user from clicking it. Next you add our own menu item to replace the default print option. If you don’t want to do this, because you are going to provide your own print button on the application, you can skip ahead to the last line of code.

To add our own menu option, just create a new ContextMenuItem object and give it a label. Then add an event listener to catch when the user clicks on this option (in this example we have specified doPrint as our listener function; we will be working with that method in the proceeding articles of this series). Finally, add our new menu item to the customItems array, and set our new menu as the contextMenu for the application.

You can see the results below. Although nothing spectacular has taken place here, we’ve disabled Flash’s built-in print capabilities and will be routing all print requests through our own function.

Gotcha:

When creating CustomMenuItems, the labels you provide must be different than those provided by the default items. For example, you cannot use “Print” as your label or the application will ignore the option. However, you can use variations, such as “Print This” or “Print Page.”

In the next article we will discuss how to generate PDF documents for more functional printing and saving. For more information of the ContextMenu, check out the Livedocs.