generating form layout code with jsfl

I just put together this little extension (mxp or plain jsfl), which outputs the actionscript to create all the components that are on the stage and assign all the same parameters etc. It's obviously not as streamlined as real IDE code generation, like in Visual Studio, but it definitely is going to make my life easier.

Using this, I won't have to put all my form code in onLoad, which always seemed like a hack, and I won't be constantly having to keep the class properties in sync with the what is on stage.

Here's the workflow I have worked out:

1. Create symbols for each form (or... ahem.. use Flash MX Pro 2004's Forms)
2. Create a class and assign it to the form. For Flash forms, that's in the Property Inspector, otherwise its in the symbol linkage panel. The class should extend UIObject or UIComponent, View, Form etc, which is assumed.
3. Add imports for mx.controls.*, DepthManager and UIObject. The generated code uses these.
4. Create a separate .as file for generated code, and include it in your class with #include. This keeps things clean, by not mixing the generated code with your own.
5. Create a guide layer inside the symbol (that is important).
6. In the guide layer, add the components you want to use and assign them properties. They won't get compiled into the swf because its a guide, but it still gives you a permanent visual reference, that you can refer to later or tweak.
7. Run the command, and copy all the code from the output panel. (This is the step I don't like so much)
8. Paste the code into the include file, and add a call to createChildComponents() in your init() method, or wherever you want to create them.

Here is what your form class might look like:

  import mx.core.UIObject;
  import mx.controls.*;
  import mx.managers.DepthManager;

  class MyForm extends UIObject {

  #include "MyForm_children.as"

     function MyForm(){
     }

     function init(){
        super.init();
        createChildComponents();
     }
  }

I know there is a lot more that it could do. For example it could automatically create and save the include file, and edit the class file itself. It doesn't currently check that the components are in guide layers. Let me know if you do any work in those directions, or make a panel or (more likely) something I didn't think of. Comments are down at the moment, due to a problem with the database, but should be back up soon...

Saffron font engine in 8Ball

After seeing the flurry of posts about Moock's 8Ball feature video, I thought I'd check out what Saffron is all about. It's not as exciting as the visual effects that were also demo'd - but there's not much chance of finding public info about that online right now!

From what I can glean from the limited public resources on the internet, its a font rendering engine, based around ADF (Adaptively Sampled Distance Fields), which allow you to define graphics that can be scaled to different sizes, including very small, and display nicely on digital displays.

Traditional font descriptions contain, amongst other things, hinting information. Hinting is how the font makes sure that it is rendered clearly at small sizes. Its a complex business, and its implemented very differently for Type1 fonts as it is in TrueType, but significantly adds to the file size in both cases. In particular, TrueType hinting is hugely complex (its a program that has to run in its own VM), and usually comprises a large table of data, describing how each glyph should be rendered at each individual pixel size. Flash has never exported hinting information in a swf, because of the filesize increase of the font, and because they'd have to choose between TrueType and Type1 or both, and include player support. In fact, the Flash player doesn't support any standard font format, with hinting or otherwise; fonts in a swf are defined the same way as any other vector shape. This is why fonts can look blurry at small sizes, and its why Macromedia introduced the "alias font" option in MX 2004, to apply the available hinting information at authortime, to create a new font that looks good at a fixed size.

Saffron seems to solve the hinting problem altogether. If I've understood this correctly, it converts font data to ADF which represents each glyph in terms of its details, rather than simply a mass of curves. The engine can then adapt the rendering process to make sure smaller details are rendered on pixel coordinates, instead of rendering each curve precisely as the data dictated.

This should make a lot of people happy. Mainly because we won't have to listen to all those designers moaning that Flash doesn't support hinting ;-)

In domains we trust

My gas and electricity bill now arrives as an email. I view my bill by following a link to www.house.co.uk where, amongst other things, I can manage my account and pay online.

Now, I think most competent web users are aware of the epidemic of fraudsters spoofing emails from banks and building societies, and setting up websites that look exactly like the one where you pay your bill or access your account. The idea is to trick you into giving them your credit card or login details. So I'm always cautious of these emails, even if my spam filter allows them through, I make sure that they are genuine before I do anything. I know that my account is at house.co.uk, so I trust anything that is there. Similarly, I trust pages on hsbc.co.uk, my bank's website.

So what is my utilities company thinking when they send me emails with links to pages on house.mx0.net? If I was going to spoof a website, I'd do it on a domain that looked pretty much identical to that. Do they want me to delete the email without reading it? To make matters worse, on pasting the link in my browser, I was redirected to a 3rd domain, images.innovyx.com. Consistent use of domain is the only solid test that we users have to make sure we are not being defrauded. I understand that this is all because British Gas has saved costs by paying a separate company to handle all its mass emails, but I wonder how much online custom they have lost because of it...

Shared Libraries and absolute URLs

In developing the Ariaware Optimizer, we had to get intimately involved with the subtleties of RSLs. One annoying thing about them is that, if you use a relative linkage URL, Flash resolves the URL as if it is relative to the url of the movie in _level0, rather than the movie that actually linked the symbol. One important consequence is, if a RSL uses a symbol from another RSL, you really must use an absolute path or URL. In fact, although it sounds backwards, it is usually more flexible and maintainable to use absolute paths for RSL linkage URLs.

In the Optimizer, we decided not to force users to use absolute paths, since people are bound to use it outside of our expectations, but we heavily hint that you should by prefilling the input box with "http://", in the GUI version of the tool. You could equally use an absolute path, starting with "/", of course.

sending variables cross-domain without a policy file

A number of times, I've needed to send variables to a different server, without needing to handle the response. Mainly this would be for logging usage stats for a client that wants the stats to show up on their existing reporting system, based on http logs, while we're hosting the project on a different domain.

LoadVars or XML won't allow you to do this unless you are in Flash 7 and you have a policy file on the server. Not always possible, and we usually end up using proxy scripts or loading the logging script into a hidden html frame, with getURL. Either way its messier than I'd like.

But it turns out you can get around it using loadMovie. Flash allows you to load other swfs from a different domain, and will quite happily try to do so if you give it a url. If the response is not a swf, Flash just fails silently, but the script is called and the data is sent. In my tests, I successfully sent both GET and POST data.

coding for the browser and Central

I'd been wondering if anybody had thought about this yet, and apparently they have. One of the appealing things about Central is that its Flash, so you should be able to use the same apps in Central as you use online. Of course, it isn't so straightforward because Central apps must be structured in a very specific way, which means you can't just use an existing app in Central, and Central provides a lot of framework, so you can't just use a Central app on the web.

Dirk Eismann has written an overview of how you can achieve this flexibility, using an abstract factory. By separating the core logic of your application into a class that assumes nothing about its context, you can define a different subclass for each environment. The task of the abstract factory is simply to detect the environment and create an instance of the appropriate version.

I'm just glad that someone has been thinking about this, as its probably vital to Central's success.