I've got a flex app with a DataGrid with several columns (defined in the MXML file), and I need to "introspect" the grid columns. That is, I need to write some ActionScript code which, given the DataGrid object, can determine various things about the grid (and more specifically, the columns of the grid).
In particular, if a column is just plain text output, I don't really care about it... but if it's got "actionable" controls within it (checkboxes, linkbuttons, etc) I do.
First, I'm assuming that columns which contain "actionable" contents will be within <mx:itemRenderer> tags (else it would just be plain text); please let me know if this is incorrect.
Next I need to "dig down" into the structures, pulling the AS object corresponding to the <mx:DataGridColumn> out of the <mx:DataGrid> (I've got this), then pulling the AS object corresponding to the <mx:itemRenderer> out of the mx:DataGridColumn (two diff ways to do this; neither seems very useful), then pulling the AS object that corresponds to the <mx:Component> out of the mx:itemRenderer (if any; it's unclear to me whether the mx:Component actually creates an object), and finally pulling the AS object corresponding to the <mx:LinkButton> (or whatever) out of the mx:Component.
Does anyone know how to do this?
P.S. I understand that there's almost no limit to what could be lurking within the itemRenderer; if I can dig down that far, I'm willing to test for a handful of things that I expect and ignore the rest.
To clarify somewhat, I've been asked to provide Section 508 compliance (accessibility) to an existing application. There are a lot of pieces to this, of course, including screen readers, etc... but one of the first steps is making sure that the application can be used without a mouse.
Many of the existing screens have a UI technique consisting of a DataGrid with item renders which place controls like radio buttons and linkbuttons and whatnot into the cells (same type of control all the way down the column). All well and good, except I can find no way to interact with these controls via the keyboard.
So, I modified one screen to have a hot key which pops up a context menu, allowing the user to arrow up/down among the actionable items, and press ENTER to choose one (toggle the checkbox, press the linkbutton, etc). But this was screen-specific, and it will be too easy for someone to update the screen (e.g. adding another actionable column) and neglect the menu.
A better (?) approach was suggested: subclass the data grid, introspect to find the actionable columns, build the menu automatically, and now all we have to do is swap out the SuperDataGrid for the DataGrid, and our screens will be 508 compliant.
If someone can recommend a better way to make the screens 508-compliant (without redesigning the UI) and with minimal per-screen effort, I'm all ears.
Maybe I'm not being clear enough, since you keep missing the point, so let me try again.
I'm NOT writing application-level code... if I were, I'd know exactly what the logic is doing and I'd be able to use the bound data in the normal way. In fact, the application-level code DOES use the bound data in the normal way. But that's totally beside the point.
What I'm TRYING to do is write "infrastructure-level" code: that is, code which runs "below" the level of the application logic. I'm trying to effectively add a feature to DataGrids which Adobe should have included, but didn't. If I can get this class working, it will be possible to just drop it into dozens of screens WITHOUT ME, AS THE CLASS AUTHOR, KNOWING ANYTHING ABOUT THOSE SCREENS OR THE LOGIC WITHIN THEM. The only way I can imagine this working is to look into the datagrid and discover, at run time, what types of controls lurk within it, and possibly what they're bound to (actually, I can probably just execute whatever the click="foo()" attribute says to do, and I won't need to know what they're bound to).
Does this make sense?
Is it possible?
Item renders interact with the outside world through their data property. They should render the data as desired and make changes to data as required. They should not reach outside and you should not try to reach in to affect an item renderer directly.
As far as the underlying problem you're trying to solve, you haven't stated it at all. You're describing a desire to follow through on a particular solution only but haven't described the underlying problem. What are you really trying to accomplish? Don't talk about getting access to item renders or digging into the DataGrid, but what interaction or affect on the rows do you want? The problem is your approach is somewhat backwards and that's why it's not working out.
Related
I have to create a Dynamic menu in ASP.NET. I want to use dynamic LinkButtons (or can be a Menu Control), but should be appended with sequence numbers. Eg: 1,2,3a 3b etc..and these sequcenes could be dynamic. Any idea. I used a repeater with a label and LinkButton in it, but having problems with view state. Any idea how to append sequence to menu??
Essentially, you have two paradigms with web applications, at least from this conversation's standpoint.
Stream out the HTML, creating it as you stream
Create containers that can bind to data and shape the data
Your concept seems to be "only #1 is dynamic", but that is not true. Any time you can change the data and get a different output, you are dealing with something dynamic. My personal feeling is shape the menu data prior to binding. This cannot always be done, but more oft than not, it can. The second method would be to attach to an event like a item binding or row binding event. Controlling the HTML stream and writing out individual items is generally my last resort.
Now to the viewstate issue. Viewstate is a bastard when you start adding things to an item after binding and semi-problematic when you are playing the dynamic game from #1 above. The problem is things added after the initial definition cannot easily be set up with automagic bits. You end up having to rebind each time. This is why shaping data and then binding is superior. Even in cases where you have to rebuild, you can cache the shaped data and quickly rebind. It takes more "up front" work, but is less problematic.
The actual container you are binding with is inconsequential. Unless you can't use the menu control for some reason (other than having to dynamically add, which can be solved by playing with the bound data), I would head this direction. Actually, I would head this direction and use the CSS friendly adapters so you can alter the look and feel more easily. :-)
I come from the Delphi school. I was really used and pleased with Delphi grids with the plus features of InfoPower. Not just me, my users loves all features that include grids. Some motives for that are:
With grids they have the ability to insert detail information using only the keyboard. Input, Tab, Input, Tab, Input Tab (automatically insert new row), input, tab, etc.
They were able to simply click in a row and edit it´s data.
They could navigate between records using only arrow keys.
In my flex apps I´ve being working arround this quite often, sometimes using a popup to insert data, sometimes using repeater instead of grid. But now I really really need some intuitive, fast way for my users to insert this data.
I am trying to use DataGrid (or AdvancedDataGrid) with inline editors and I am living a real hell to do that. For the last 3 days I am struggling, tweaking and workarrounding in order to try to mimic the features that I had with Delphi.
Main problems are:
DateField simply don´t work as an inline editor. It gets focus but never looses, only with pressing ESC, wich makes me loose the inputed data.
AdvancedAutoComplete: I have a component descendant from AdvancedAutoComplete with a custom browser. The custom browser is a popup, when I try to PopupManager.remove flex raises an exception of a null pointer inside it´s focus managing engines.
I couldn´t get to insert a new line focused in it´s first column when TABing in the last column of last row.
Having all these problems and not getting substantial material to solve them makes me think the (now obvious) fact that it is just not the way grids are intended to work in flex. My question is: what are the patterns used in flex applications to make sequencial, intuitive, fast, keyboard only insertions in a detail?
To answer your question bluntly, there are no specific established patterns to make editing or inserting data in the DataGrid fast and easy. Not being able to Tab between fields is one of the things I really wish Adobe had added to the DataGrid by default.
In order to get the functionality you want, you'll have to do some custom coding and extend/override the DataGrid's default functionality. Switch On The Code has an example up on tabbing between fields, but you would have to build upon their sample a bit further to include features like adding a new row when pressing tab in the last field of the last row in the DataGrid.
You may also want to consider Flexicious. Based on the Flexicious Ultimate demo, it looks like they have the functionality you're looking for (and then some!).
I have a generic function to build rows of controls (each row comprising of sliders, radio buttons, reset buttons, text display) etc, and some functionality to change underlying data based on these
As I didn't want to write specific code for each row, I had code written by which I can detect the row on which there has been a mouseevent, and though the row access each individual control
The hierarchy used is titleWindow (part of popup)->skinnable container->HGroup->control
When I trace for a radiobutton, I get the path as follows Electric_Modify.TitleWindowSkin2620._TitleWindowSkin_Group1.contents.contentGroup.0.RadioButton2645
The '0' before the radioButton stands for the first Hgroup id->named as 0
I tried accessing the radio button as follows- 5th element in the HGroup
((this.contentGroup.getChildAt(row)as Group).getChildAt(4) as RadioButton).enabled=false;
and get a message "Cannot access a property or method of a null object reference" on this line. How should I navigate the hierarchy to reach the element?
You should be using getElementAt(...) and not getChildAt(...).
The get element functions represent a "higher level" element hierarchy which is needed to make skinning easier.
((this.getElementAt(row) as IVisualElementContainer).getElementAt(4) as RadioButton).enabled = false;
It should look something like that, but the exact hierarchy depends on what's in your app.
#drkstr
Thanks for your input... I thought of an alternate approach that worked for me...I mapped out the parent of the HGroup via
parent1=hgrp.parent; and then referenced these buttons as follows
((parent1.getChildAt(row)as Group).getChildAt(4) as RadioButton)
This works like a dream...I presume your suggestion would let me jump across the intermediate layers
#J_A_X/ #Constantiner: Thanks for the suggestion. I have no idea why we didn't think through and go down the DataGroup path. Prima facie seems simpler... we got to creating the UI controls in MXML laying out controls serially,and when it came to making it generic, we literally replicated the MXML approach in AS. Started off easy, till it caused problems like above. We will fix this to a better approach, when we upgrade versions. It works for now
I'm building my first Flex custom component, in Flex 3. It is a data table based on the 'Grid' container class, with a simple text Label in each cell. (DataGrid and AdvancedDataGrid were not appropriate starting points for my needs.) The component works quite well using smallish tables, but I tried stress-testing it using a larger table, and have been disappointed by the results.
The component creation process has some slow spots, but those are in my power to optimize and aren't my primary concern. What worry me more are what appear to be limitations in the Flex framework itself.
This 'large' sample table has a bit over 7000 cells in it. This is largish, but still 1-2 orders of magnitude less than the biggest I need to accommodate. In standard Grid structure, the main portion of the component consists of a Grid with 400 GridRows of 16 GridItems each, plus a few other smaller ancillary Grids.
Once the table renders, I find the following:
Mouse-related events are slow to fire. Specifically, I have rollOver/rollOut event handlers registered on each table cell, to let me highlight the cell under the pointer. On a small table, I could move the mouse over the table very quickly, and the highlighting would follow the pointer in real-time. With the larger table, the highlighting is very jerky, changing only about twice per second, skipping over many cells.
If I place the mouse cursor over the component and leave it there, my CPU is pegged (one processor core, anyway), and stays that way until I move off of the component, when it drops to idle. My component isn't doing anything at all at this point.
It feels like Flex simply cannot scale to support component trees that are this large. I shudder to imagine how it would behave with 100,000 cells. Perhaps I'm pushing the Grid beyond its intended use, but having an object per table cell doesn't seem like an unreasonable model, and ~14,000 objects in the tree (a GridItem and a Label per cell) seems pretty modest.
I have yet to get useful data out of the FlexBuilder profiler; I'm working on it. For now, my biggest questions are:
Am I really pushing the limits of Flex with this modest test?
Is my approach to this component completely off-base?
I'm running this on Flash Player 9 under Firefox on WinXP.
Yes, Flex is not designed to support very large numbers of components, it is well known that you should minimize the number of components and don't use features that you don't need (Eg. DisplayObject instead of Canvas if you don't need the extra functions).
It's unwise to mirror your data exactly with displayed objects. DisplayObjects (and related classes) are relatively heavyweight, and you need to control how many of those you have.
I would say that the scale you're working at, with 1000+ Cells, and an event listener for each one, would definitely reach Flex's limits.
I think you should take a better look at your approach and architecture. I assume you are not displaying all 1000+ items at the same time, perhaps you should use paging and display 100ish with each screen, with previous/next buttons to move on to another page. You could also consider dynamically adding and removing rows using a custom scrollbar, simulating the scroll effect. This is much more complicated to do.
Boy, it seems we can write a book on this topic. Or atleast a chapter. We learnt quite a few things in this area as we were developing our products.
Bottom line - yes, Flex will slow down to a halt when you add 1000+ "things" on the screen. Here are a few bullet points, and some repetitions of what's already mentioned (just to be concise)
1) Always draw only what is visible. Hans Muller, the architect on the new Spark DataGrid has a great writeup on ViewPorts. http://hansmuller-flex.blogspot.com/2009/06/introduction-to-viewports-and-scrolling.html. So instantiate enough "cells" to fill up the visible area, and basically recycle them as the user scrolls.
2) Recycle, recycle, recycle: Further to above, as the user scrolls, you obviously have to recycle cells that are now out of view to show the ones that are in view. Here there are a few things we learned the hard way :-)
-> Instead of disposing and creating new cells, either use reparenting or use repositioning (prefer repositioning)
What this means is this: Say you have a 10X10 grid (visible) showing a 100X100 data provider.When the user scrolls to cells 20X20, the quickest way will be to set the X and Y of the existing cells to the new locations, and then call set data for each. We used reparenting earlier because our scenario was a series of related containers, so this may not apply to you. But bottom line - we simply move "rows" around the visible area. So creating and destroying will be slow, removing and adding to the display object list will be faster, and just moving around (x,y) will be fastest.
3) Choose what you inherit from wisely: The Flex SDK is a beast. So choose your "cells" base class wisely. For example, the SDK DataGrids, have a lightweight renderer that inherits from UITextField (Halo), as opposed to Label. Even UIComponent will be heavy in certain scenarios. Look up the asdocs for UIComponent and see if you need everything in there, else consider inheriting from further up its hierarchy.
4) Cache Calculations: Do this last in your development cycle. Once you are done with a feature, run flex profiler. Identify the longest running methods, and the most called methods. We always do this when we release, because there's always improvements to be made. There's a lot of math involved when you're developing a highly visual component, and too many calculations will slow things down.
5) Make sure you profile for memory : Unwired event listeners, rogue object references, etc will kill performance. Flex profiler is an excellent tool to combat this, so make sure you use it.
We have some good links here:
http://www.flexicious.com/resources/Ultimate/Docs/LargeDataset.htm?
Hope this helps!
If you look at any List-based control in the Flex framework, you'll see that they make significant use of item renderers which are recycled. So a DataGrid with 20 rows displayed only creates about 22 renderers and recycles them as you scroll through the list. This is why a DataGrid can hold thousands of records and still have pretty snappy performance. I recommend you check out Peter Ent's series of articles on item renderers and take a look at ListBase/List and some of the related classes to understand how to build something similar:
http://weblogs.macromedia.com/pent/archives/2008/03/itemrenderers_p.html
Without seeing your code and knowing exactly what you're trying to do...it definitely seems like you're pushing the limits of Flex by pushing that much data into the framework all at once.
Keep in mind that the Flash runtime wasn't designed to handle huge applications...but run somewhat light applications inside the browser. It also seems unlikely that your users are going to need to have access to all of those controls all at once.
You could try providing data services (Java, .NET, etc.) to drive the data in your application. You would then page through the data so that the framework is only dealing with maybe 200 - 300+ elements at a time.
In flex, if you using Mouse move event to redraw anything .. You might have experienced very slow rendering .
eg:
this.addEventListener(MouseEvent.MOUSE_MOVE, redraw);
and
public function redraw(anything:Object=null):void{
//draw something here
this.graphics.clear();
this.graphics.lineStyle(3, 0x000000);
this.graphics.moveTo(startPoint.x, startPoint.y);
this.graphics.lineTo(endPoint.x, endPoint.y);
this.scaleTextInput.x = centerPoint.x;
this.scaleTextInput.y = centerPoint.y;
}
The Above code results very slow rendering ...
Solution:
Use Event.ENTER_FRAME event instead? Although more resource intensive than the mouse move event, you should receive considerably more updates per second, allowing the mouse to appear more responsive to the user:
Eg:
this.addEventListener(Event.ENTER_FRAME, redraw); instead of
this.addEventListener(MouseEvent.MOUSE_MOVE, redraw);
and You are good to go ..Happy Flexing
More on:
http://www.deepakdhakal.com
I've written a simple calendar control to allow for selecting single days, weeks, months and so on. The simplicity comes from the fact that I don't really do any drawing myself, opting instead to create a bunch of boxes and labels to act as date cells for the calendar.
When a date or a date range is selected, I need to highlight that range. It's easily done by iterating through the cells and switching their style. [edit:] However, this seems to cause a delay during which the cells are first drawn as if the style name was blank, and then re-drawn with the correct style, despite the fact that I never explicitly set the style to null -- I alternate between "CalendarCell" and "CalendarCellSelected".
If this were Windows Forms, I'd call SuspendLayout on the parent container to make sure the controls are repainted only after I've finished the updates. What I'm looking to know is whether or not a similar solution exists for Flex. I'd like to avoid drawing the entire calendar "manually", so to speak, if that's at all possible.
edit: changed the problem description to more accurately reflect what I'm seeing.
Are you using callLater() at all?
If you use callLater() it may impove your visuals as it batches up changes until it needs to draw a frame or you force a frame draw with validateNow() or similar. It might be enough in your case.
Is your calendar control a UIComponent? Is it using the standard invalidation methods like commitProperties(), updateDisplayList(), etc?
What you might want to do is keep a private array of the cells that will have their styles changed, but then do the actual style switching in your commitProperties() override. I'm just not sure if setStyle() fires an validateNow() because the flickering is a bit surprising.
This may not be exactly what you're looking for, but David Coletta at Adobe has posted a video explaining an EventCoalescer that they use in Buzzword for deferring events that update specific areas of the app UI until the user has stopped moving the insertion point in the text, for example.
This blog post by Hans Van de Velde also has a similar solution, and actual code for it as well.