Mailing-List: contact dev-help@flex.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@flex.apache.org
Received-SPF: pass (athena.apache.org: domain of gavharbs@gmail.com designates
 74.125.82.54 as permitted sender)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Apple Message framework v1283)
Subject: Re: Spark Tree
From: Harbs <gavharbs@gmail.com>
In-Reply-To: <CD5B6AD3.4E643%aharui@adobe.com>
Date: Tue, 5 Mar 2013 22:54:58 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <DABA9097-4CD0-48DC-A718-FB94293204D4@gmail.com>
References: <CD5B6AD3.4E643%aharui@adobe.com>
To: dev@flex.apache.org

My concern was really because selecting "Spark only" in Flash Builder =
makes those classes unavailable. I'm not sure how much of an issue that =
really is. Does that compiler option really make any difference in app =
size if you don't use mx components?

I've been spending a LOT of time (like tens of hours) minimizing =
dependencies in my app. It's horribly painful=85 :-(

On Mar 5, 2013, at 7:26 PM, Alex Harui wrote:

> I think you have to pick some goals.  What is the main purpose of a =
Spark
> Tree?  Is it just to allow for Spark skinning of the control?  Does it =
have
> to run on mobile (Spark DataGrid is not recommended for mobile either =
and
> the Adobe version of Spark Tree was going to be based on Spark =
DataGrid).
>=20
> If mobile isn't a requirement, then a dependency on =
ITreeDataDescriptor and
> HierarchicalCollection isn't the end of the world.  I think those =
classes
> are now in the mx.swc which is in most Flex projects except for =
mobile.  And
> you can always map the classes in the manifest into the spark =
namespace (we
> already do that for ArrayList)
>=20
> You could move some of these classes back into framework.swc so the =
default
> mobile projects will have the classes, but check to see what else they =
drag
> in so we know the full set of what we're moving.
>=20
> I believe the Spark Tree on my blog also used these classes.  I don't =
recall
> any real need to want to re-write the collection and descriptor APIs.
>=20
> -Alex
>=20
>=20
>=20
> On 3/4/13 11:29 PM, "Harbs" <harbs.lists@gmail.com> wrote:
>=20
>> On second blush, it looks like spark-tree has all of the same =
dependencies=8A
>>=20
>> What's the correct way to go about this?
>>=20
>> On Mar 5, 2013, at 9:11 AM, Harbs wrote:
>>=20
>>> Okay. I'm looking into this now.
>>>=20
>>> I've tried Spark-Tree as well as this one.
>>>=20
>>> Both seem to have dependency on mx.
>>>=20
>>> Spark-Tree has a dependency on =
mx.controls.treeClasses.ITreeDataDescriptor2
>>>=20
>>> alatarus/tree has even more dependencies:
>>> mx.collections.HierarchicalCollectionView;
>>> mx.collections.HierarchicalData;
>>> mx.collections.IHierarchicalData;
>>>=20
>>> An additional issue with Spark-Tree is a conflict between some style =
names
>>> and private vars. That was easily fixed by renaming the vars.
>>>=20
>>> I think duplicating the ITreeDataDescriptor2 interface should be =
easy enough.
>>>=20
>>> Anyone know who Kachurovskiy is for a donation? Alternately, Alexey, =
would
>>> you be interested in donating your implementation?
>>>=20
>>> On Feb 25, 2013, at 2:42 PM, Alexey Taran wrote:
>>>=20
>>>> My implementation:
>>>> https://github.com/alatarus/tree
>>>> Supports sorting and filter function.
>>>>=20
>>>>=20
>>>> 2013/2/22 Paul Hastings <paul.hastings@gmail.com>
>>>>=20
>>>>> On 2/22/2013 5:18 PM, Bogdan DINU wrote:
>>>>>=20
>>>>>> Hi, I've used Kachurovkiy's version - seems well written.
>>>>>>=20
>>>>>=20
>>>>> +1 (not that i'd know anything "well written" in flex but it works =
as
>>>>> advertized).
>>>>>=20
>>>=20
>>=20
>=20
> --=20
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>=20