Mailing-List: contact flex-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: flex-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of carlos.rovira@gmail.com
 designates 209.85.213.175 as permitted sender)
MIME-Version: 1.0
Sender: carlos.rovira@gmail.com
In-Reply-To: <kuj5ygqar6f3h03k5gjx28dn.1332581006415@email.android.com>
References: <kuj5ygqar6f3h03k5gjx28dn.1332581006415@email.android.com>
Date: Sat, 24 Mar 2012 10:53:38 +0100
Message-ID: 
 <CAMFKFRi22eeD6t7qS6XFh+Z7h+4THPns+59ep0GHFtKSm0=XJw@mail.gmail.com>
Subject: Re: Halo x Spark
From: Carlos Rovira <carlos.rovira@codeoscopic.com>
To: flex-dev@incubator.apache.org
Content-Type: multipart/alternative; boundary=20cf30563a0388723304bbfa1d33

--20cf30563a0388723304bbfa1d33
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I agree with the people that thinks that "spark was the best thing happen
in Flex4". Until Flex 4 skinning was limited and a pain. Right now skinning
is soooo much easy. Why people thinks the opposite let me think that they
does not understand how to use skinning in the right way.

For example I see many people using views and components directly in MXML
and using external Presentation Models...The recommended way is to use
views and components in AS3 that holds  the logic you will use in your
Presentation Model and separate the representation in a MXML (again for
views and components).

In this way you can effectively put all your skins and css in an externa
SWC and change all the apperance of your application.

mx was monolitich with kilometric methods with logic and representation
mixed making separation of concerns impossible. With spark a huge step in
separation was done, and in many components the logic is better distributed=
.

A evolution in spark (the right way) should continue the separation of
concerns since some core components continue to have thousands lines of
code.

To all the people that state that prefer mx over spark I would ask they try
to learn more about spark and try to figure why many things was done in
that way.

Again not all is positive and as many people stated here before, many
things was done to accomodate Flash Catalyst and maybe this is some of the
overhead and negative things.

But the approach is great, and people should try to avoid prestablished
thoughts and learn more. I'm sure they will find a great component set with
a great architecture that we should evolve and maintain. Still there's many
bugs


2012/3/24 Tink <flex@tink.ws>

> You can't design and preview skins in Illustrator, Fireworks and Photosho=
p
> and export as FXG?
>
> Tink
>
>
>
>
> Left Right <olegsivokon@gmail.com> wrote:
>
> >I think that the most important motivation behind new skinning system wa=
s
> >that assets imported from Flash CS aren't editable / aren't fully editab=
le
> >in other editors commonly used for Flex framework. Since new skins are a=
ll
> >in plain text, they eliminate this restriction. However, several importa=
nt
> >advantages of previous system were lost. The preview at the time of
> >developing the skin is very important, but no tool exists to fairly
> preview
> >Spark skins until they are actually used. For reasons beyond my
> >comprehension, the skins had to inherit from UIComponent. Combined
> together
> >these two disadvantages are a show-stopper for many projects / workflows=
.
> >
> >Now, the problem with promising that this is going to be fixed any time =
is
> >that:
> >- If we want to consider some graphic tool for designing the GUI, what
> tool
> >should it be?
> >- New skinning system is the most significant change in Halo to Spark
> >transition, if it is dropped, then there's basically no reason to use
> Spark
> >at all. So, patching Spark components in attempt to alter the way they u=
se
> >skins would be a major rewrite anyway.
> >- There isn't any solid plan, neither less solid goals or even intention=
s
> >expressed as about what would be the priorities of Apache version of the
> >framework, so I don't think there may be a reasonable answer. Maybe this
> >will be addressed, maybe it won't be, maybe the problem will perish
> because
> >of the development taking a completely different turn...
> >
> >Best.
> >
> >Oleg
>


--=20
Carlos Rovira
Director de Tecnolog=EDa
M: +34 607 22 60 05
F:  +34 912 35 57 77
<http://www.codeoscopic.com>
CODEOSCOPIC S.A. <http://www.codeoscopic.com>
Avd. del General Per=F3n, 32
Planta 10, Puertas P-Q
28020 Madrid

--20cf30563a0388723304bbfa1d33--