7:00 – 4:30 – VISIBILITY

• Deployed my new copy, which works fine, though it has one diagnostic print statement in it. Need to fix that
• Fixed the bugs, and added move capability. The executable looks at the name it was called when executed and adjusts its behavior. If the file is called cpPlusDate, it will copy. If it’s called mvPlusDate, it will move. Uploaded the files to my ftp site (since we still need CDs!), to deploy on Monday. Also committed to subversion.
• Looking at ways to have a user build a form online and then use it.
  • Read the xml on the server side and have it compiled (http://livedocs.adobe.com/flex/3/html/help.html?content=apache_3.html). This doesn’t allow for graphical creation of the component though.
  • Serialize as xml:
    • http://stackoverflow.com/questions/270046/flex-xml-serialization-and-de-serialization-of-nested-object-structures
    • http://cookbooks.adobe.com/post_Serializing_object_to_XML-11988.html
  • Serialize the top level object using the ByteArray class (http://www.kylehayes.info/2008/01/06/Persisting-an-ActionScript-Data-Model/). This would need the following:
    • A container class that knows how to read and write a serialized object to the server
    • That the app exist entirely inside the above container.
    • The question is – will this store the entire hierarchy under that object in a way that will work later?
  • I like this better because it has the ability to graphically lay out the form. There would be two fundamental types of containers – an Authoring container and a Player container. The authoring container would have the code to lay out the form (and set up the tables on the server?). The player would simply load and show. Aaaaaaaaaaand it doesn’t work. Turns out not all the data for a display object gets stored this way. Seems to only work for value objects.
  • Trying out FlexXB. Changed the compiler options to preserve meta data
  • Set up my path so that the mxmlc compiler can be reached from the command line