This was both rewarding, frustrating and ultimately a lesson in when to do one design over the other.
My initial thought was something along the lines of;
1. Flex(actionscript) is heavily geared to be an event based system.
2. A telnet protocol incorporating all events would be cool
3. Hey I'll write an event based telnet socket!
It works, don't take me wrong, it works.... but it also generates an awesome amount of events. Espacially when one considers that to be a true telnet client that you have to operate in a char by char model. i.e. every single character that traveled across this pipe was generating an event to end up rendering the display.
Combined with the single threaded nature of flash and we got ourselves an interface that felt a lot more slow then it needed to be.
I'm a developer and code junky. I like languages, and the premise behind how and why people write the code that they do.
Showing posts with label Flex. Show all posts
Showing posts with label Flex. Show all posts
Friday, December 18, 2009
Wednesday, December 16, 2009
Creating a MUD client
Recently I decided to take on a side project. Something to do outside of the business realm that would keep me mentally occupied at home. As an old school adventure player. I thought a good start would be to create a telnet application to play MUD(MU*) games.
This process, which has been going on for several months now has been a fascinating learning experience. To the point that I felt it appropriate to start recording the useful bits of information I had found out so that those who may come after me are assisted in their endeavors.
The technology I decided was to use Adobe Flex/AIR
This process, which has been going on for several months now has been a fascinating learning experience. To the point that I felt it appropriate to start recording the useful bits of information I had found out so that those who may come after me are assisted in their endeavors.
The technology I decided was to use Adobe Flex/AIR
Thursday, July 17, 2008
Aligning a checkbox in a Flex Datagrid
When you need to align a checkbox within a Flex based Datagrid the best way to do it is to center it with a Horizontal Box as so
<mx:advanceddatagridcolumn headertext="Parts Ordered?" width="80" datafield="parts_ordered" fontweight="bold">
<mx:itemrenderer>
<mx:component>
<mx:hbox disabledoverlayalpha="0.0" enabled="false" horizontalalign="center" verticalalign="middle">
<mx:checkbox selected="{data.parts_ordered.toString() != 'F'}">
</mx:HBox>
</mx:Component>
</mx:itemRenderer>
</mx:AdvancedDataGridColumn>
Tuesday, July 15, 2008
BlazeDS - Filtering out your own message
Recently I created a record management framework for a RIA that I've been working on for my employer.
The idea behind this is that as soon as an individual opens a record for possible editing he locks the record from being edited by any one else.
Using Flex/BlazeDS this was rather straightforward. I created a new channel called recordMangement and sent all lock/unlock requests to it.
One of the options that I wanted to do, however, was to filter out the messages that I was sending so that the event handling would be efficient and straight forward.
My first thought was to use the connection ID that is created when you connect to the DS channel. I would then just ignore those messages that came from the same ID as the one I have. This turned out not to be as effective as I liked as I came to the conclusion that the connection ID was an ID that was specific to the physical connection itself and not the logical connection. Therefore it was possible for the physical connection to be reset between the sending and receiving of the event.
In the end it became more efficient to create a unique ID instance using the UIDUtil.createUID function which became a constant value for all communications that I establish and then use the selector function to designate a filter for the my consumer.
consumer = new Consumer();
consumer.selector = "(from <> '" + uid + "')";
The idea behind this is that as soon as an individual opens a record for possible editing he locks the record from being edited by any one else.
Using Flex/BlazeDS this was rather straightforward. I created a new channel called recordMangement and sent all lock/unlock requests to it.
One of the options that I wanted to do, however, was to filter out the messages that I was sending so that the event handling would be efficient and straight forward.
My first thought was to use the connection ID that is created when you connect to the DS channel. I would then just ignore those messages that came from the same ID as the one I have. This turned out not to be as effective as I liked as I came to the conclusion that the connection ID was an ID that was specific to the physical connection itself and not the logical connection. Therefore it was possible for the physical connection to be reset between the sending and receiving of the event.
In the end it became more efficient to create a unique ID instance using the UIDUtil.createUID function which became a constant value for all communications that I establish and then use the selector function to designate a filter for the my consumer.
consumer = new Consumer();
consumer.selector = "(from <> '" + uid + "')";
Subscribe to:
Posts (Atom)