Multiple objects using Senocular TransformTool

Senocular TransformTool is one of the best and most used components around the net. It is really useful for those (include me) who don’t want to fight against Matrix, concatenation of Matrix and all those painful stuff…

The only ‘lack’ of that component is that it does not support multiple objects as target. If you want to transform n array of elements at the same time you should have all those elements in the same parent DisplayObjectContainer and then set that parent as target of TransformTool.

But maybe sometimes this is not possible due to various reason and you want to use different items with different parents as dataprovider.

This is the solution I actually use for that particular situation (Remember that I’m using a modified version of the TransformTool)

This is the final result: ( Ctrl+click on the tree leaves to multiple selection )

Live Demo of the Trasform Tool using multiple objects

( Here you can download download the source files ).

In few words the solution I found is this:

Create a temporary layer which will be the TransformTool target.
For every item in the selection Array create a temporary shape with the size of the getBounds() of the real object. Store this shape into the temporary layer, assigning to it the concatenated matrix of the real object.

Once there’s a transformation of the temporary layer get every shape transform matrix and assign back to the original object.

Probably there are many and better solutions to do the same, this is just the one I found, maybe someone has better approach to this problem (and he is welcome here!)

A long journey through chunked transfer and file uploading

It has been a while since I wrote the last post … I know, I’ve still quite a lot of stuff left opened but sooner or later you’ll get it. Don’t worry 😉

During the last days I’ve been working on improving some server side API for a client I’m working for.

Actually they’re using a mix of AMF and HTTP based API but, as long as the AMF implementation is unfortunately a bit unstable, they want to move to a full HTTP based API … that sounded quite easy: take a bit of HTTP, dress it with POST and maybe XML (or whatever other ingredient you like most) and you’ll have a good base to start porting the API.

But I’ve ignored a small particular that turned out to be really painful to manage by using just HTTP: sending efficently to the server big chunks of binary data.

Those were the requirements I had to fulfill:

  1. I have potentially really big binary files to be sent quickly to the server;
  2. I have to track upload progress somehow;
  3. I must be able to trigger the upload without the user interaction;
  4. I should rely on HTTP only;

And here the solutions I’ve tried to implement, and the conclusions I’ve achieved (well, I didn’t try all the options because I already knew that a few of them were not suitable for my situation, but they might be useful to someone and so I’m reporting them anyway).

Continue reading