I am very proud to announce the release of Flextrine 0.9.  This is a major release with changes across the board; much of the codebase has been improved, optimized and cleaned up, and a host of new features have been added.  Flextrine has also moved from Google Code to Github, and the documentation has been completely updated for the new version and is available on the Github wiki.  Some of the new features are listed below:

• The ability to run multiple Flextrine applications within a single install – Flextrine will ship with a micro-framework to facilitate this along with a command line tool to create new projects.
• Flextrine Manager functions, including entity generation, will become available through the command line (implemented through the Doctrine console tool) to aid in build processes.  The Flextrine Manager has been removed.
• Configuration files are YAML instead of PHP.
• Support for XML, YAML as well as annotations in entities (this was done mainly to enable the use of the awesome ORM Designer) .
• Massive performance boosts when updating large objects graphs.
• Lazily loaded collection associations can be configured to load on demand, throwing ItemPendingErrors to allow Flex components to react to the updates automatically.
• Lazily loaded entities can be configured to load on demand.
• Improved DQL querying from Flex including support for named parameters and hydration modes including scalar queries.
• Bi-directional associations are now auto-managed by Flextrine, so there is no longer a need to set both sides of the relationship.
• An EntityManager::rollback() method that undoes any changes made to the repository.
• Class table and single table inheritance.
• By default repositories hold weak references so that unused entities are eligible for garbage collection after Configuration::entityTimeToLive has elapsed (configurable globally or per repository).
• The option to run Flextrine in PULL mode; this queues up changes but doesn’t apply them to the repositories until a successful return from em.flush() (experimental!)
• PagedCollections which load query results as the user scrolls (experimental!)
• Integrated support for access control to entities using Zend_Acl (experimental!)
• Heaps of bug fixes!

Flextrine v0.9 is available from www.flextrine.com

If you get the chance get along to the summer conference in Norway or next winter’s one which will once again be in Switzerland.  It sure beats sitting in an office…

http://www.gotoandski.com/, and you can see us having fun in the snow at http://www.flickr.com/groups/gotoandskiswitzerland/

Here are a few of the things that will be in the upcoming release of Flextrine:

• The ability to run multiple Flextrine applications within a single install – Flextrine will ship with a micro-framework to facilitate this along with a command line tool to create new projects.
• Flextrine Manager functions, including entity generation, will become available through the command line (implemented through the Doctrine console tool) to aid in build processes.  The Flextrine Manager will probably be removed.
• Configuration files will be YAML instead of PHP.
• Support for XML, YAML as well as annotations in entities (this was done mainly to enable the use of the awesome ORM Designer) .
• Integrated support for access control to entities using Zend_Acl.
• Massive performance boosts when updating large objects graphs.
• Lazily loaded collection associations can be configured to load on demand, throwing ItemPendingErrors to allow Flex components to react to the updates automatically.
• Lazily loaded entities can also be configured to load on demand.
• Improved DQL querying from Flex including support for named parameters.
• Bi-directional associations are now auto-managed by Flextrine, so there is no longer a need to set both sides of the relationship.
• An EntityManager::rollback() method that undoes any changes made to the repository.
• Class table inheritance.
• By default repositories hold weak references so that unused entities are eligible for garbage collection after Configuration::entityTimeToLive has elapsed (configurable globally or per repository).
• The option to run Flextrine in PULL mode; this queues up changes but doesn’t apply them to the repositories until a successful return from em.flush() (experimental!)
• PagedCollections which load query results as the user scrolls (experimental!)
• Heaps of bug fixes!

Flextrine 0.9 is currently planned for release towards the end of February.

Its usually very easy to use RTMPT with the media server – for example, in Wowza you don’t have to do anything at all except connect using rtmpt:// instead of rtmp:// from your Flash application.

