flex tips


The entire OLAP package in Flex has sparse API documentation, but there are several ‘how-to’ examples out in the land of live-docs. This usually doesn’t bode well, because it generally means a tech-writer never talked to the development team to figure out what all the dependencies are on the various properties. We have the source, but chasing it down ourselves sucks.

 

A precursor into what doesn’t work:

  • OLAPAttribute.displayName does NOT work on subsequent dimensions. It will only work on your first dimension which is usually the ROW_AXIS. However, the OLAPLevel.attributeName will always expect to look up the OLAPAttribute.name.
  • The allMemberName even though it’s defined on the OLAPHierarchy, it must be actually set on an OLAPAttribute which is displayed for that dimension.

Now onto the real problem:

Generally to sort your cube, you do a 2-dimensional sort to the original flat dataprovider then assign this to the cube dataprovider.  And in most cases this seems to work OK, until your CATEGORY_AXIS is based on anything to do with Time (which is a lot of the time actually). In most cases you’ll have a two-tier hierarchy of year and month / quarter, but the problem appears to be most prevalent with months. Even though your original source is sorted correctly, some months will be placed out of order, especially if you’re using the allMember level which it builds on the fly in the query.

The Fix:

So the fix involves re-arranging the member IList in building the OLAPQuery to the appropriate OLAPSet. In addition to fixing the sort issue, now is the time to re-arrange the allMember level to where it seems logical for your application. Accounting applications generally read left-to-right, so summary total’s are generally shown on the right hand side.

The way know if you’re working with the allMember level that it created for you in the sort method, is to look for the OLAPMember.hierarchy.allMemberName and compare that to the current OLAPMember.name

The way to correctly resort months involves a bit of kludgery but I haven’t found a more elegant way around it. In the OLAPAttribute for the dimension you specify the dataField to the integer of the month (generally this is string from a formatter), and assign a displayNameFunction to use a DateFormatter to turn this into something meaningful at the UI level. Even though the name of the OLAPMember is a string, it’s actually a string cast of the original value to the dataField (hence the actual integer value). You can then re-cast this back to an int to do a numeric sort (so you don’t end up with 0, 1, 10, 11, 2, 3, etc).

Now you might think an easier way to do this is to just use a SortField, however since you’re original Object is transformed to a flash_proxy and lost in the process relative to the OLAPGrid, the internal numeric sort method to Sort will throw an error that it can’t find the property that you originally wanted to sort on (eg month).

This should get your columns back in the order in which they were meant to be in.

