incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Smith <rob...@thedevprocess.com>
Subject Re: Halo x Spark
Date Sat, 24 Mar 2012 18:49:02 GMT
I agree with Sebastian. As long as both component sets remain available, 
the argument is pretty moot. My personal opinion is that I'll take the 
spark components and the power they provide over mx components any day. 
In advertising, it's very helpful to have the extra capability to do 
most anything a client an dream up. Also, in the case that your client 
presents you with a crazy design, it's much less complex to go through 
the spark skinning process than it is to extend and modify an mx 
component to have just the behavior you want.

On 3/24/2012 6:20 AM, sébastien Paturel wrote:
> i already started a discussion several weeks ago about it.
> MX versus Spark war has no sens since flex could not stay without 
> separating ui logic and skin code. spark components had to be done. 
> Without Spark architecture, im not sure we would be able to target 
> mobile today.
> The main issue here is ease of skining.
> Spark is great for flexible skining, and complex UI, making it more 
> easy to complitly change the layout of a component, when MX component 
> make you stuck.
> But for easy skining, spark made it more difficult.
>
> But the war has no sens since you still can choose to use Spark OR Mx 
> components in latests flex SDK according to what you want to do.
> Thing is Spark lib is not complete yet, not all MX components have 
> Spark counterpart yet.
>
> For easy skining, we can create a new component lib, based on Spark 
> wich could expose same skin settings than MX ones do.
> That would not be so much work to do and it could give back the easy 
> skining ability we liked with MX.
> MX components would stay in SDk only for backward compatibility.
>
> Le 24/03/2012 11:49, Carlos Rovira a écrit :
>> Oleg,
>>
>> I'm not saying that the problems you are point are not there, but if 
>> we are
>> commeting between halo vs spark. I think the later is the way to go. 
>> MX was
>> a component set brought from the Flash MX and MX 2004 days. It has many
>> problems, more than spark.
>>
>> If this discussion is about to choose a way. We should think about make
>> spark better, since make mx better is not an option. The other way 
>> should
>> be a third new component set that address from scratch all problems. But
>> that could happen in the long term since that should required lots of 
>> work,
>> and that would not require to be called Flex and all the hard work to 
>> move
>> flex from adobe to apache. That could be done from scratch as a new 
>> Apache
>> project.
>>
>> So we should discuss things that could be done and should be possible.
>> Spark is the recommended component set in flex right now. we should 
>> work to
>> make it better. Take other way could definitely kill flex since we 
>> should
>> end doing nothing.
>>
>> Maybe a better component set could be make in the following years but to
>> make it happen we first need to make apache flex success...
>>
>>
>>
>> 2012/3/24 Left Right<olegsivokon@gmail.com>
>>
>>> Carlos,
>>> I've just explained why using Spark skins sometimes is absolutely
>>> impossible - they are literary order of magnitude bigger and slower 
>>> then
>>> their Halo counterparts. This may be a weak argument in the light of 
>>> how
>>> the entire framework is slow and bloated, but there are always certain
>>> requirements and at times it just becomes the straw that breaks the 
>>> neck of
>>> the proverbial camel.
>>>
>>> I'm not trying to protect Halo components in particular - I don't think
>>> they were better designed or anything. It just happened so by chance 
>>> that
>>> they were smaller and there was a shorter tool chain that made it 
>>> possible
>>> to skin them. I think that ignoring the problem introduced by the 
>>> change is
>>> short sighted. There is a problem: a longer tool chain, a more 
>>> complicated
>>> development process, a less optimal outcome - you can't really ignore
>>> that...
>>>
>>> Best.
>>>
>>> Oleg
>>>
>>
>>
>


Mime
View raw message