However, there is a potential problem; since Wowza (I will refer to Wowza from here on, but this should be applicable for all the media servers) is now running on port 80 it means that nothing else can run on port 80; and since Apache is likely to be running on port 80 that means its either Apache or Wowza, but not both.  Note that if you can get 2 IP addresses there is no problem; Apache runs on port 80 of one IP address and Wowza on port 80 of the other, and this is of course the ideal solution.  But there are cases when for technical or business reasons its simply not possible to get 2 IP addresses.

So here is the trick getting access to both Apache and Wowza on port 80 of a single IP address:

Leave Wowza running on port 1935, and Apache running on port 80 as normal.  Then:

1. In Apache enable mod_proxy and mod_proxy_http
2. In your <VirtualHost> configuration section of Apache add the following code.  This does not work in .htaccess

# Allow FMS to act as a reverse proxy for Wowza traffic over port 80

ProxyPass /open http://localhost:1935/open

ProxyPassReverse /open http://localhost:1935/open

ProxyPass /send http://localhost:1935/send

ProxyPassReverse /send http://localhost:1935/send

ProxyPass /idle http://localhost:1935/idle

ProxyPassReverse /idle http://localhost:1935/idle

ProxyPass /close http://localhost:1935/close

ProxyPassReverse /close http://localhost:1935/close

ProxyPass /fcs http://localhost:1935/fcs

ProxyPassReverse /fcs http://localhost:1935/fcs

<Proxy *:80>

    Order Allow,Deny

    Allow from all

</Proxy>

And that’s it!  It works because RTMPT always accesses URLs at /open, /send, /close, /idle or /fcs.  mod_proxy grabs these requests and forwards them onto Wowza on port 1935.  Note that if you have Wowza running on a different IP or URL just change localhost to wherever it is located.

The only thing to remember is that you can’t serve any pages from Apache at /open, /send, /close, /idle or /fcs.

Pick it up at www.flextrine.com

SPOILER ALERT (only if you are coming to Flash on the Beach) – here is a sneak preview of my slides for the presentation http://prezi.com/6vrft-2h4sjy/flextrine/

Functionally speaking things remain exactly the same, and we continue to approach our stable release alongside Doctrine 2.

The new version of Flextrine can be downloaded from www.flextrine.com.  Note that if you are upgrading from a previous version of Flextrine you will need to regenerate your AS3 entities.

My continued thanks to the community for their help in testing and using Flextrine!

I hope that this tutorial has given you some insight into the power of Flextrine.  In fact there are many areas of Flextrine that we didn’t touch on here including one to one and many to many associations, lazy loading, DQL, fetch joins, custom PHP functions and more – check the documentation for more details.

Both Flextrine and Doctrine 2 are currently in beta; the planned release date for both products is 1st September 2010 by which time I would hope to be able to confidently pronounce Flextrine as stable.  That’s where you come in!  If you find any issues in Flextrine please log them at http://code.google.com/p/flextrine2/issues/list and help me to make Flextrine the best Flex ORM library there is

Once an entity is in an EntityRepository (either because it was loaded from the database or it was persisted) it is known as a MANAGED entity.  This means that Flextrine will constantly watch the entity to see if anything changes, and if so will mark the entity for updating on the next flush().

Therefore updating entities is extremely simple – as long as the entity is managed there is literally nothing to do

Lets create an editor for the ContactGroups (in the same directory as Main.mxml):

ContactGroupEditor.mxml

   1: <?xml version="1.0" encoding="utf-8"?>

   2: <s:Group xmlns:fx="http://ns.adobe.com/mxml/2009"

   3:          xmlns:s="library://ns.adobe.com/flex/spark"

   4:          xmlns:mx="library://ns.adobe.com/flex/mx">

   5:     

   6:     <fx:Script>

   7:         <![CDATA[

   8:         import vo.ContactGroup;

   9:         

  10:         [Bindable]

  11:         public var contactGroup:ContactGroup;

  12:         

  13:         ]]>

  14:     </fx:Script>

  15:     

  16:     <mx:Form labelWidth="150" width="100%" height="100%">

  17:         

  18:         <mx:FormHeading label="Edit group" />

  19:         

  20:         <mx:FormItem label="Name">

  21:             <s:TextInput text="@{contactGroup.name}" />

  22:         </mx:FormItem>

  23:         

  24:     </mx:Form>

  25:     

  26: </s:Group>

