It's interesting Alex because on the Flex forum and at least a few times here on flex coders I've seen this same question, I recently just answered someone asking how to prevent sort while editing grid values.
So I really have 2 points 1) let developers disable re-sorting of a collection on propertyChange (ListCollectionView feature enhancement not bug) 2) make sdk more interface based. Here is the scenario for #1: "Don't automatically reorder rows while I'm editing the grid" - imagine working in excel and having rows jump all over the place as you change value of cells. This sounds like at least a reasonable scenario for editable grid controls. One could argue that automatic resorting (in certain scenarios) is very counter intuitive and while it's ok that it's a default, it should be something we can easily disable on a live collection bound to a view (you can already do this with sort/group/filter). I have never seen documentation or best practice stating that you should reapply the dataProvider every time you make this change. Because of that, I really don't agree with this statement "The idea is that you never apply a sorted AC to the DG". To me this is the beauty of Flex View+Model working together, I have a grid bound to some data, I apply sorts/groups/filters to my collection all the time and the view reflects those. I understand that you see this issue because your "sort, refresh, toArray and reset() all in one shot. I would use custom header renders to display the virtual sort" solution would certainly work but it's a lot of work in some scenarios. In our specific example the CustomAC we set as dataProvider has quite a bit of business logic that it shields from the grid (we recalculate other cells based on changes to existing ones), it also makes sure that the grid control thinks its operating on a vanilla AC. #2) "its faster to monkey-patch and continue", it's actually must safer (speed of dev is not issue) to monkey patch it as I don't have to hunt down all usages of Flex classes and make sure I custom implemented them. On to the other questions, " We don't have the resources to build mock collections so our test teams use the only implementations of IXXXCollection they have" - I'm not sure I follow, I was simply suggesting the code itself is more interface driven (it's already at least 97% there). Not clear on how this affects your test scenarios since it is my responsibility as a developer to make sure that my CustomCollection (which implements ISomeFlexCollection) works as long as I implement the interface and if I broke something because I chose to re-implement some Flex class it's my own fault. Maybe this is making it more then it but this " disable re-sorting of a collection on propertyChange" idea is an enhancement not a bug, in fact LCV is solid piece of code :) --- In [email protected], Alex Harui <aha...@...> wrote: > > OK, I imagine when you're actually trying to get your app working that its > faster to monkey-patch and continue on than do a formal patch. But if you > have time, maybe instead of a formal patch, let's strategize a bit. The main > reason these bugs exist is because we don't have a fool-proof way of finding > them. We don't have the resources to build mock collections so our test > teams use the only implementations of IXXXCollection they have. We can do > manual scrubs but as soon as you check in, the next day an engineer will make > a mistake and we won't catch it again. > > The problem is that we don't have the resource and mechanism for accepting > test material from the community and if the community submits a mock > collection with a bug in it, the lead time for getting response from the > community totally messes us up. > > The only thing that moves the needle is folks submitting a test case with > their bugs that makes it clear that their situation is not so unusual that it > can be pushed out to the community pasture. I'm not so sure I like your > "disable the sort on further changes" flag idea so if you just submit that > and management comes to me I'll probably say that we shouldn't take that > change as it breaks the contract of introspecting the sort and making > assumptions of the data within and might mess up the search/find code as > well. So let's focus on that first. > > You're saying that the "toArray and reset" is too expensive. I don't know > ADG code that well, but my sense for DG is that the cost should be > negligible. The idea is that you never apply a sorted AC to the DG. When a > sort is requested, you sort, refresh, toArray and reset() all in one shot. I > would use custom header renders to display the "virtual" sort. > > This scenario is common enough so if there is a bug in our code that makes > that strategy too expensive, file a bug with a test case on that and you'll > probably get votes and we'll fix that. If that strategy just isn't working > for you, let's figure out why. > > Meanwhile, I'm forwarding this email to a colleague who gets to worry about > ADG for Spark. And me, I'm working on a top-secret project that might have > the side effect of minimizing the chance that you find yourself pinned down > like this in the future. > > > On 3/23/10 6:32 PM, "tntomek" <tnto...@...> wrote: > > > > > > > Thanks again :) I'll take your advice and file a formal patch. Just so you > know my initial solution was a custom implementation of many of these > components via copy paste and modify. Where I finally drew the line was > HierarchicalCollectionView/ADG, it was much more risky to duplicate, modify > and make sure that I addressed all known usages of these classes than to just > patch them and sleep sound knowing that I didn't miss anything internal. > > Even taking a look at makeListData in ADG > > it has: > "iterator is HierarchicalCollectionViewCursor" > > I mean why oh why not IHierarchicalCollectionViewCursor :) > > Now that 4 is out the door, I would strongly suggest the Flex team takes a > quick scrub of the SDK to hunt down these fixed references and ensure that > developers can safely plug custom interface/factory implementations in. > > Thx for your hard work on 4 btw :) while its a bit too soon to switch because > of the player 10 minimum we are excited by what the team is doing, FB4 is > wickedly a pleasure to use over beta 2. > > --- In [email protected] <mailto:flexcoders%40yahoogroups.com> , > Alex Harui <aharui@> wrote: > > > > I was thinking about your problem some more. While it is bad that ADG > > assumes HD, it seems like it only does that for drag/drop and you should be > > able to subclass ADG, override dragCompleteHandler and call your own > > version of addItemsToTarget. Then you wouldn't need to monkeypatch ADG. > > > > > > On 3/23/10 2:10 PM, "tntomek" <tntomek@> wrote: > > > > > > > > > > > > > > Hi Alex, > > > > Specific issues I've had were mostly in DMV components, GroupingCollection > > (and GC2), HierarchicalData and ADG all make hard coded "new > > SomeSdkFlexClass()" with no way to plug in a custom class' that implements > > the necessary interface. I already made my custom copies of GC since it's > > beyond hope to plug in a custom ICollectionView/IList. And because ADG > > instantiates HierarchicalData I had to monkey patch that as well. > > > > You're right in that I could do the toArray and reassign to my View but > > that would totally recreate the view in an undesirable way. > > > > It's a lot cleaner for me to have CustomAC and just inherit from AC and set > > enablePostSortReorder=false in CustomAC constructor. I never actually > > change the value of enablePostSortReorder once its instantiated and > > assigned to my view. I do however update sorts/group and filters without > > having to set my ADG to new dataProvider. To me this freezing of > > sort/filter state is no different then asking me to do a custom filter then > > reassign back to my view object, we just don't do that, its enough to call > > sort/filter/group and refresh() and this keeps that behavior consistent. > > > > And this is internal code and not something we are distributing, in that > > case I would of course not even consider monkey patch route. > > > > What do you think? Would this be a valid SDK candidate change? > > > > Here is the specific bug I filed a while back. > > > > https://bugs.adobe.com/jira/browse/FLEXDMV-2341 > > > > -Tomek (http://tomek.me) > > > > --- In [email protected] <mailto:flexcoders%40yahoogroups.com> > > <mailto:flexcoders%40yahoogroups.com> , Alex Harui <aharui@> wrote: > > > > > > I'm confused. Whose code makes "new ArrayCollection" assumptions? > > > > > > The area of code you are changing implies that the collection has long > > > since been established, a sort or filter is applied and you want to make > > > some change that does that should not adjust the sort or filtered > > > results. Under what conditions is that happening? In many cases folks > > > want to freeze the current sort and then add new items at random. At the > > > time they would set your enablePostSortReorder=false, they can just as > > > easily copy the AC into a new one using toArray > > > > > > > > > On 3/23/10 12:17 AM, "tntomek" <tntomek@> wrote: > > > > > > > > > > > > > > > > > > > > > Thanks Alex I'll give the order a shot. I'm not so much introducing a new > > > api as adding a bool to toggle some behavior, be default it will behave > > > like vanilla. > > > > > > The specific issue is to disable sort in ListCollectionView and since > > > ArrayCollection inherits from that and many controls are hard coded for > > > "new ArrayCollection" vs new Factory(SomeCollection) I don't see many > > > options. > > > > > > Do you have time to give your 2 cents? > > > > > > In > > > private function handlePropertyChangeEvents(events:Array):void > > > > > > Change > > > > > > if (sort || filterFunction != null) > > > > > > to > > > > > > if (enablePostSortReorder && (sort || filterFunction != null)) > > > > > > http://tomek.me/disable-sort-on-datagrid-edit-update/ > > > > > > --- In [email protected] <mailto:flexcoders%40yahoogroups.com> > > > <mailto:flexcoders%40yahoogroups.com> > > > <mailto:flexcoders%40yahoogroups.com> , Alex Harui <aharui@> wrote: > > > > > > > > It is bad practice to be adding new APIs when monkey-patching. You > > > > should be subclassing instead. > > > > > > > > However, all that should matter is the compile time stamp in the SWC. > > > > Newest one wins. Make sure the SWCs are listed in the correct order > > > > just to be safe in your project properties. I'm not sure if code hints > > > > go lookin for the time stamps. > > > > > > > > > > > > On 3/22/10 5:30 PM, "tntomek" <tntomek@> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > Seems like monkey patching works when everything is included in 1 > > > > project but not when using libraries. What happens when I have 2 > > > > projects and monkey patch is in other one. > > > > > > > > i.e. > > > > MainAppProject (contains MainApp.mxml) > > > > -SomeLibraryProject (this has the monkey patch code, i.e. Button) > > > > > > > > Now in my MainApp.mxml I'm unable to reference my version of the code. > > > > > > > > I understand if I use RSLs I can force load my class first so runtime > > > > would work, but how do I get compile time access to this class? What if > > > > I added a new property (in library project) and I want to access that > > > > property from MainApp? The compiler has no idea and I can't build. This > > > > forces me to make the monkey patch class implement some interface that > > > > would guarantee compile time changes, but this is getting way more > > > > complicated then it needs to. Any other ideas? > > > > > > > > -Tom Gruszowski (http://tomek.me) > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > Alex Harui > > > > Flex SDK Team > > > > Adobe System, Inc. > > > > http://blogs.adobe.com/aharui > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > Alex Harui > > > Flex SDK Team > > > Adobe System, Inc. > > > http://blogs.adobe.com/aharui > > > > > > > > > > > > > > > > > -- > > Alex Harui > > Flex SDK Team > > Adobe System, Inc. > > http://blogs.adobe.com/aharui > > > > > > > > > -- > Alex Harui > Flex SDK Team > Adobe System, Inc. > http://blogs.adobe.com/aharui >