private function getQuery(cube:IOLAPCube):IOLAPQuery
{
… //Setup the rest of the dimensions / sets to associate to the correct axis

var list:ArrayCollection = cube.findDimension(“timeDimension”).findAttribute(“Month”).members as ArrayCollection;
list.sort = new Sort();
list.sort.compareFunction = compareSortMonth;
list.refresh();

var moSet:OLAPSet = new OLAPSet();
moSet.addElements(list);

private function compareSortMonth(a:OLAPMember, b:OLAPMember, fields:Array = null):int
{
if (a.name == a.hierarchy.allMemberName) return 1;
else if (b.name == b.hierarchy.allMemberName) return -1;

var aMonth:int = parseInt(a.name);
var bMonth:int = parseInt(b.name);

if (aMonth < bMonth) return -1;
else if (bMonth < aMonth) return 1;
else return 0;
}

There is probably only a handful of things that are probably less understood at the SDK level as to how just exactly the Drag-Drop event sequence is generated, captured, and handled. First off, the UIComponent is the one where events can be registered but does absolutely nothing about dispatching or even ‘psuedo-dispatching’ through an intermediary.

 

Not In Here:

Case is point – we all know about the DragManager, and how you have to enable certain targets to allow the capture sequence to generate events for the final drop event, however it’s really the SystemManager that handles a bunch of marshalling for you – since it sits at the near root level it knows about MouseEvents for just about every object.

It’s this ferrying back and forth between the InterManagerRequest.DRAG_MANAGER_REQUEST event between the DragManager and ultimately passed through the Implementor (ie DragManagerImpl), and the SystemManager, is what creates the DragEvent to eventually be fired via the DragProxy. This is why the documentation says it is important to trigger the allowDragDrop method from within the DragEvent.ENTER event – because the target is then assigned directly to the proxy instance.

(more…)

The design detail:
You want to be able to create item renderers in a list that apply different styles depending on different visual cues or the data itself. For example lets take the TSA’s security approach with colors – the text changes for each level of severity.

The problem:
The problem is in handling the default case where every item renderer style should be the same, in the protected method of makeRowsAndColumns():Point After the itemrenderer instance has been created it’s styleName is set to the listContent container. This is important because no amount of setting through the ClassFactory properties, or setting styles anywhere in the pre-construction phase will save these unique values since it’s reset after it’s created.

The solution:
The one I came up with overrides the actual styleName property itself, where with a bit of checking we can safely ignore only the request coming from this creation area. This looks to make sure the object requesting the new stylename reference isn’t a ListContentBaseHolder or List so long as there is a stylename already set. Remember – properties are populated immediately after construction and before the initialization phase, that means this styleName will have already had something set on it from our ClassFactory in the List/Tree instance when setting our renderer.

override public function set styleName(value:Object):void
{
if (!super.styleName || (!(value is ListBaseContentHolder) && !(value is ListBase))) super.styleName = value;
}

Now in the List/Tree instance we can set our styleName:
Where:

<mx:Tree itemRenderer=”{myRendererFactory}” />
private function get myRendererFactory():IFactory
{
var cf:ClassFactory = new ClassFactory(MyRenderer);
cf.properties = {styleName:myStyleName};
return cf;
}

Not sure if anyone else has come across this, although I heard through someone else that it may have been mentioned by Grant Skinner on one of his circuits but I don’t see anything on his site about it.

As far as I know, this predominantly applies to applications built in the Halo space, although I suppose it could have some sort of implied effect to Spark.

The Symptoms: When setting the compatibility flag to “3″ certain runtime elements will render to the screen approximately twice as fast when using the Flex 4 SDK (and yes I mocked out an uber-simple PerformanceMonitor which checks the time delta between construction and the FlexEvent.CREATION_COMPLETE). This will become even more evident if you use a distributed rendering model to draw A LOT of elements to the screen (eg iterating a list of elements in a Queue paradigm -this is typically used to manage user expectations during heavy cpu cycles).

The Probable Cause: If you delve into the guts of SDK you’ll notice they use the FlexVersion.VERSION_3_0 just about everywhere in order to determine what behaviors or styles to run. It’s 1 way to keep your software platform up to date using a single source, however it complicates things with backward compatibility. The one area where it probably has the biggest affect is in the StyleManager. Considering the StyleManager is essentially a giant hash map used to manage both inherited, non-inherited, single overridden class selectors, and default type selectors: this is probably the biggest culprit for the Flash Player to be putting on the breaks.

The Risk Assessment: Thankfully not a whole lot appears to change and / or render incorrectly when using both a mix of type and class selectors in stylesheets. The one thing I did notice is some elements which would be typically interpreted as straight string must be encapsulated in quotes (eg textAlign : right now needs to be textAlign : ‘right’ ).

The Key: The key to using the flag is setting it to only 3 or 3.0, because this code checks against a Number, setting the flag to 3.1, 3.2, or 3.3 will cause the additional code to execute thereby giving you the same performance degradation as with just running the actual Flex 4 SDK.

I found only a few references to this, but not much of a well documented solution, so for those who stumble upon this needing one, you’re in luck.

The problem: The ComboBox does not dispatch a change event under all circumstances, most notably when you use the keyboard to select find the particular item in the list. Think of a states combo, where by ‘n’ will first cycle to Nebraska. This then closes the combo, but does not appropriately fire the change event as it would if you manually scrolled and selected ‘Nebraska’ from the list.

Why the problem exists: The combo is a composition of a TextInput, a Button, and a List. While the appropriate change event listener is added to the input, it’s not added to the List to it’s fullest extent. It only checks to see if non-printing characters are used to see if the user is attempting to scroll the list with the arrow or page-up / page-down keys. Thus, when using a normal alpha-numeric filter,  this doesn’t reflect itself in the parent combo control.

The fix: This fix is unusually difficult in light of the fact of one of my earlier rants that at best all properties and / or methods of a highly public and distributed platform, ie the SDK should only ever be protected. Literally all accessors to both the instance list and it’s combo listeners are private? What the hell?

Further proof of their own exacerbation, is a comment that literally says starting around Line 1512:

private function displayDropdown(show:Boolean, trigger:Event = null):void

// Subclasses may extend to do pre-processing
// before the dropdown is displayed
// or override to implement special display behavior

So remind me, how is that possible with a private selector? Oh yeah.

So the only way around this is to override the downArrowButton_buttonDownHandler() handler, and use the mx_internal::isShowingDropdown property to find if the list is about to be shown, and get a reference to the list by grabbing the dropdown property where you will attach your own ListEvent.CHANGE listener. In this handler you proxy dispatch a clone from the ComboBox point of view, and you finally have a change event that now works.

Finally, create another Event.REMOVED_FROM_STAGE event in the createChildren() method, since destroyDropdown() is also private (note to self: !#$#@!) to clean up your additional change event to prevent  a memory leak.

http://help.adobe.com/en_US/AS3LCR/Flash_10.0/flash/sampler/package-detail.html

It’s interesting to see, not necessarily from a backward compatibility model, but interesting none the less for those of us who are leading enterprise applications which are still stuck at “lowest common denomenator” just due to their tremendous size and expected reach.

I can certainly see how many applications can expect to reach a better performance vs cost (engineering man hours, legacy patch costs, etc) ratio for their intensive parts which either have the best chance for memory or cpu utilization management. Lets face it, none of our applications can be so brazen to run on a Cray with unlimited resources (although it sure as hell would be a lot easier on reducing Engineering constraints or getting “Pixel Nazi’s” off our backs).

This one seems weird to be but I guess I didn’t notice it earlier. As we all know Styles set as an external source need to be compiled first, which even for a modest application pushes this up to about 100k or so. I thought this was a bit heavy but didn’t think of it any further.

What the documentation tells you about Modules fails to mention that you can most certainly do the same thing when running the compiler on your compiled.swf stylesheet.

Run the stylesheet builder with the

-load-externs=report.xml

against the

-link-report =report.xml

and instantly save at least 10x the file size (at least this is what I experienced), as it went down to about 10-12k or so.

mxmlc -link-report=myapplication.xml -output=myapplication.swf MyApplication.mxml

mxmlc -output=mystylesheet.swf -load-externs=myapplication.xml MyStyleSheet.css

Instant savings.

Getting a tree to represent data in XML is fairly straight forward, and most examples use this as the default. However, what happens when you have an object tree and want to be able to represent that as the descriptor you built but also easily allow drag-drop operations (especially in cases where you need the parent object reference)?

It turns out writing a new DataDescriptor class is not necessary (as I learned the hard way), but it was necessary to figure out what they are trying to do with ancestors and child objects. While there is no defined interface for it, the data descriptor tries to figure out if the current object is parented by looking for a property called children.

So if you implement your object class with this property as an ICollectionView (it will convert to a ListCollectionView -so you might as well go the extra step to do it yourself), you’re all set.

To the naysayers of MXML / “I don’t see that it’s any better if I can write it all out myself in AS” / progress antagonists, if you’re the type to write ItemRenderers and/or ItemEditors this is where you single-handedly loose in time & money, readability, code quality. Every time. (Those who I previously worked for should seriously pay attention -free lesson here -but they never paid attention to me the 1st time around =) . (more…)

Arrays: every, filter, map, some

Nearly all callback methods to a filter-based method only specify that the type of object to be inspected be of type Object. While this certainly allows for the greatest flexibility in what is stored in the ordinal list, this doesn’t give you much control over chasing down RTE’s or allow for IDE ease of use in auto-completion. (more…)

Next Page »