The component takes a contactGroup and provides a TextInput that edits its name attribute using Flex 4 two-way databinding.  In fact you need to be careful with two-way databinding on some components (e.g. DateChooser) as it can cause unnecessary updates, but it works fine for Spark’s TextInput.

Now we need to add the ContactGroupEditor into Main.mxml:

   1: ...

   2: <s:VGroup width="100%" height="100%">

   3:             <!-- The editors -->

   4:             <local:ContactGroupEditor contactGroup="{tree.selectedItem as ContactGroup}" enabled="{tree.selectedItem is ContactGroup}" />

   5: ...

And that’s it for the group editor.  When we select a ContactGroup in the tree, the ContactGroupEditor becomes enabled, and the selected item is passed to the editor’s contactGroup attribute.  Flex updates the contactGroup’s name attribute when we change it in the editor and Flextrine automatically picks up on the change and marks the entity for updating.  On the next flush() the changes will be written to the database.

Now for the ContactEditor.

ContactEditor.mxml

   1: <?xml version="1.0" encoding="utf-8"?>

   2: <s:Group xmlns:fx="http://ns.adobe.com/mxml/2009"

   3:          xmlns:s="library://ns.adobe.com/flex/spark"

   4:          xmlns:mx="library://ns.adobe.com/flex/mx">

   5:     

   6:     <fx:Script>

   7:         <![CDATA[

   8:         import org.davekeen.flextrine.orm.EntityManager;

   9:         import vo.ContactGroup;

  10:         import vo.Contact;

  11:         

  12:         [Bindable]

  13:         public var contact:Contact;

  14:         

  15:         ]]>

  16:     </fx:Script>

  17:     

  18:     <mx:Form labelWidth="150" width="100%" height="100%">

  19:         

  20:         <mx:FormHeading label="Edit contact" />

  21:         

  22:         <mx:FormItem label="Name">

  23:             <s:TextInput text="@{contact.name}" />

  24:         </mx:FormItem>

  25:         

  26:         <mx:FormItem label="Telephone number">

  27:             <s:TextInput text="@{contact.telephoneNumber}" />

  28:         </mx:FormItem>

  29:         

  30:         <mx:FormItem label="Birthday">

  31:             <mx:DateChooser selectedDate="{contact.birthday}" change="contact.birthday = event.currentTarget.selectedDate" />

  32:         </mx:FormItem>

  33:         

  34:         <mx:FormItem label="Group">

  35:             <s:DropDownList dataProvider="{EntityManager.getInstance().getRepository(ContactGroup).entities}"

  36:                             selectedItem="{contact.contactGroup}"

  37:                             change="contact.setContactGroup(event.currentTarget.selectedItem);"

  38:                             labelField="name" />

  39:         </mx:FormItem>

  40:         

  41:     </mx:Form>

  42:     

  43: </s:Group>

The contact editor is marginally more complicated, but still fairly simple.  A few points:

• Note is that as mentioned above we don’t use two-way databinding on any component apart from TextInput.
• Although it is perfectly legal to retrieve the singleton EntityManager in the ContactEditor as we have done in the DropDownList dataProvider, in a real application we probably wouldn’t do this as it breaks encapsulation.  I’ve done it here for the sake of simplicity

Finally we need to add the editor to Main.mxml:

   1: ...

   2:  

   3: <s:VGroup width="100%" height="100%">

   4:     <!-- The editors -->

   5:     <local:ContactGroupEditor contactGroup="{tree.selectedItem as ContactGroup}" enabled="{tree.selectedItem is ContactGroup}" />

   6:     <mx:HRule width="100%" />

   7:     <local:ContactEditor contact="{tree.selectedItem as Contact}" enabled="{tree.selectedItem is Contact}" />

   8: ...

An that’s it!  A simple but fully functioning, database aware Flex application.

And now, the thrilling conclusion.