Someone suggested that with so much happening in the Flash world at the moment I should talk about the future direction of XPComponents.
This basically means talking about Flux!
Flux is the code name for a project we are currently working on.
Flux stands for a FLash User interface defined in Xml.
Might sound similar to Flex, I mean that’s Flash and XML right? True, they are similar products but I would describe them as siblings i.e. related but not competitors. Flux differs most significantly from Flex in that Flux is compiled at run time whereas Flex is compiled at author time, additionally all code behind in Flux is contained in actionscript class files not in scriptlets in the XML. I see both approaches as having there advantages and disadvantages, some situations will be best suited to Flex but I believabe others will be better served by Flux, I don't really see that there will be much overlap.
A typical Flux application consist of several precompiled libraries containing the XP3 component framework, plus your application specific code library and an xml file containing the definition of the overall application structure and screen definitions.
It will be possible for an application to be made up of more than one custom library/XML i.e. to have a Form or a group of Forms in a separate library and a separate XML file so that it will be possible to share Forms across different applications without needing to have the Form compiled into your application.
Much of the power of Flux comes from leverageing the existing capabilities of the XP3 framework with its layout managers, data binding, forms and application architecture.
The typical workflow that we imagine with Flux will be to create your application class files in Eclipse (i.e. ASDT, Zorn, or PowerFlasher), at the same time define your UI in XML, then compile your actionscript using MTASC, copy the compiled files plus XML to server and run.
The idea is basically similar to how you would handle a JSP or HTML application today, the interface is defined in an xml file then rendered at run time when a form is requested. Your own code behind will then exist in a compiled library and will be loaded and associated with the interface as it is rendered. The XML file will be modifiable after the application is compiled i.e. after being deployed, making simple layout changes trivial.
The foot print of Flux applications is generally very small, each Form will only be a few kb maybe in the region of 1 or 2 kb (obviously dependent on the amount of code you write) plus a few hundred bytes for the xml UI definition. The XP3 system libraries obviously are larger than this but then they will be cached on the client so they will only be needed to download once rather than with every application or Form.
Ultimately we hope to have a Flux Form designer that can be integrated with Eclipse though this currently has a low priority and wont be in Flux 1.0 .
Flux is currently under development, we don’t yet have a planned launch date but it will probably be sometime in October.
XPComponents will still continue to be targeted at both Flash IDE and Eclipse development, Flux will probably be sold as an add-on product that will targeted primarily for Eclipse based development.
For anyone interested in XPCharting, we have plans for substantial development of the charting package once we get our hands on Flash8. We are hoping that the improved graphic capabilities of Flash8 will provide the basis for major enhancements particular in user interactivity as well as improved rendering making more complex charts practical.
Tuesday, August 23, 2005
Thursday, August 18, 2005
Excluding AS2 Classes
Recently I have been looking at how to exclude classes from a swf as part of a strategy for constructing large multi-swf RIA where core classes are loaded in as a common shared library at run time and then individual forms are loaded on demand.
Flash 7 introduced the "exclude.xml" as a way to achieve this.
To exclude classes from compilation, create a specially named and formatted XML file and place it in the same directory as the FLA file. Name the XML file FLA_filename_exclude.xml, where FLA_filename is the name of your FLA file minus the extension. For example, if your FLA file is sellStocks.fla, the XML filename must be sellStocks_exclude.xml.
Place the following tags in the XML file:
<excludeAssets>
<asset name="className1"></asset>
<asset name="className2"></asset>
...
</excludeAssets>
The values you specify for the name attributes in the tags are the names of classes you want to exclude from the SWF file. For example, the following XML file excludes the mx.core.UIObject and mx.screens.Slide classes from the SWF file:
<excludeAssets>
<asset name="mx.core.UIObject"></asset>
<asset name="mx.screens.Slide"></asset>
</excludeAssets>
Ok so this does work but the problem is it does not work properly, there are still classes that get compiled into the swf.
I was pointed to this article by Darron Schall which did provide useful information.
However in one case after several hours work to rework a class so that it would be excluded I was pleased to see it worked and the class was excluded, however the swf footprint went up, I was wondering what was going on!
Well after poking around inside the swf using ASV I saw that though the target class was not there several other classes had now been included. These were unrelated to any changes I had been making.
So at this point I decided to go back to basics and try and look at some very simple cases to see what was really happening.
I created a swf with no assets but with some code that directly referenced half a dozen classes. Without the exclude file the swf was 54k, with the exclude file it was 159bytes, good so far!
I then created another swf with a particular component and with the exlude file it was 7k which was all made up of graphical elements in the component. Again, good so far.
So now what happens if I combine these two files?
Well at worst case the size should be simply the two individual file sizes added together, however if the two files shared some classes you might expect the total size might reduce.
So what did happen?
The resultant swf was 35k, why???
Using ASV I can see a whole bunch of additional classes were being included.
I cant see any logic to explain this behavior.
But thats not the end of the story, taking this 35k swf I added additional components and placed them on the stage.
Again logic says the swf size would stay the same or increase depending on the overlap of the classes needed but what happened was the swf decreased in size to 21k.
At this point I give up further testing, although using an exlude file does have a very significant effect and certainly becomes an essential part of the strategy for developing larger RIA's there is no way to predict its impact or plan the class structure to achieve the smallest size swf. Just to be clear, from my own testing on the average form I can achieve reduction in size ranging from 50% up to 80% using the exclude file but whatever reduction you do initially get there isn't anything you can do to tweek it to get the remaining classes excluded.
It would be nice to think that this might be sorted out in Flash8 but it has already been said that little has changed in Flash 8 related to actionscript and anyway MM's focus is moving away from Flash so I guess this might become a feature of Zom.
I should note in this respect that MTASC also supports an exclude file, though it uses a different format, from testing it was accurate and consistant in excluding files.
In fact we are currently using MTASC to build the core shared component library as it is able to achieve a significantly smaller footprint than the same built from the Flash IDE.
Flash 7 introduced the "exclude.xml" as a way to achieve this.
To exclude classes from compilation, create a specially named and formatted XML file and place it in the same directory as the FLA file. Name the XML file FLA_filename_exclude.xml, where FLA_filename is the name of your FLA file minus the extension. For example, if your FLA file is sellStocks.fla, the XML filename must be sellStocks_exclude.xml.
Place the following tags in the XML file:
<excludeAssets>
<asset name="className1"></asset>
<asset name="className2"></asset>
...
</excludeAssets>
The values you specify for the name attributes in the
<excludeAssets>
<asset name="mx.core.UIObject"></asset>
<asset name="mx.screens.Slide"></asset>
</excludeAssets>
Ok so this does work but the problem is it does not work properly, there are still classes that get compiled into the swf.
I was pointed to this article by Darron Schall which did provide useful information.
However in one case after several hours work to rework a class so that it would be excluded I was pleased to see it worked and the class was excluded, however the swf footprint went up, I was wondering what was going on!
Well after poking around inside the swf using ASV I saw that though the target class was not there several other classes had now been included. These were unrelated to any changes I had been making.
So at this point I decided to go back to basics and try and look at some very simple cases to see what was really happening.
I created a swf with no assets but with some code that directly referenced half a dozen classes. Without the exclude file the swf was 54k, with the exclude file it was 159bytes, good so far!
I then created another swf with a particular component and with the exlude file it was 7k which was all made up of graphical elements in the component. Again, good so far.
So now what happens if I combine these two files?
Well at worst case the size should be simply the two individual file sizes added together, however if the two files shared some classes you might expect the total size might reduce.
So what did happen?
The resultant swf was 35k, why???
Using ASV I can see a whole bunch of additional classes were being included.
I cant see any logic to explain this behavior.
But thats not the end of the story, taking this 35k swf I added additional components and placed them on the stage.
Again logic says the swf size would stay the same or increase depending on the overlap of the classes needed but what happened was the swf decreased in size to 21k.
At this point I give up further testing, although using an exlude file does have a very significant effect and certainly becomes an essential part of the strategy for developing larger RIA's there is no way to predict its impact or plan the class structure to achieve the smallest size swf. Just to be clear, from my own testing on the average form I can achieve reduction in size ranging from 50% up to 80% using the exclude file but whatever reduction you do initially get there isn't anything you can do to tweek it to get the remaining classes excluded.
It would be nice to think that this might be sorted out in Flash8 but it has already been said that little has changed in Flash 8 related to actionscript and anyway MM's focus is moving away from Flash so I guess this might become a feature of Zom.
I should note in this respect that MTASC also supports an exclude file, though it uses a different format, from testing it was accurate and consistant in excluding files.
In fact we are currently using MTASC to build the core shared component library as it is able to achieve a significantly smaller footprint than the same built from the Flash IDE.
Friday, August 12, 2005
New Flash 8 Player Security
Someone on Flashcoders today mentioned that one of our demos crashed under FP8, so I installed FP8 to check it out.
Whilst checking into the issue I ran the application from my local PC and came face to face with the new security features of FP8 from a user perspective.
All I can say is I hope it is improved by the time it is released.
The application basically links to our site and downloads an XML document and some jpg's.
First I got the message box saying that a potentially dangerous thing had been stopped and I needed to click settings if I wanted it to go ahead, fine so far. Bit to long a delay while it fires open a new browser and heads of to the MM site to show the security setting screen but ok if this is really unavoidable. Once there it took me a while to realise that I needed to add the url of our server as a trusted location and restart but OK got that done.
On restart I get the same message, again go to MM site, so maybe I got the wrong url, so I enter another of our servers url's as trusted and restart.
and again... and again... didnt matter what I put in it wasn't what FP8 needed.
So in the end I just clicked the option to say just trust everybody..
Thats fixed it..
Now this may be just a beta issue, but a suggestion here.
When you go to the security page why not tell me what the url the application was trying to access was and then just give me the option to say "OK that one is good" 'cos in reality no user is going to actually enter trusted sites it will be "all" or "nothing" unless you give them something to click.
Whilst checking into the issue I ran the application from my local PC and came face to face with the new security features of FP8 from a user perspective.
All I can say is I hope it is improved by the time it is released.
The application basically links to our site and downloads an XML document and some jpg's.
First I got the message box saying that a potentially dangerous thing had been stopped and I needed to click settings if I wanted it to go ahead, fine so far. Bit to long a delay while it fires open a new browser and heads of to the MM site to show the security setting screen but ok if this is really unavoidable. Once there it took me a while to realise that I needed to add the url of our server as a trusted location and restart but OK got that done.
On restart I get the same message, again go to MM site, so maybe I got the wrong url, so I enter another of our servers url's as trusted and restart.
and again... and again... didnt matter what I put in it wasn't what FP8 needed.
So in the end I just clicked the option to say just trust everybody..
Thats fixed it..
Now this may be just a beta issue, but a suggestion here.
When you go to the security page why not tell me what the url the application was trying to access was and then just give me the option to say "OK that one is good" 'cos in reality no user is going to actually enter trusted sites it will be "all" or "nothing" unless you give them something to click.
Flash 8 IDE
Its been over 5 months since I last got round to blogging, we�ve been heads down working on XP3 the next generation of the XPComponent framework but now its out the door our heads are coming back up. I will try to highlight some of the new features in XP3 in future posts but for now Flash 8!
So Flash 8 is announced, some great new features for sure, but I was somewhat disappointed in what wasn�t there.
I read this blog by g.wygonik and I agree with what is being said not so much from the aspect of particular features discussed but about development of the IDE in general.
Mike Downey has made several comments on the subject which I feel are very significant and are worth highlighting.
Let me summarise:
People wont use the Flash editor even if we improved it
People want other things improved
Flash is not for application development Flex is
Mike does say that this doesn�t mean that they are never going to improve the editor/IDE but to be honest that comment doesn�t make a whole lot of sense. If the facts as stated are true then how are you ever going to justify the resources needed to improve the IDE to match that of other similar products (IDEs - Delphi, VisualStudio, Editors-Eclipse,SEPY) particularly when in 2 years (or whenever F9 is out) the IDE will be even further behind the alternatives and the mountain will have become even steeper and higher.
Mike somewhat dismisses the rant about missing features by saying don�t get upset if your own personal favorite feature is not in Flash 8, but I think that is unfair the rant is not so much about one persons favorite feature but about lack of development in general of the IDE stretching back over several generations of Flash.
If we now have to wait until Flash9 to see any improvements that�s a long ways off and I cant see things changing then anyway. We have put resources, time and money with the aim of developing jsfl tools and wizards for use with our components in the IDE, our belief was that a visual IDE was an important element in creating Flash applications and a good IDE is a major productivity benefit to a language (just look at the Delphi IDE) and that someday soon the Flash IDE would be at least brought into the ballpark of VisualStudio (not the greatest IDE by any means ) but I realize now this is just not going to happen. The decision has been made and clearly Macromedia are following a different path.
So as a company focused on RIA�s or supporting developers who create RIA�s I have to take this on board. I shouldn�t be using the IDE to create applications and instead I should use Eclipse. So today I downloaded Eclipse, although we do do a lot of Java development we are not Eclipse users (we use JCreator) so it was something new (also makes me wonder how many MS shops were in MM�s survey group �cos I don�t know of many who use Eclipse) .
I don�t really have a problem with Eclipse but I will say if I am using Eclipse to write my code for sure I am going to use MTASC to compile it. Its just a natural fit and it seems that everyone else has the same idea.
I may be gaining in productivity using Eclipse/MTASC as I don�t spend half my day waiting for a recompile or needing to restart Flash after a crash but its not a visual IDE and in some areas my productivity is going to suffer.
One of the cool things with MTASC. is I can already build Flash8 swf�s even before the release of Flash8.
The question I find myself asking is why would I now want to upgrade to Flash 8? It has nothing to offer me that I don�t already have, and it sounds like its unlikely to have anything for the foreseeable future either.
Its a shame really a good visual IDE is a major productivity boost, Delphi has it, VB has it, others have it, Flash on the other hand doesn�t and seems to be giving up but there is no point in trying to fight lost battles so over time XPComponents will shift its focus away from the Flash IDE towards Eclipse and MTASC as the target development enviroment as MM suggest and so expect to see a lot more from us in this area in the future.
So Flash 8 is announced, some great new features for sure, but I was somewhat disappointed in what wasn�t there.
I read this blog by g.wygonik and I agree with what is being said not so much from the aspect of particular features discussed but about development of the IDE in general.
Mike Downey has made several comments on the subject which I feel are very significant and are worth highlighting.
We haven�t done any major code-editing improvements for hand coders as we found that almost all of the hand coders that we interviewed preferred to choose their own text editor. Even if we had added all of the features of an editor like PrimalScript or Eclipse (which would have been far too much work for a single cycle) users told us that they would still use their own editors. So we decided to focus on other things instead
We met with customers all over the world who represent every key segment of the Flash user base (solo devs, creative agencies, educators, enterprise shops, etc) and found that, overwhelmingly, everyone had a different idea of what features a good text editor should have and - even more so - were very attached to their existing text editor solutions.
The number of Flash users who are advanced hand coders and would be willing to give up their text editor to go back into Flash was far too small when compared to the greater base of Flash customers.
In the case of Flash 8, users made it clear that code editor enhancements like the ones mentioned in this thread were important - but not as important as the other things that we did.
We developed Flex because Flash authoring was never going to fit the traditional application developer market (Java/C++/.NET/etc) so we needed to do something new. Flex is not a replacement for Flash, it�s a new solution targetted at a completely different market
Let me summarise:
Mike does say that this doesn�t mean that they are never going to improve the editor/IDE but to be honest that comment doesn�t make a whole lot of sense. If the facts as stated are true then how are you ever going to justify the resources needed to improve the IDE to match that of other similar products (IDEs - Delphi, VisualStudio, Editors-Eclipse,SEPY) particularly when in 2 years (or whenever F9 is out) the IDE will be even further behind the alternatives and the mountain will have become even steeper and higher.
Mike somewhat dismisses the rant about missing features by saying don�t get upset if your own personal favorite feature is not in Flash 8, but I think that is unfair the rant is not so much about one persons favorite feature but about lack of development in general of the IDE stretching back over several generations of Flash.
If we now have to wait until Flash9 to see any improvements that�s a long ways off and I cant see things changing then anyway. We have put resources, time and money with the aim of developing jsfl tools and wizards for use with our components in the IDE, our belief was that a visual IDE was an important element in creating Flash applications and a good IDE is a major productivity benefit to a language (just look at the Delphi IDE) and that someday soon the Flash IDE would be at least brought into the ballpark of VisualStudio (not the greatest IDE by any means ) but I realize now this is just not going to happen. The decision has been made and clearly Macromedia are following a different path.
So as a company focused on RIA�s or supporting developers who create RIA�s I have to take this on board. I shouldn�t be using the IDE to create applications and instead I should use Eclipse. So today I downloaded Eclipse, although we do do a lot of Java development we are not Eclipse users (we use JCreator) so it was something new (also makes me wonder how many MS shops were in MM�s survey group �cos I don�t know of many who use Eclipse) .
I don�t really have a problem with Eclipse but I will say if I am using Eclipse to write my code for sure I am going to use MTASC to compile it. Its just a natural fit and it seems that everyone else has the same idea.
I may be gaining in productivity using Eclipse/MTASC as I don�t spend half my day waiting for a recompile or needing to restart Flash after a crash but its not a visual IDE and in some areas my productivity is going to suffer.
One of the cool things with MTASC. is I can already build Flash8 swf�s even before the release of Flash8.
The question I find myself asking is why would I now want to upgrade to Flash 8? It has nothing to offer me that I don�t already have, and it sounds like its unlikely to have anything for the foreseeable future either.
Its a shame really a good visual IDE is a major productivity boost, Delphi has it, VB has it, others have it, Flash on the other hand doesn�t and seems to be giving up but there is no point in trying to fight lost battles so over time XPComponents will shift its focus away from the Flash IDE towards Eclipse and MTASC as the target development enviroment as MM suggest and so expect to see a lot more from us in this area in the future.
Tuesday, June 14, 2005
XP3 whats new part 1 - DataBinding
XP3, the third generation of XPComponents, will be released in a few days and people have been asking what is new in this release so this is the start of taking a look at some of the changes.
XP3 represents an evolutionary rather than revolutionary change although we have taken the opportunity to review the whole architecture and refine it.
DataBinding
A lot of work has been done in the data binding area.
DataSources in XPComponents are somewhat the equivalent of DataProviders and we provide a number of different types.
The basic DataSource which exposes a single data object (think of the equivalent of the data model for an html input form), ListDataSource which encapsulates an array of objects and XMLDataSource which represents an array of XMLNodes.
The XMLDataSource allows you to display and manipulate XML documents in a DataGrid or other controls whilst retaining the data in its orginal native XML format.
However if you wish to translate your source xml into native objects once it has been downloaded, we also provide the RecordsetDecoder and NodeListDecoder, which will automatically convert xml nodes into native objects. Both of these classes generate there own internal schema for a document to enable them to convert objects back into xml at some later point if you wish. These classes are both built on the new ArrayProxy class which provides support for "lazy" decoding.
All datasources provide built in support for inserts, updates and deletes with various validation events to prevent invalid being committed, these work in hand with the XPDataGrid's row based editor to prevent you moving to another row in the grid whilst data is not valid. We also track all changes that are made to the data to enable you to easily update the server appropriately.
An important new feature is the DataRelation, data relations provide built in support for master/detail or parent/child relationships between datasources in the client. So for example if you have a invoice(master) datasource and an invoiceitems(detail) datasource moving the master record will automatically cause the detail records to be filtered to expose only the related records without any code required.
The DataRelation also provides support during editing. It will block any attempt to move the master recordset whilst a child record is being edited unless that record can be sucessfully validated.
This enables you to quickly setup some quite complex and sophisticated structures on the client.
We also provide a number of connectors to handle communication with the server covering CSV, XML, remoting, web services and others.
XP3 represents an evolutionary rather than revolutionary change although we have taken the opportunity to review the whole architecture and refine it.
DataBinding
A lot of work has been done in the data binding area.
DataSources in XPComponents are somewhat the equivalent of DataProviders and we provide a number of different types.
The basic DataSource which exposes a single data object (think of the equivalent of the data model for an html input form), ListDataSource which encapsulates an array of objects and XMLDataSource which represents an array of XMLNodes.
The XMLDataSource allows you to display and manipulate XML documents in a DataGrid or other controls whilst retaining the data in its orginal native XML format.
However if you wish to translate your source xml into native objects once it has been downloaded, we also provide the RecordsetDecoder and NodeListDecoder, which will automatically convert xml nodes into native objects. Both of these classes generate there own internal schema for a document to enable them to convert objects back into xml at some later point if you wish. These classes are both built on the new ArrayProxy class which provides support for "lazy" decoding.
All datasources provide built in support for inserts, updates and deletes with various validation events to prevent invalid being committed, these work in hand with the XPDataGrid's row based editor to prevent you moving to another row in the grid whilst data is not valid. We also track all changes that are made to the data to enable you to easily update the server appropriately.
An important new feature is the DataRelation, data relations provide built in support for master/detail or parent/child relationships between datasources in the client. So for example if you have a invoice(master) datasource and an invoiceitems(detail) datasource moving the master record will automatically cause the detail records to be filtered to expose only the related records without any code required.
The DataRelation also provides support during editing. It will block any attempt to move the master recordset whilst a child record is being edited unless that record can be sucessfully validated.
This enables you to quickly setup some quite complex and sophisticated structures on the client.
We also provide a number of connectors to handle communication with the server covering CSV, XML, remoting, web services and others.
Thursday, February 17, 2005
Flashcoders down again.....
Dont know whats up with Flashcoders these days.
This is the second time in a week that its been down, and when it goes down it goes down for days on end (2 days already this time).....
What with all the problems with searching the archives after the recent service upgrade, makes you wonder whats up.
I know its a free service so one should try to support not complain but I regard it as an important business resource, its format as a mailing list makes it vastly more valuable than web forum based sites.
So if there is an underlying issue maybe the community as a whole needs to address it before we all lose an important resource.
And just to make it very clear... Thanks! to the guys who do provide FlashCoders, whoever you are, my frustration is only becuase youve made it so good its a pain not have it around..
This is the second time in a week that its been down, and when it goes down it goes down for days on end (2 days already this time).....
What with all the problems with searching the archives after the recent service upgrade, makes you wonder whats up.
I know its a free service so one should try to support not complain but I regard it as an important business resource, its format as a mailing list makes it vastly more valuable than web forum based sites.
So if there is an underlying issue maybe the community as a whole needs to address it before we all lose an important resource.
And just to make it very clear... Thanks! to the guys who do provide FlashCoders, whoever you are, my frustration is only becuase youve made it so good its a pain not have it around..
Wednesday, February 16, 2005
Property getter/setters in MX2004 and the Component Inspector
Properties in MX2004 highlight how Flash uniquely occupies a space somewhere in between the Windows centric world and the Java centric world.
In Windows style a property is used just like a variable
var x = myComp.myCustomProperty;
myComp.myCustomProperty=x
and are declared using the get/set keywords
function get myCustomProperty():Number{ return __myCustomProperty; }
However in the Java world we use get/set methods
var x = myComp.getMyCustomProperty();
myComp.setMyCustomProperty(x);
and declared like this
function getMyCustomProperty():Number{ return __myCustomProperty; }
So what's the big deal you ask, so Flash just lets you use either style, so isn't that a good thing?
Well, yes if it did in fact let you freely use both styles, but it doesn't!
You see if you want to expose that property in the Component Inspector you can only do that using the implicit get/set style but on the other hand if you want to define your property in an interface you can only do that using the getter/setter methods.
So that's a problem. You can't create a property that works in both the Inspector and an Interface.
So how can we work around it? If you look at the MM Source Code you will find the only answer is to simply code both style of property getter/setters.
At a minimum this is inefficient coding, adds to the bloat of components and is more code to debug.
I hope this will be resolved in the next version of Flash, preferably by making the Java style getter/setters work with the ComponentInspector or by allowing properties in interface definitions.
Whilst talking about the ComponentInspector, I must say this is something that really needs improving a lot in the next version of Flash.
In MX2004 it can be said to be a good first effort but it is still years behind component inspectors common in other products.
Features I would like to see are:
1) Custom Property Editors - Create a property editor using JSFL and assign that editor as a handler for particular properties of a component. Currently you can have a component wizard but that is a poor alternative. Users expect to be able to click a property to edit it not search somewhere else for a wizard.
2) Custom Class properties - The Collection property introduced a custom class property but only in the context of a collection, we need the same thing but for single properties. Currently you can have an "Object" property but this is very limited, has many inherent limitations and only produces a generic object not a typed class. It also needs to allow this class property to be null.
3) More efficient code generation - Currently Flash generates setter code for all exposed variable, it also requires you to set a default value in the metadata. If a property is still at its default value Flash still generates code to "set" its value. Code that commonly duplicates you own component internal code that sets the default value. The IDE should be smart enough to NOT generate code if a property is using its default value. This is particularly an issue as the IDE generates the code per instance whereas your own internal code is per class. If you have many properties at there default value this can result in a sizable proportion of the movie footprint be taken up by unnecessary code. The current approach only works as long as you only expose a few properties in the IDE (as MM do) but then what's the point of the inspector if you are not going to use it.
It becomes a major issue if you say expose 20/30 properties per component and have maybe 100+ component in an application, that�s an awfull lot of "dead" code being injected into you movie.
4) Allow null values - Currently properties MUST have a value, there isn't a way to have a null value. This is particularly relevant to Object type properties where you currently you need a second Boolean property to indicate "nullness".
5) Improve code generation for Collection properties - Collections properties generate a lot of code, that�s particularly an issue as the IDE generates the code even if the collection is empty. Again the IDE code is per instance whereas your own code is per class which makes collection properties currently impracticable for general use limiting them to special cases and only in components that will only have a few instances per application.
I know this probably isn't the most popular improvement and many may not see the reason why we rate it so highly, but what we are looking to do is to enable you to work more efficiently through providing you with components that are both easier to use and more powerful, in other words a strong foundation will enable you to build better applications.
We believe strongly that a good powerful visual editor is the key to making Flash more usuable as a development enviroment rather than just a "nice" add on. Its also why we prefer to see the IDE improve than resort to third party tools.
In Windows style a property is used just like a variable
var x = myComp.myCustomProperty;
myComp.myCustomProperty=x
and are declared using the get/set keywords
function get myCustomProperty():Number{ return __myCustomProperty; }
However in the Java world we use get/set methods
var x = myComp.getMyCustomProperty();
myComp.setMyCustomProperty(x);
and declared like this
function getMyCustomProperty():Number{ return __myCustomProperty; }
So what's the big deal you ask, so Flash just lets you use either style, so isn't that a good thing?
Well, yes if it did in fact let you freely use both styles, but it doesn't!
You see if you want to expose that property in the Component Inspector you can only do that using the implicit get/set style but on the other hand if you want to define your property in an interface you can only do that using the getter/setter methods.
So that's a problem. You can't create a property that works in both the Inspector and an Interface.
So how can we work around it? If you look at the MM Source Code you will find the only answer is to simply code both style of property getter/setters.
At a minimum this is inefficient coding, adds to the bloat of components and is more code to debug.
I hope this will be resolved in the next version of Flash, preferably by making the Java style getter/setters work with the ComponentInspector or by allowing properties in interface definitions.
Whilst talking about the ComponentInspector, I must say this is something that really needs improving a lot in the next version of Flash.
In MX2004 it can be said to be a good first effort but it is still years behind component inspectors common in other products.
Features I would like to see are:
1) Custom Property Editors - Create a property editor using JSFL and assign that editor as a handler for particular properties of a component. Currently you can have a component wizard but that is a poor alternative. Users expect to be able to click a property to edit it not search somewhere else for a wizard.
2) Custom Class properties - The Collection property introduced a custom class property but only in the context of a collection, we need the same thing but for single properties. Currently you can have an "Object" property but this is very limited, has many inherent limitations and only produces a generic object not a typed class. It also needs to allow this class property to be null.
3) More efficient code generation - Currently Flash generates setter code for all exposed variable, it also requires you to set a default value in the metadata. If a property is still at its default value Flash still generates code to "set" its value. Code that commonly duplicates you own component internal code that sets the default value. The IDE should be smart enough to NOT generate code if a property is using its default value. This is particularly an issue as the IDE generates the code per instance whereas your own internal code is per class. If you have many properties at there default value this can result in a sizable proportion of the movie footprint be taken up by unnecessary code. The current approach only works as long as you only expose a few properties in the IDE (as MM do) but then what's the point of the inspector if you are not going to use it.
It becomes a major issue if you say expose 20/30 properties per component and have maybe 100+ component in an application, that�s an awfull lot of "dead" code being injected into you movie.
4) Allow null values - Currently properties MUST have a value, there isn't a way to have a null value. This is particularly relevant to Object type properties where you currently you need a second Boolean property to indicate "nullness".
5) Improve code generation for Collection properties - Collections properties generate a lot of code, that�s particularly an issue as the IDE generates the code even if the collection is empty. Again the IDE code is per instance whereas your own code is per class which makes collection properties currently impracticable for general use limiting them to special cases and only in components that will only have a few instances per application.
I know this probably isn't the most popular improvement and many may not see the reason why we rate it so highly, but what we are looking to do is to enable you to work more efficiently through providing you with components that are both easier to use and more powerful, in other words a strong foundation will enable you to build better applications.
We believe strongly that a good powerful visual editor is the key to making Flash more usuable as a development enviroment rather than just a "nice" add on. Its also why we prefer to see the IDE improve than resort to third party tools.
Subscribe to:
Posts (Atom)