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" <[email protected]> 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 <aha...@...> 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" <tnto...@...> 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
