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], 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> , > 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> , 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 >
