You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Omar Gonzalez <om...@gmail.com> on 2012/03/02 00:12:18 UTC
Why Spark? (was Re: s:Spacer (was Re: Missing Spark components))
>
> Maybe, I am completely off base here, but exactly what is the motivation of
> the spark component set? Is it the new skinning paradigm, or is it better
> performing versions of existing components or is it a completely different
> set of components that happen to have similar names? If this is a separate
> conversation, please reply in a new thread.
>
> Thanks,
> Om
>
Personally for me the motivation to create Spark equivalents of some of
these components is the better skinning model. At least, in my opinion, I
much prefer the Spark skinning over MX. This is why I haven't done any MX
apps since Spark came out.
--
Omar Gonzalez
s9tpepper@apache.org
Apache Flex PPMC Member
RE: Why Spark? (was Re: s:Spacer (was Re: Missing Spark components))
Posted by "Michael A. Labriola" <la...@digitalprimates.net>.
>Hmmm, I think the right term would be composition-based design. In most cases dependency injection would be the pattern to use to configure the compositions.
>Sorry for being a smart-ass by the way... :)
Working on both. As soon as I can push something to the whiteboard I will.
Re: Why Spark? (was Re: s:Spacer (was Re: Missing Spark components))
Posted by Daniel Harfleet <dh...@yahoo.com>.
+1 on the DI
________________________________
From: Roland Zwaga <ro...@stackandheap.com>
To: flex-dev@incubator.apache.org
Sent: Friday, 2 March 2012, 17:46
Subject: Re: Why Spark? (was Re: s:Spacer (was Re: Missing Spark components))
>
> > One of the re-occurring discussions on this list has been the desire to
> break down components into smaller parts.
> >
> > The spark architecture goes some way to achieving this. Take scrolling,
> if you want it you wrap you group on a Scroller
> > and off you go. Same for layouts. In this way spark is far more flexible
> and superior to mx along with its skinning model.
> >
> > Spark is about writing smaller parts that can be put together to make a
> whole, instead of each component having all the
> > functionality for every scenario baked in.
> >
> > Tink
>
> I believe this paradigm is referred to as Aspect Oriented Programming
> (AOP), and IMHO, should be the way forward for Flex.
>
Hmmm, I think the right term would be composition-based design. In most
cases dependency injection would be the pattern to
use to configure the compositions.
Sorry for being a smart-ass by the way... :)
Roland
RE: Why Spark? (was Re: s:Spacer (was Re: Missing Spark components))
Posted by Aaron Miller <am...@learnatvivid.com>.
Yeah, I get it now. The term describes a specific methodology, where I understood it to mean a general concept.
Regardless, I still stand by my point. The way forward for Flex is in "providing" implementation details, rather than the more traditional approach of "sealing" them. Spark is a step in the right direction.
All the best,
-
Aaron
________________________________________
From: Michael A. Labriola [labriola@digitalprimates.net]
Sent: Friday, March 02, 2012 12:29 PM
To: flex-dev@incubator.apache.org
Subject: RE: Why Spark? (was Re: s:Spacer (was Re: Missing Spark components))
>Haha, yeah maybe you're right. I've always taken AOP as a loosely defined term (like OOP), to mean the "composition of objects with cross-cutting concerns," where DI would be a design pattern in which to achieve AOP. I didn't >realize the term was specific to the methodology. I always use DI to compose my Spark components anyways (ala skinning), so I guess it's a moot point for me. :)
I would actually think about it the other way. AOP can be used to facilitate DI.
RE: Why Spark? (was Re: s:Spacer (was Re: Missing Spark components))
Posted by "Michael A. Labriola" <la...@digitalprimates.net>.
>Haha, yeah maybe you're right. I've always taken AOP as a loosely defined term (like OOP), to mean the "composition of objects with cross-cutting concerns," where DI would be a design pattern in which to achieve AOP. I didn't >realize the term was specific to the methodology. I always use DI to compose my Spark components anyways (ala skinning), so I guess it's a moot point for me. :)
I would actually think about it the other way. AOP can be used to facilitate DI.
RE: Why Spark? (was Re: s:Spacer (was Re: Missing Spark components))
Posted by Aaron Miller <am...@learnatvivid.com>.
Haha, yeah maybe you're right. I've always taken AOP as a loosely defined term (like OOP), to mean the "composition of objects with cross-cutting concerns," where DI would be a design pattern in which to achieve AOP. I didn't realize the term was specific to the methodology. I always use DI to compose my Spark components anyways (ala skinning), so I guess it's a moot point for me. :)
Cheers!
-
Aaron
-----Original Message-----
From: Roland Zwaga [mailto:roland@stackandheap.com]
Sent: Friday, March 02, 2012 9:46 AM
To: flex-dev@incubator.apache.org
Subject: Re: Why Spark? (was Re: s:Spacer (was Re: Missing Spark components))
>
> > One of the re-occurring discussions on this list has been the desire
> > to
> break down components into smaller parts.
> >
> > The spark architecture goes some way to achieving this. Take
> > scrolling,
> if you want it you wrap you group on a Scroller
> > and off you go. Same for layouts. In this way spark is far more
> > flexible
> and superior to mx along with its skinning model.
> >
> > Spark is about writing smaller parts that can be put together to
> > make a
> whole, instead of each component having all the
> > functionality for every scenario baked in.
> >
> > Tink
>
> I believe this paradigm is referred to as Aspect Oriented Programming
> (AOP), and IMHO, should be the way forward for Flex.
>
Hmmm, I think the right term would be composition-based design. In most cases dependency injection would be the pattern to use to configure the compositions.
Sorry for being a smart-ass by the way... :)
Roland
Re: Why Spark? (was Re: s:Spacer (was Re: Missing Spark components))
Posted by Roland Zwaga <ro...@stackandheap.com>.
>
> > One of the re-occurring discussions on this list has been the desire to
> break down components into smaller parts.
> >
> > The spark architecture goes some way to achieving this. Take scrolling,
> if you want it you wrap you group on a Scroller
> > and off you go. Same for layouts. In this way spark is far more flexible
> and superior to mx along with its skinning model.
> >
> > Spark is about writing smaller parts that can be put together to make a
> whole, instead of each component having all the
> > functionality for every scenario baked in.
> >
> > Tink
>
> I believe this paradigm is referred to as Aspect Oriented Programming
> (AOP), and IMHO, should be the way forward for Flex.
>
Hmmm, I think the right term would be composition-based design. In most
cases dependency injection would be the pattern to
use to configure the compositions.
Sorry for being a smart-ass by the way... :)
Roland
RE: Why Spark? (was Re: s:Spacer (was Re: Missing Spark components))
Posted by Aaron Miller <am...@learnatvivid.com>.
> One of the re-occurring discussions on this list has been the desire to break down components into smaller parts.
>
> The spark architecture goes some way to achieving this. Take scrolling, if you want it you wrap you group on a Scroller
> and off you go. Same for layouts. In this way spark is far more flexible and superior to mx along with its skinning model.
>
> Spark is about writing smaller parts that can be put together to make a whole, instead of each component having all the
> functionality for every scenario baked in.
>
> Tink
I believe this paradigm is referred to as Aspect Oriented Programming (AOP), and IMHO, should be the way forward for Flex.
-
Aaron
Re: Why Spark? (was Re: s:Spacer (was Re: Missing Spark components))
Posted by Tink <fl...@tink.ws>.
On 1 Mar 2012, at 23:12, Omar Gonzalez wrote:
>>
>> Maybe, I am completely off base here, but exactly what is the
>> motivation of
>> the spark component set? Is it the new skinning paradigm, or is it
>> better
>> performing versions of existing components or is it a completely
>> different
>> set of components that happen to have similar names? If this is a
>> separate
>> conversation, please reply in a new thread.
>>
>> Thanks,
>> Om
>>
>
One of the re-occurring discussions on this list has been the desire
to break down components into smaller parts.
The spark architecture goes some way to achieving this. Take
scrolling, if you want it you wrap you group on a Scroller and off you
go. Same for layouts. In this way spark is far more flexible and
superior to mx along with its skinning model.
Spark is about writing smaller parts that can be put together to make
a whole, instead of each component having all the functionality for
every scenario baked in.
Tink
RE: Why Spark? (was Re: s:Spacer (was Re: Missing Spark components))
Posted by Aaron Miller <am...@learnatvivid.com>.
> To me, that can't be true. If anything, while more verbose Spark
> is infinitely friendlier to the little guy. In mx, as soon as
> you wanted to do anything different, your only choice was to
> hire a component developer to extend/copy/rewrite these classes.
> Take for example a circular or carousel list. You can create a
> layout object for a circular list in a hundred lines of code in
> Spark. Since I did this in mx, I will let you know it's a
> thousand plus. If you wanted to change the headers of a datagrid
> in mx, several hundred lines of cut and paste plus maintaining a
> component extension version to version of framework changes. In
> Spark, you change a skin. Sorry, to me spark is verbose not
> harder, and it doesn't push anyone out. Its friendlier to
> businesses who do not have the budget or dedicated staff for
> component development.
>
> BTW, if the extra lines bother someone, then create a library
> calls spark basic, which does nothing but extend list and set
> the horizontal layout... then the syntax is nearly identical.
>
> IMO, the complaining about spark doesn't address the actual
> issue. There is nothing harder about it. It is different. The
> things I mentioned earlier in this thread have absolutely
> nothing to do with how mx or spark would be used by the average
> developer. It is all internal architecture and doing so would in
> no way affect someone who didn't want to use it.
>
> Mike
^^ This times a million!
Re: Why Spark? (was Re: s:Spacer (was Re: Missing Spark components))
Posted by Cortlandt Winters <co...@cortwinters.net>.
I hope I didn't come on too strong with my tone. I agree that we're not
really differing much.
And I do agree that spark is a better architecture from a programmers point
of view and for the long term. The point that I was trying to make is that
many flex users both in the past and in the future will never develop a
single user interface component. The architecture is not so important to
them as the end user facing features. How easy it is to develop a carosel
is unimportant to them, because it's outside of what they are focused on,
regardless of architecture.
They are really php or coldfusion developers that wear a half a dozen
different hats and manage every part of their project from gathering the
content to the database, the server configuration and hosting, to the user
interface. For these folk the mx components gave them the ability to create
pretty nice user interface without having to learn about flex's internals.
It's not having to add a horizontal layout, it's that when a client says
"can you change the thumb of the scrollbar so that it's dark and the track
so that it is light" that you can do so without overriding 8 classes.
Anyway I hope I didn't waste too much of your time here. I'll shift my
energy into doing something useful rather than talking about it now.
I'm pretty happy with where flex is now really and I definitely feel
empowered to fix what I'm not happy with because of this move to Apache.
On Fri, Mar 2, 2012 at 9:40 PM, Michael A. Labriola <
labriola@digitalprimates.net> wrote:
> >...When the little guy was pushed out.
> > Most projects can't create components for the project. Most projects use
> components to build the project. That's why they are called components.
>
> I need to respond to this one separately because I think this point is
> absolutely false and incorrect.
>
> In the old framework you had a List and a HorizontalList.
>
> <mx:List/> <mx:HorizontalList/>
>
> Now you have to type this:
>
> <s:List/>
>
> <s:List>
> <s:layout>
> <s:HorizontalLayout/>
> </s:layout>
> </s:List>
>
> So, to clarify, the difference in this syntax pushes the little guy out?
> These extra lines of code are the difference between success and failure?
>
> To me, that can't be true. If anything, while more verbose Spark is
> infinitely friendlier to the little guy. In mx, as soon as you wanted to do
> anything different, your only choice was to hire a component developer to
> extend/copy/rewrite these classes. Take for example a circular or carousel
> list. You can create a layout object for a circular list in a hundred lines
> of code in Spark. Since I did this in mx, I will let you know it's a
> thousand plus. If you wanted to change the headers of a datagrid in mx,
> several hundred lines of cut and paste plus maintaining a component
> extension version to version of framework changes. In Spark, you change a
> skin. Sorry, to me spark is verbose not harder, and it doesn't push anyone
> out. Its friendlier to businesses who do not have the budget or dedicated
> staff for component development.
>
> BTW, if the extra lines bother someone, then create a library calls spark
> basic, which does nothing but extend list and set the horizontal layout...
> then the syntax is nearly identical.
>
> IMO, the complaining about spark doesn't address the actual issue. There
> is nothing harder about it. It is different. The things I mentioned earlier
> in this thread have absolutely nothing to do with how mx or spark would be
> used by the average developer. It is all internal architecture and doing
> so would in no way affect someone who didn't want to use it.
>
> Mike
>
>
>
RE: Why Spark? (was Re: s:Spacer (was Re: Missing Spark components))
Posted by "Michael A. Labriola" <la...@digitalprimates.net>.
>...When the little guy was pushed out.
> Most projects can't create components for the project. Most projects use components to build the project. That's why they are called components.
I need to respond to this one separately because I think this point is absolutely false and incorrect.
In the old framework you had a List and a HorizontalList.
<mx:List/> <mx:HorizontalList/>
Now you have to type this:
<s:List/>
<s:List>
<s:layout>
<s:HorizontalLayout/>
</s:layout>
</s:List>
So, to clarify, the difference in this syntax pushes the little guy out? These extra lines of code are the difference between success and failure?
To me, that can't be true. If anything, while more verbose Spark is infinitely friendlier to the little guy. In mx, as soon as you wanted to do anything different, your only choice was to hire a component developer to extend/copy/rewrite these classes. Take for example a circular or carousel list. You can create a layout object for a circular list in a hundred lines of code in Spark. Since I did this in mx, I will let you know it's a thousand plus. If you wanted to change the headers of a datagrid in mx, several hundred lines of cut and paste plus maintaining a component extension version to version of framework changes. In Spark, you change a skin. Sorry, to me spark is verbose not harder, and it doesn't push anyone out. Its friendlier to businesses who do not have the budget or dedicated staff for component development.
BTW, if the extra lines bother someone, then create a library calls spark basic, which does nothing but extend list and set the horizontal layout... then the syntax is nearly identical.
IMO, the complaining about spark doesn't address the actual issue. There is nothing harder about it. It is different. The things I mentioned earlier in this thread have absolutely nothing to do with how mx or spark would be used by the average developer. It is all internal architecture and doing so would in no way affect someone who didn't want to use it.
Mike
RE: Why Spark? (was Re: s:Spacer (was Re: Missing Spark components))
Posted by "Michael A. Labriola" <la...@digitalprimates.net>.
>Over engineered much?
I actually believe UIComponent is way under-engineered... hence the reason it has 14k lines of code
RE: Why Spark? (was Re: s:Spacer (was Re: Missing Spark components))
Posted by "Michael A. Labriola" <la...@digitalprimates.net>.
>one of the main roadmap objectives (someone confirm that?)
There isn't really a roadmap it's what each of us works on, commits and votes for.
>The question is: can flex include any new lib before having fixed that?
Sure, it's just going to be a constant refactoring.
>Will it take long to be achived?
Probably years
how can we organize those new lib within flex project without including it in the code framework?
>I think they need to be physically separate so the temptation to cross bounds does not occur
Re: Why Spark? (was Re: s:Spacer (was Re: Missing Spark components))
Posted by sébastien Paturel <se...@gmail.com>.
I think we all agree with that.
And the SparkSimple lib would also need to be optionnaly linked to not
penalize other projects.
The modularity of the framework has already been heavly discussed in ML
and if i get it right its one of the main roadmap objectives (someone
confirm that?)
The question is: can flex include any new lib before having fixed that?
Will it take long to be achived? how can we organize those new lib
within flex project without including it in the code framework?
Le 05/03/2012 05:21, Tony Constantinides a écrit :
> My issue with this whole issue is choice.
> Even if I select "Spark only" its loads the MX library core and Spark
> components which are based on mx.core.UIComponent.
> I love the desire for backward compatibility but GIVE ME A CHOICE to cut
> the mx framework loose. Its still loads 6 RSL
> with its loading time which people use as the excuse to dump Flex. Unless
> this is FIXED, this framework does not have a
> snowball chance of Hell of every be successful.
> Suggestion: Based Spark classes on a SPARK base framework class and not
> mx.core.UIComponent with its 14 thousand
> lines of code.
> Over engineered much?
> I already building up my own Spark custom framework rather than the one
> from Flex 4.6.
> I basically getting components only as 1/3 as big and running nice and
> fast. Although I like the Flex framework
> I like to use less functionality and get smaller components than the option
> of loading two frameworks
>
>
> On Sun, Mar 4, 2012 at 7:19 PM, Michael A. Labriola<
> labriola@digitalprimates.net> wrote:
>
>>> In Conclusion in my opinion:
>>> Spark should be the base for all components from now on.
>>> MX should die mainly because we cant use it for Mobile and it is not
>>> based on Spark (that makes the SDK more hard to maintain).
>> MX can't die. It is still used by many more projects than Spark. It will
>> need to be maintained for the foreseeable future
>>
>>> A new components list based on Spark should replace MX for easy and
>>> simple skinning use cases.
>> I think it's fine to have a rich set of skins that you can use if you want
>> all of those styling attributes. I would hate to penalize every project
>> though. It still seems to me that, like HGroup and VGroup, we can extend
>> all of these classes and put them in a library... perhaps SparkSimple. It's
>> nothing but composed versions of the other classes with a more full
>> featured skin and additional style declarations. To me that would be the
>> way to solve both issue.
>>
>>
Re: Why Spark? (was Re: s:Spacer (was Re: Missing Spark components))
Posted by Tony Constantinides <co...@gmail.com>.
My issue with this whole issue is choice.
Even if I select "Spark only" its loads the MX library core and Spark
components which are based on mx.core.UIComponent.
I love the desire for backward compatibility but GIVE ME A CHOICE to cut
the mx framework loose. Its still loads 6 RSL
with its loading time which people use as the excuse to dump Flex. Unless
this is FIXED, this framework does not have a
snowball chance of Hell of every be successful.
Suggestion: Based Spark classes on a SPARK base framework class and not
mx.core.UIComponent with its 14 thousand
lines of code.
Over engineered much?
I already building up my own Spark custom framework rather than the one
from Flex 4.6.
I basically getting components only as 1/3 as big and running nice and
fast. Although I like the Flex framework
I like to use less functionality and get smaller components than the option
of loading two frameworks
On Sun, Mar 4, 2012 at 7:19 PM, Michael A. Labriola <
labriola@digitalprimates.net> wrote:
> > In Conclusion in my opinion:
> > Spark should be the base for all components from now on.
> > MX should die mainly because we cant use it for Mobile and it is not
> > based on Spark (that makes the SDK more hard to maintain).
>
> MX can't die. It is still used by many more projects than Spark. It will
> need to be maintained for the foreseeable future
>
> > A new components list based on Spark should replace MX for easy and
> > simple skinning use cases.
>
> I think it's fine to have a rich set of skins that you can use if you want
> all of those styling attributes. I would hate to penalize every project
> though. It still seems to me that, like HGroup and VGroup, we can extend
> all of these classes and put them in a library... perhaps SparkSimple. It's
> nothing but composed versions of the other classes with a more full
> featured skin and additional style declarations. To me that would be the
> way to solve both issue.
>
>
RE: Why Spark? (was Re: s:Spacer (was Re: Missing Spark components))
Posted by Glenn Williams <in...@tinylion.co.uk>.
I agree
The main think I love about spark is the lack of
css in the skins and the ability to add my own if
I want to.
I really would rather all spark default skins had
zero CSS in there
The idea of a separate set of skins\components
that are heavily syllable with CSS is fine, just
as long as it's an optional thing.
The basic skins should really not have and css
styling at all, for me I mean.
glenn
-----Original Message-----
From: Michael A. Labriola
[mailto:labriola@digitalprimates.net]
Sent: 05 March 2012 03:20
To: flex-dev@incubator.apache.org
Subject: RE: Why Spark? (was Re: s:Spacer (was Re:
Missing Spark components))
I think it's fine to have a rich set of skins that
you can use if you want all of those styling
attributes. I would hate to penalize every project
though. It still seems to me that, like HGroup and
VGroup, we can extend all of these classes and put
them in a library... perhaps SparkSimple. It's
nothing but composed versions of the other classes
with a more full featured skin and additional
style declarations. To me that would be the way to
solve both issue.
RE: Why Spark? (was Re: s:Spacer (was Re: Missing Spark components))
Posted by "Michael A. Labriola" <la...@digitalprimates.net>.
>Why would someone continue to choose MX if the other solution we are discussing here exists?
Lots of legacy code
Re: Why Spark? (was Re: s:Spacer (was Re: Missing Spark components))
Posted by sébastien Paturel <se...@gmail.com>.
Yeah of course i meant MX dying for new components only. Would you like
to continue to implement MX version of every new component aside to spark?
Why would someone continue to choose MX if the other solution we are
discussing here exists?
I like the SparkSimple lib that you can optionnally include for
beginners or simple skinned projects.
But VGroup and HGroup are not in separated lib, and dont rely on Skins
for specialization. cf Tony answer.
Like i said in my last mail, the main thing that bother me with
simpleSpark featured skin class is that it goes in conflict with the
mobile skins. (maybe im wrong?)
Or we also need a simpleSpark for mobile. Starting from a copy of base
skin class make it more difficult to maintain.
Again, does anyone know why the copy solution has been chosen for
BorderContainer by Adobe?
Le 05/03/2012 04:19, Michael A. Labriola a écrit :
>> In Conclusion in my opinion:
>> Spark should be the base for all components from now on.
>> MX should die mainly because we cant use it for Mobile and it is not
>> based on Spark (that makes the SDK more hard to maintain).
> MX can't die. It is still used by many more projects than Spark. It will need to be maintained for the foreseeable future
>
>> A new components list based on Spark should replace MX for easy and
>> simple skinning use cases.
> I think it's fine to have a rich set of skins that you can use if you want all of those styling attributes. I would hate to penalize every project though. It still seems to me that, like HGroup and VGroup, we can extend all of these classes and put them in a library... perhaps SparkSimple. It's nothing but composed versions of the other classes with a more full featured skin and additional style declarations. To me that would be the way to solve both issue.
>
RE: Why Spark? (was Re: s:Spacer (was Re: Missing Spark components))
Posted by "Michael A. Labriola" <la...@digitalprimates.net>.
> In Conclusion in my opinion:
> Spark should be the base for all components from now on.
> MX should die mainly because we cant use it for Mobile and it is not
> based on Spark (that makes the SDK more hard to maintain).
MX can't die. It is still used by many more projects than Spark. It will need to be maintained for the foreseeable future
> A new components list based on Spark should replace MX for easy and
> simple skinning use cases.
I think it's fine to have a rich set of skins that you can use if you want all of those styling attributes. I would hate to penalize every project though. It still seems to me that, like HGroup and VGroup, we can extend all of these classes and put them in a library... perhaps SparkSimple. It's nothing but composed versions of the other classes with a more full featured skin and additional style declarations. To me that would be the way to solve both issue.
Re: Summary of all ML discussions in wiki - was: (Re: Why Spark?
(was Re: s:Spacer (was Re: Missing Spark components)))
Posted by Tomasz Maciąg | Fuse Collective <t....@fusecollective.com>.
> - how can i add a wiki page (as a simple user)?
Sign up for wiki and ask on the list for permissions.
Summary of all ML discussions in wiki - was: (Re: Why Spark? (was
Re: s:Spacer (was Re: Missing Spark components)))
Posted by sébastien Paturel <se...@gmail.com>.
Ok thanks.
But i dont feel that this wiki page reflects the heavy number of
discussion subjects already seen in ML so far.
A kind of summary of discussions, list of the point of views and
arguments as a conclusion, would be very usefull.
And if users could vote for it to show their interest would be great too.
It could be a very powerfull community tool here, aside the ML which is
hard to follow for everyone. And users dont need to get the whole
discussion but only conclusions, before giving their opinion about the
need of a feature or update and its priority level, and even their will
to participate to their implementation.
If a user wants to go deeply in the discussion he still can go back to
ML, and the wiki subject can be updated.
The more we wait for such a summary, the more it will be hard to not
loose interesting discussions from the so active ML.
It would also be usefull for new ML users, to not launch a discussion
that has already been heavely discussed before.
I think the wiki section "Random Thoughts" is more relevant for that
purpose. But again theres not much in it.
and:
- how can i add a wiki page (as a simple user)?
- am i sure that the decision board will chek this page frequently for
the roadmap decisions? (be sure i dont 'preach in the desert')
i say ' i ' but i mean any user launching a discussion in the ML.
Le 04/03/2012 13:39, almansour belleh blanco a écrit :
>> By the way, where can we find the results of every ideas that decision
> board has put aside for later votes, after all those rich discussions from
> ML?
>
>
> You can find it in the wiki, in the section decisions so far
>
>
>
Re: Why Spark? (was Re: s:Spacer (was Re: Missing Spark components))
Posted by almansour belleh blanco <za...@gmail.com>.
> By the way, where can we find the results of every ideas that decision
board has put aside for later votes, after all those rich discussions from
ML?
You can find it in the wiki, in the section decisions so far
--
Mansour Blanco
Software engineer
Stackoverflow: http://stackoverflow.com/users/612920/mansuro
Blog: zuro.blogspot.com
github: https://github.com/Mansuro
Re: Why Spark? (was Re: s:Spacer (was Re: Missing Spark components))
Posted by sébastien Paturel <se...@gmail.com>.
When you say that it is the plan, you mean that its already planned to
take it in the Apache Flex roadmap? Would be great news for MX easy
skinning lovers.
By the way, where can we find the results of every ideas that decision
board has put aside for later votes, after all those rich discussions
from ML?
About the BorderContainer Idea, its one way to do so, but if i
understand well how it is done, BorderContainer is only a
SkinnableContainer with styles properties exposed, and for which the
default skin class use the host component skin properties values with
code like: contentGroup.setStyle("styleProperty",
hostComponent.styleProperty);
am i right?
Thats a quite easy solution that would not take much work to achieve.
2 things bothers me:
- Is it a problem if with that solution we need to maintain this easy
skinning component skin class in sync with the updates of the base
component skin? (maybe not)
- More important: It means that we also need to define those custom
skins from a copy of mobile skins?
Would it be possible to use inheritance of skin classes in such a
purpose instead of starting from a copy of the base skin class? Why
Adobe did not use this solution for BorderContainer ?
Even better: would it be possible that the component, after init, acces
its current skin (default Spark, custom, or MOBILE !!) and set the
exposed values to the skin, overriding the current skin values? Maybe
the skin class, especially for mobile, could decide if some skin
settings should not be allowed to be overriden like this?
Le 04/03/2012 07:02, jude a écrit :
> That's the plan (loosely). A set of core components and then convenience
> components.
>
>
> On Sat, Mar 3, 2012 at 3:20 PM, Rob Sheely<ro...@gmail.com> wrote:
>
>> Maybe we can build on the concept of the Spark BorderContainer (quoting
>> the docs):
>>
>> The BorderContainer container provides a set of CSS styles and class
>> properties to control the border and background of the container.
>>
>> A set of subclassed Spark components with CSS styling implemented. Or more
>> specifically, a set of skins for the components that expose many properties
>> for CSS styling.
>>
>>
Re: Why Spark? (was Re: s:Spacer (was Re: Missing Spark components))
Posted by jude <fl...@gmail.com>.
That's the plan (loosely). A set of core components and then convenience
components.
On Sat, Mar 3, 2012 at 3:20 PM, Rob Sheely <ro...@gmail.com> wrote:
> Maybe we can build on the concept of the Spark BorderContainer (quoting
> the docs):
>
> The BorderContainer container provides a set of CSS styles and class
> properties to control the border and background of the container.
>
> A set of subclassed Spark components with CSS styling implemented. Or more
> specifically, a set of skins for the components that expose many properties
> for CSS styling.
>
>
Re: Why Spark? (was Re: s:Spacer (was Re: Missing Spark components))
Posted by Rob Sheely <ro...@gmail.com>.
Maybe we can build on the concept of the Spark BorderContainer (quoting the docs):
The BorderContainer container provides a set of CSS styles and class properties to control the border and background of the container.
A set of subclassed Spark components with CSS styling implemented. Or more specifically, a set of skins for the components that expose many properties for CSS styling.
On Mar 3, 2012, at 12:18 PM, Cortlandt Winters <co...@cortwinters.net> wrote:
> I totally agree with this and will try to help with it.
>
> On Sat, Mar 3, 2012 at 6:12 AM, sébastien Paturel <se...@gmail.com>wrote:
>
>> Hi all,
>> Im new to the mailing list so sorry if i do mistakes :)
>>
>> I'm personnally very concerned about the ease of learning curve of Flex
>> for new users.
>> Don't forget that the ease of use and power of this SDK suits to not only
>> enterprise scale projects. It will be more true when the cross compilation
>> to HTML5 will be a reality.
>> I intend to create a new thread about this subject in the mailing list.
>>
>> But about Spark vs MX subject, i must say that MX components were very
>> important to easely learn flex, and new spark components were harder to use
>> at first to do only simple skinning, even if the flexibility made it more
>> powerfull.
>> That said, Spark vs MX war has no sens since they refer to very different
>> use cases with pro and cons:
>> MX: Ease of use and quick simple skinning
>> Spark: Flexibility and power to create complexes skins and layout
>> We need both!
>>
>> We could say that when the Spark components complete list will be
>> finished, you will still have the possibility to choose between MX and
>> Spark for your specific projects needs.
>> BUT: The main drawback for MX components is that you cant use them for
>> Mobile!
>> Thats too bad to not have a simple quick way of skinning when working on
>> Mobile projects.
>>
>> The fact that we oppose Spark and MX is only because of flex's history.
>> But you should consider a components list dedicated to use cases for which
>> we would have chosen MX components.
>> This NEW components library would be (not like MX) based on Spark
>> components and expose basic skinning attributes easely in MXML (as MX).
>> That way a new lib equivalent to old MX could be used for Mobile.
>> And when a developper is stuck by the limitations of skinning
>> possibilities (like he would have been with MX) he still can use the Spark
>> base to freely do what he wants.
>> It should not be that much work to achieve that.
>> It must be carefully defined to manage Desktop and Mobile for easy
>> skinning components.
>>
>> In Conclusion in my opinion:
>> Spark should be the base for all components from now on.
>> MX should die mainly because we cant use it for Mobile and it is not based
>> on Spark (that makes the SDK more hard to maintain).
>> A new components list based on Spark should replace MX for easy and simple
>> skinning use cases.
>>
>> What you think of it?
>>
>> Thanks for reading
>> Seb
>>
Re: Why Spark? (was Re: s:Spacer (was Re: Missing Spark components))
Posted by Cortlandt Winters <co...@cortwinters.net>.
I totally agree with this and will try to help with it.
On Sat, Mar 3, 2012 at 6:12 AM, sébastien Paturel <se...@gmail.com>wrote:
> Hi all,
> Im new to the mailing list so sorry if i do mistakes :)
>
> I'm personnally very concerned about the ease of learning curve of Flex
> for new users.
> Don't forget that the ease of use and power of this SDK suits to not only
> enterprise scale projects. It will be more true when the cross compilation
> to HTML5 will be a reality.
> I intend to create a new thread about this subject in the mailing list.
>
> But about Spark vs MX subject, i must say that MX components were very
> important to easely learn flex, and new spark components were harder to use
> at first to do only simple skinning, even if the flexibility made it more
> powerfull.
> That said, Spark vs MX war has no sens since they refer to very different
> use cases with pro and cons:
> MX: Ease of use and quick simple skinning
> Spark: Flexibility and power to create complexes skins and layout
> We need both!
>
> We could say that when the Spark components complete list will be
> finished, you will still have the possibility to choose between MX and
> Spark for your specific projects needs.
> BUT: The main drawback for MX components is that you cant use them for
> Mobile!
> Thats too bad to not have a simple quick way of skinning when working on
> Mobile projects.
>
> The fact that we oppose Spark and MX is only because of flex's history.
> But you should consider a components list dedicated to use cases for which
> we would have chosen MX components.
> This NEW components library would be (not like MX) based on Spark
> components and expose basic skinning attributes easely in MXML (as MX).
> That way a new lib equivalent to old MX could be used for Mobile.
> And when a developper is stuck by the limitations of skinning
> possibilities (like he would have been with MX) he still can use the Spark
> base to freely do what he wants.
> It should not be that much work to achieve that.
> It must be carefully defined to manage Desktop and Mobile for easy
> skinning components.
>
> In Conclusion in my opinion:
> Spark should be the base for all components from now on.
> MX should die mainly because we cant use it for Mobile and it is not based
> on Spark (that makes the SDK more hard to maintain).
> A new components list based on Spark should replace MX for easy and simple
> skinning use cases.
>
> What you think of it?
>
> Thanks for reading
> Seb
>
Re: CSS
Posted by Dwayne Henderson <it...@gmail.com>.
Also do check out http://tinyurl.com/6n9an3o!
--Dwayne
On Sat, Mar 3, 2012 at 5:10 PM, Martin Heidegger <mh...@leichtgewicht.at>wrote:
> I have given CSS quite a bit of thoughts over time.
>
> Practically speaking: CSS is a file format that allows to set many
> properties with various detail for a huge set of components with few
> statements. Specially when I new dialect like SASS is used it allows to set
> a huge bunch of properties types. In some way this can be seen as IOC
> descriptor! This is an awesome feature! But it also offers to change and
> safe the properties at runtime:
>
> - on instantiation: fill properties
> - on style-change within: set changed properties
> - on objects signature change: set changed properties
>
> That is all closely related to a IOC Framework that offers things like
> auto dependency injection.
>
> This has the awesome architectural implication that every module has to
> offer runtime-changable properties. Yeah: modules! ...
>
> Now: That doesn't mean that the implementation is awesome. Compiling CSS
> to bytecode would certainly be a performance boost. But the bigger boost
> would be to make CSS processing optional: If one never uses CSS it should
> not be added. This would allow alternative containers to be faster while
> still utilizing the flexibility of the components. The problem is that
> right now MXML, UIComponent and CSS are hardwired. Those needed to be
> separated and that is tough. There are other engines that already are
> separate styling on a different level like Jakute[1]. They work on the
> basis of the onAdded/onRemoved event handler and I think they are a more
> usable approach within ActionScript. But you can be sure: Writing a system
> that does CSS updating (the 3 events above) efficiently (fast) is hard!
>
> And just to be sure: You can/should not use the Flex CSS 1:1 when
> targeting HTML/CSS: The properties do not contain same values (font
> handling anyone) and that can result to quite some conflicts. My personal
> experience with HTML/CSS is that trying to control things related to
> styling within the code is likely to fail as there is always extra effort
> from the developer needed to clean out quirks.
>
> yours
> Martin.
>
> [1] http://sibirjak.com/osflash/**projects/jakute-styling-**engine/<http://sibirjak.com/osflash/projects/jakute-styling-engine/>
>
>
> On 04/03/2012 00:18, Ariel Jakobovits wrote:
>
>> I mostly used CSS in the mx days. Though spark skins with fxg are easy
>> for designers, CSS can be quicker for newbies, and is relevant to future
>> HTML output.
>>
>> Thing is, I have found CSS styling to be a drag on performance. Any
>> chance we can update our compiler to apply stylesheets at compile time and
>> perhaps even disable CSS styling at runtime?
>>
>> Ariel Jakobovits
>> ajakobov@adobe.com
>> 650-350-0282
>>
>> On Mar 3, 2012, at 3:12 AM, sébastien Paturel<sebpatu.flex@gmail.com**>
>> wrote:
>>
>> Hi all,
>>> Im new to the mailing list so sorry if i do mistakes :)
>>>
>>> I'm personnally very concerned about the ease of learning curve of Flex
>>> for new users.
>>> Don't forget that the ease of use and power of this SDK suits to not
>>> only enterprise scale projects. It will be more true when the cross
>>> compilation to HTML5 will be a reality.
>>> I intend to create a new thread about this subject in the mailing list.
>>>
>>> But about Spark vs MX subject, i must say that MX components were very
>>> important to easely learn flex, and new spark components were harder to use
>>> at first to do only simple skinning, even if the flexibility made it more
>>> powerfull.
>>> That said, Spark vs MX war has no sens since they refer to very
>>> different use cases with pro and cons:
>>> MX: Ease of use and quick simple skinning
>>> Spark: Flexibility and power to create complexes skins and layout
>>> We need both!
>>>
>>> We could say that when the Spark components complete list will be
>>> finished, you will still have the possibility to choose between MX and
>>> Spark for your specific projects needs.
>>> BUT: The main drawback for MX components is that you cant use them for
>>> Mobile!
>>> Thats too bad to not have a simple quick way of skinning when working on
>>> Mobile projects.
>>>
>>> The fact that we oppose Spark and MX is only because of flex's history.
>>> But you should consider a components list dedicated to use cases for
>>> which we would have chosen MX components.
>>> This NEW components library would be (not like MX) based on Spark
>>> components and expose basic skinning attributes easely in MXML (as MX).
>>> That way a new lib equivalent to old MX could be used for Mobile.
>>> And when a developper is stuck by the limitations of skinning
>>> possibilities (like he would have been with MX) he still can use the Spark
>>> base to freely do what he wants.
>>> It should not be that much work to achieve that.
>>> It must be carefully defined to manage Desktop and Mobile for easy
>>> skinning components.
>>>
>>> In Conclusion in my opinion:
>>> Spark should be the base for all components from now on.
>>> MX should die mainly because we cant use it for Mobile and it is not
>>> based on Spark (that makes the SDK more hard to maintain).
>>> A new components list based on Spark should replace MX for easy and
>>> simple skinning use cases.
>>>
>>> What you think of it?
>>>
>>> Thanks for reading
>>> Seb
>>>
>>>
>>> Le 03/03/2012 03:02, Om a écrit :
>>>
>>>> So if paying for the flex Ide is their only revenue point, to say that
>>>>> the
>>>>> mx components were badly written is false. They hit exactly the crowd
>>>>> that
>>>>> they needed to hit with them. You may be happy with the spark
>>>>> components,
>>>>> but that's when flex died, after they were introduced. When the little
>>>>> guy
>>>>> was pushed out.
>>>>>
>>>>> This. I love the spark architecture, but that's because I have used
>>>> mx
>>>> exhaustively (pushing its limits) and I know all the pain points. So,
>>>> moving to the Spark architecture was a logical progression for me.
>>>>
>>>> But, this also means that new folks that start using Flex 4+ for the
>>>> first
>>>> time, dont have an easy entry point. Changing the look and feel of an
>>>> app
>>>> - which was extremely easy in mx is now a chore. I know and have worked
>>>> with design firms that created new application styles using the 'Flex 3
>>>> Style Explorer' - which was an online flex application. Thats it.
>>>> Thats
>>>> how easy it was to work with mx components.
>>>>
>>>> I dont know if the answer is better tooling (Catalyst, Design view,
>>>> etc.)
>>>> or if it is a question of more exhaustive documentation, working
>>>> examples,
>>>> tutorials, etc. Or even a change to the way Spark approaches skinning
>>>> and
>>>> customizations.
>>>>
>>>> This kind of developer outreach (especially for newbies) should also be
>>>> a
>>>> goal for the Apache Flex project, IMHO.
>>>>
>>>> Thanks,
>>>> Om
>>>>
>>>>
>>>> On Fri, Mar 2, 2012 at 5:10 PM, Cortlandt Winters<co...@cortwinters.net>
>>>> **wrote:
>>>>
>>>> Thank you, Micheal for a great response.
>>>>>
>>>>> I think what we have here are two radically different use cases.
>>>>>
>>>>> On the one hand flex needs to be a good enough framework that a team of
>>>>> three can create something of real value on a 10-30 thousand dollar
>>>>> budget
>>>>> in a few months. Without rock stars.
>>>>>
>>>>> On the other hand how can a team of 100 which was probably 10 times
>>>>> the
>>>>> number of core flex developers, do world class stuff if the sweet spot
>>>>> is
>>>>> for a team of 3-5?
>>>>>
>>>>> But frankly from Macromedia/Allaire and Adobe's standpoint, there are
>>>>> probably a thousand times more users
>>>>> in the first scenario than the second, maybe ten thousand more.
>>>>>
>>>>> So if paying for the flex Ide is their only revenue point, to say that
>>>>> the
>>>>> mx components were badly written is false. They hit exactly the crowd
>>>>> that
>>>>> they needed to hit with them. You may be happy with the spark
>>>>> components,
>>>>> but that's when flex died, after they were introduced. When the little
>>>>> guy
>>>>> was pushed out.
>>>>>
>>>>> I reiterate that there is not a single complete commercial spark
>>>>> component
>>>>> skin on any marketplace after two years. Mx skins weren't in the 100's
>>>>> but
>>>>> there were 30 or 40 attempts.
>>>>>
>>>>> Frankly, If you have a hundred developers, you had more than enough
>>>>> resources to take the core as3 language and build your own framework
>>>>> that
>>>>> covers this larger set of world class issues with a less feature rich
>>>>> end
>>>>> point.
>>>>>
>>>>> I have no doubt that given this experience you are well suited to
>>>>> guide the
>>>>> core framework internals in the future, but not if you can't recognize
>>>>> that
>>>>> it's a niche case and that mx covered 95% of most user's needs.
>>>>>
>>>>> Most projects can't create components for the project. Most projects
>>>>> use
>>>>> components to build the project. That's why they are called components.
>>>>> They are reusable. Most projects are focused on the content and use the
>>>>> components to display the content.
>>>>>
>>>>>
>>>>> On Fri, Mar 2, 2012 at 9:36 AM, Michael A. Labriola<
>>>>> labriola@digitalprimates.net> wrote:
>>>>>
>>>>> Ok. I'm totally willing to believe you and to think that I'm missing
>>>>>>>
>>>>>> something here but I think you have to explain that a little bit more.
>>>>>>
>>>>> What
>>>>>
>>>>>> kind of apps were these? Were they super detailed subcomponents? Or
>>>>>> was a
>>>>>>
>>>>>>> combobox something that needed an item renderer? What other UI set
>>>>>>> are
>>>>>>>
>>>>>> you
>>>>>
>>>>>> comparing them with?
>>>>>>
>>>>>> The need to build and extend these components for large enterprises
>>>>>>
>>>>>> Or to put a hard number on it how big were these projects? Two
>>>>>>> people?
>>>>>>>
>>>>>> ten? or more?
>>>>>> Dozens sometimes hundreds.
>>>>>>
>>>>>> But point me to a better set of standard ui components and make the
>>>>>>> case
>>>>>>>
>>>>>> for them, because then we can emulate them.
>>>>>> Its not that there is a better set. The point is that there are major
>>>>>> improvements that can be made
>>>>>>
>>>>>> How did you like awt or swing or the microsoft native component sets?
>>>>>>>
>>>>>> Did
>>>>>
>>>>>> you use the silverlight components at all? Tcl did the job?
>>>>>> Although I didn't always like their internals, the quantity and
>>>>>> general
>>>>>> extensibility of many of the Silverlight components was quite nice
>>>>>>
>>>>>> Did spark solve your problems? Please tell me how removing the
>>>>>>> ability
>>>>>>>
>>>>>> to
>>>>>
>>>>>> change simple things like label positioning and styles, base colors,
>>>>>> enabled something to solve your problems?
>>>>>> It solves many of the problems simply by delegating the instantiation
>>>>>> of
>>>>>> the visual components to a separate, swappable class
>>>>>>
>>>>>> Things can always be better, but what then, in your mind is the gold
>>>>>>>
>>>>>> standard that we should strive for? Because in my experience, the mx
>>>>>> components were the best out of the box stuff that I've been able to
>>>>>> work
>>>>>> with.
>>>>>> The mx components were the multi-tool of the world. When you buy a
>>>>>>
>>>>> kitchen
>>>>>
>>>>>> appliance that does -everything- you often find that it doesn't do
>>>>>> -anything- with expertise. We spent millions of dollars doing nothing
>>>>>> but
>>>>>> changing the SDK so we could begin to extend it. Components being
>>>>>> created
>>>>>> inside of 500 line methods which access private variables so you can
>>>>>>
>>>>> never
>>>>>
>>>>>> change the implementations via subclass. Hardcoded dependencies, hell,
>>>>>>
>>>>> even
>>>>>
>>>>>> the methodology by which createChildren checks for the existence of a
>>>>>>
>>>>> child
>>>>>
>>>>>> before creating a new one so that you have this primitive sort of
>>>>>>
>>>>> override
>>>>>
>>>>>> mechanism. All code smells.
>>>>>>
>>>>>> You had to recompile the whole sdk to add minimal functionality?
>>>>>>>
>>>>>> We maintain nearly 15 copies of the sdk each modified in different
>>>>>> ways
>>>>>>
>>>>> to
>>>>>
>>>>>> suit client needs. Try to fix the i18n issues of the framework when
>>>>>> internally every object is bound to a hard date instance or uses a
>>>>>> set of
>>>>>> string utilities which don't work 100% with 3/5ths of the world's
>>>>>>
>>>>> languages
>>>>>
>>>>>> and you will quickly find that, to change one of those pieces (due to
>>>>>> coupling and hard dependencies) you have to override an entire branch
>>>>>> of
>>>>>> the framework class by class, not just a node.
>>>>>>
>>>>>>
>>>>>>
>>
>
Re: CSS
Posted by Martin Heidegger <mh...@leichtgewicht.at>.
I have given CSS quite a bit of thoughts over time.
Practically speaking: CSS is a file format that allows to set many
properties with various detail for a huge set of components with few
statements. Specially when I new dialect like SASS is used it allows to
set a huge bunch of properties types. In some way this can be seen as
IOC descriptor! This is an awesome feature! But it also offers to change
and safe the properties at runtime:
- on instantiation: fill properties
- on style-change within: set changed properties
- on objects signature change: set changed properties
That is all closely related to a IOC Framework that offers things like
auto dependency injection.
This has the awesome architectural implication that every module has to
offer runtime-changable properties. Yeah: modules! ...
Now: That doesn't mean that the implementation is awesome. Compiling CSS
to bytecode would certainly be a performance boost. But the bigger boost
would be to make CSS processing optional: If one never uses CSS it
should not be added. This would allow alternative containers to be
faster while still utilizing the flexibility of the components. The
problem is that right now MXML, UIComponent and CSS are hardwired. Those
needed to be separated and that is tough. There are other engines that
already are separate styling on a different level like Jakute[1]. They
work on the basis of the onAdded/onRemoved event handler and I think
they are a more usable approach within ActionScript. But you can be
sure: Writing a system that does CSS updating (the 3 events above)
efficiently (fast) is hard!
And just to be sure: You can/should not use the Flex CSS 1:1 when
targeting HTML/CSS: The properties do not contain same values (font
handling anyone) and that can result to quite some conflicts. My
personal experience with HTML/CSS is that trying to control things
related to styling within the code is likely to fail as there is always
extra effort from the developer needed to clean out quirks.
yours
Martin.
[1] http://sibirjak.com/osflash/projects/jakute-styling-engine/
On 04/03/2012 00:18, Ariel Jakobovits wrote:
> I mostly used CSS in the mx days. Though spark skins with fxg are easy for designers, CSS can be quicker for newbies, and is relevant to future HTML output.
>
> Thing is, I have found CSS styling to be a drag on performance. Any chance we can update our compiler to apply stylesheets at compile time and perhaps even disable CSS styling at runtime?
>
> Ariel Jakobovits
> ajakobov@adobe.com
> 650-350-0282
>
> On Mar 3, 2012, at 3:12 AM, sébastien Paturel<se...@gmail.com> wrote:
>
>> Hi all,
>> Im new to the mailing list so sorry if i do mistakes :)
>>
>> I'm personnally very concerned about the ease of learning curve of Flex for new users.
>> Don't forget that the ease of use and power of this SDK suits to not only enterprise scale projects. It will be more true when the cross compilation to HTML5 will be a reality.
>> I intend to create a new thread about this subject in the mailing list.
>>
>> But about Spark vs MX subject, i must say that MX components were very important to easely learn flex, and new spark components were harder to use at first to do only simple skinning, even if the flexibility made it more powerfull.
>> That said, Spark vs MX war has no sens since they refer to very different use cases with pro and cons:
>> MX: Ease of use and quick simple skinning
>> Spark: Flexibility and power to create complexes skins and layout
>> We need both!
>>
>> We could say that when the Spark components complete list will be finished, you will still have the possibility to choose between MX and Spark for your specific projects needs.
>> BUT: The main drawback for MX components is that you cant use them for Mobile!
>> Thats too bad to not have a simple quick way of skinning when working on Mobile projects.
>>
>> The fact that we oppose Spark and MX is only because of flex's history.
>> But you should consider a components list dedicated to use cases for which we would have chosen MX components.
>> This NEW components library would be (not like MX) based on Spark components and expose basic skinning attributes easely in MXML (as MX).
>> That way a new lib equivalent to old MX could be used for Mobile.
>> And when a developper is stuck by the limitations of skinning possibilities (like he would have been with MX) he still can use the Spark base to freely do what he wants.
>> It should not be that much work to achieve that.
>> It must be carefully defined to manage Desktop and Mobile for easy skinning components.
>>
>> In Conclusion in my opinion:
>> Spark should be the base for all components from now on.
>> MX should die mainly because we cant use it for Mobile and it is not based on Spark (that makes the SDK more hard to maintain).
>> A new components list based on Spark should replace MX for easy and simple skinning use cases.
>>
>> What you think of it?
>>
>> Thanks for reading
>> Seb
>>
>>
>> Le 03/03/2012 03:02, Om a écrit :
>>>> So if paying for the flex Ide is their only revenue point, to say that the
>>>> mx components were badly written is false. They hit exactly the crowd that
>>>> they needed to hit with them. You may be happy with the spark components,
>>>> but that's when flex died, after they were introduced. When the little guy
>>>> was pushed out.
>>>>
>>> This. I love the spark architecture, but that's because I have used mx
>>> exhaustively (pushing its limits) and I know all the pain points. So,
>>> moving to the Spark architecture was a logical progression for me.
>>>
>>> But, this also means that new folks that start using Flex 4+ for the first
>>> time, dont have an easy entry point. Changing the look and feel of an app
>>> - which was extremely easy in mx is now a chore. I know and have worked
>>> with design firms that created new application styles using the 'Flex 3
>>> Style Explorer' - which was an online flex application. Thats it. Thats
>>> how easy it was to work with mx components.
>>>
>>> I dont know if the answer is better tooling (Catalyst, Design view, etc.)
>>> or if it is a question of more exhaustive documentation, working examples,
>>> tutorials, etc. Or even a change to the way Spark approaches skinning and
>>> customizations.
>>>
>>> This kind of developer outreach (especially for newbies) should also be a
>>> goal for the Apache Flex project, IMHO.
>>>
>>> Thanks,
>>> Om
>>>
>>>
>>> On Fri, Mar 2, 2012 at 5:10 PM, Cortlandt Winters<co...@cortwinters.net>wrote:
>>>
>>>> Thank you, Micheal for a great response.
>>>>
>>>> I think what we have here are two radically different use cases.
>>>>
>>>> On the one hand flex needs to be a good enough framework that a team of
>>>> three can create something of real value on a 10-30 thousand dollar budget
>>>> in a few months. Without rock stars.
>>>>
>>>> On the other hand how can a team of 100 which was probably 10 times the
>>>> number of core flex developers, do world class stuff if the sweet spot is
>>>> for a team of 3-5?
>>>>
>>>> But frankly from Macromedia/Allaire and Adobe's standpoint, there are
>>>> probably a thousand times more users
>>>> in the first scenario than the second, maybe ten thousand more.
>>>>
>>>> So if paying for the flex Ide is their only revenue point, to say that the
>>>> mx components were badly written is false. They hit exactly the crowd that
>>>> they needed to hit with them. You may be happy with the spark components,
>>>> but that's when flex died, after they were introduced. When the little guy
>>>> was pushed out.
>>>>
>>>> I reiterate that there is not a single complete commercial spark component
>>>> skin on any marketplace after two years. Mx skins weren't in the 100's but
>>>> there were 30 or 40 attempts.
>>>>
>>>> Frankly, If you have a hundred developers, you had more than enough
>>>> resources to take the core as3 language and build your own framework that
>>>> covers this larger set of world class issues with a less feature rich end
>>>> point.
>>>>
>>>> I have no doubt that given this experience you are well suited to guide the
>>>> core framework internals in the future, but not if you can't recognize that
>>>> it's a niche case and that mx covered 95% of most user's needs.
>>>>
>>>> Most projects can't create components for the project. Most projects use
>>>> components to build the project. That's why they are called components.
>>>> They are reusable. Most projects are focused on the content and use the
>>>> components to display the content.
>>>>
>>>>
>>>> On Fri, Mar 2, 2012 at 9:36 AM, Michael A. Labriola<
>>>> labriola@digitalprimates.net> wrote:
>>>>
>>>>>> Ok. I'm totally willing to believe you and to think that I'm missing
>>>>> something here but I think you have to explain that a little bit more.
>>>> What
>>>>> kind of apps were these? Were they super detailed subcomponents? Or was a
>>>>>> combobox something that needed an item renderer? What other UI set are
>>>> you
>>>>> comparing them with?
>>>>>
>>>>> The need to build and extend these components for large enterprises
>>>>>
>>>>>> Or to put a hard number on it how big were these projects? Two people?
>>>>> ten? or more?
>>>>> Dozens sometimes hundreds.
>>>>>
>>>>>> But point me to a better set of standard ui components and make the case
>>>>> for them, because then we can emulate them.
>>>>> Its not that there is a better set. The point is that there are major
>>>>> improvements that can be made
>>>>>
>>>>>> How did you like awt or swing or the microsoft native component sets?
>>>> Did
>>>>> you use the silverlight components at all? Tcl did the job?
>>>>> Although I didn't always like their internals, the quantity and general
>>>>> extensibility of many of the Silverlight components was quite nice
>>>>>
>>>>>> Did spark solve your problems? Please tell me how removing the ability
>>>> to
>>>>> change simple things like label positioning and styles, base colors,
>>>>> enabled something to solve your problems?
>>>>> It solves many of the problems simply by delegating the instantiation of
>>>>> the visual components to a separate, swappable class
>>>>>
>>>>>> Things can always be better, but what then, in your mind is the gold
>>>>> standard that we should strive for? Because in my experience, the mx
>>>>> components were the best out of the box stuff that I've been able to work
>>>>> with.
>>>>> The mx components were the multi-tool of the world. When you buy a
>>>> kitchen
>>>>> appliance that does -everything- you often find that it doesn't do
>>>>> -anything- with expertise. We spent millions of dollars doing nothing but
>>>>> changing the SDK so we could begin to extend it. Components being created
>>>>> inside of 500 line methods which access private variables so you can
>>>> never
>>>>> change the implementations via subclass. Hardcoded dependencies, hell,
>>>> even
>>>>> the methodology by which createChildren checks for the existence of a
>>>> child
>>>>> before creating a new one so that you have this primitive sort of
>>>> override
>>>>> mechanism. All code smells.
>>>>>
>>>>>> You had to recompile the whole sdk to add minimal functionality?
>>>>> We maintain nearly 15 copies of the sdk each modified in different ways
>>>> to
>>>>> suit client needs. Try to fix the i18n issues of the framework when
>>>>> internally every object is bound to a hard date instance or uses a set of
>>>>> string utilities which don't work 100% with 3/5ths of the world's
>>>> languages
>>>>> and you will quickly find that, to change one of those pieces (due to
>>>>> coupling and hard dependencies) you have to override an entire branch of
>>>>> the framework class by class, not just a node.
>>>>>
>>>>>
>
CSS
Posted by Ariel Jakobovits <ar...@yahoo.com>.
I mostly used CSS in the mx days. Though spark skins with fxg are easy for designers, CSS can be quicker for newbies, and is relevant to future HTML output.
Thing is, I have found CSS styling to be a drag on performance. Any chance we can update our compiler to apply stylesheets at compile time and perhaps even disable CSS styling at runtime?
Ariel Jakobovits
ajakobov@adobe.com
650-350-0282
On Mar 3, 2012, at 3:12 AM, sébastien Paturel <se...@gmail.com> wrote:
> Hi all,
> Im new to the mailing list so sorry if i do mistakes :)
>
> I'm personnally very concerned about the ease of learning curve of Flex for new users.
> Don't forget that the ease of use and power of this SDK suits to not only enterprise scale projects. It will be more true when the cross compilation to HTML5 will be a reality.
> I intend to create a new thread about this subject in the mailing list.
>
> But about Spark vs MX subject, i must say that MX components were very important to easely learn flex, and new spark components were harder to use at first to do only simple skinning, even if the flexibility made it more powerfull.
> That said, Spark vs MX war has no sens since they refer to very different use cases with pro and cons:
> MX: Ease of use and quick simple skinning
> Spark: Flexibility and power to create complexes skins and layout
> We need both!
>
> We could say that when the Spark components complete list will be finished, you will still have the possibility to choose between MX and Spark for your specific projects needs.
> BUT: The main drawback for MX components is that you cant use them for Mobile!
> Thats too bad to not have a simple quick way of skinning when working on Mobile projects.
>
> The fact that we oppose Spark and MX is only because of flex's history.
> But you should consider a components list dedicated to use cases for which we would have chosen MX components.
> This NEW components library would be (not like MX) based on Spark components and expose basic skinning attributes easely in MXML (as MX).
> That way a new lib equivalent to old MX could be used for Mobile.
> And when a developper is stuck by the limitations of skinning possibilities (like he would have been with MX) he still can use the Spark base to freely do what he wants.
> It should not be that much work to achieve that.
> It must be carefully defined to manage Desktop and Mobile for easy skinning components.
>
> In Conclusion in my opinion:
> Spark should be the base for all components from now on.
> MX should die mainly because we cant use it for Mobile and it is not based on Spark (that makes the SDK more hard to maintain).
> A new components list based on Spark should replace MX for easy and simple skinning use cases.
>
> What you think of it?
>
> Thanks for reading
> Seb
>
>
> Le 03/03/2012 03:02, Om a écrit :
>>> So if paying for the flex Ide is their only revenue point, to say that the
>>> mx components were badly written is false. They hit exactly the crowd that
>>> they needed to hit with them. You may be happy with the spark components,
>>> but that's when flex died, after they were introduced. When the little guy
>>> was pushed out.
>>>
>> This. I love the spark architecture, but that's because I have used mx
>> exhaustively (pushing its limits) and I know all the pain points. So,
>> moving to the Spark architecture was a logical progression for me.
>>
>> But, this also means that new folks that start using Flex 4+ for the first
>> time, dont have an easy entry point. Changing the look and feel of an app
>> - which was extremely easy in mx is now a chore. I know and have worked
>> with design firms that created new application styles using the 'Flex 3
>> Style Explorer' - which was an online flex application. Thats it. Thats
>> how easy it was to work with mx components.
>>
>> I dont know if the answer is better tooling (Catalyst, Design view, etc.)
>> or if it is a question of more exhaustive documentation, working examples,
>> tutorials, etc. Or even a change to the way Spark approaches skinning and
>> customizations.
>>
>> This kind of developer outreach (especially for newbies) should also be a
>> goal for the Apache Flex project, IMHO.
>>
>> Thanks,
>> Om
>>
>>
>> On Fri, Mar 2, 2012 at 5:10 PM, Cortlandt Winters<co...@cortwinters.net>wrote:
>>
>>> Thank you, Micheal for a great response.
>>>
>>> I think what we have here are two radically different use cases.
>>>
>>> On the one hand flex needs to be a good enough framework that a team of
>>> three can create something of real value on a 10-30 thousand dollar budget
>>> in a few months. Without rock stars.
>>>
>>> On the other hand how can a team of 100 which was probably 10 times the
>>> number of core flex developers, do world class stuff if the sweet spot is
>>> for a team of 3-5?
>>>
>>> But frankly from Macromedia/Allaire and Adobe's standpoint, there are
>>> probably a thousand times more users
>>> in the first scenario than the second, maybe ten thousand more.
>>>
>>> So if paying for the flex Ide is their only revenue point, to say that the
>>> mx components were badly written is false. They hit exactly the crowd that
>>> they needed to hit with them. You may be happy with the spark components,
>>> but that's when flex died, after they were introduced. When the little guy
>>> was pushed out.
>>>
>>> I reiterate that there is not a single complete commercial spark component
>>> skin on any marketplace after two years. Mx skins weren't in the 100's but
>>> there were 30 or 40 attempts.
>>>
>>> Frankly, If you have a hundred developers, you had more than enough
>>> resources to take the core as3 language and build your own framework that
>>> covers this larger set of world class issues with a less feature rich end
>>> point.
>>>
>>> I have no doubt that given this experience you are well suited to guide the
>>> core framework internals in the future, but not if you can't recognize that
>>> it's a niche case and that mx covered 95% of most user's needs.
>>>
>>> Most projects can't create components for the project. Most projects use
>>> components to build the project. That's why they are called components.
>>> They are reusable. Most projects are focused on the content and use the
>>> components to display the content.
>>>
>>>
>>> On Fri, Mar 2, 2012 at 9:36 AM, Michael A. Labriola<
>>> labriola@digitalprimates.net> wrote:
>>>
>>>>> Ok. I'm totally willing to believe you and to think that I'm missing
>>>> something here but I think you have to explain that a little bit more.
>>> What
>>>> kind of apps were these? Were they super detailed subcomponents? Or was a
>>>>> combobox something that needed an item renderer? What other UI set are
>>> you
>>>> comparing them with?
>>>>
>>>> The need to build and extend these components for large enterprises
>>>>
>>>>> Or to put a hard number on it how big were these projects? Two people?
>>>> ten? or more?
>>>> Dozens sometimes hundreds.
>>>>
>>>>> But point me to a better set of standard ui components and make the case
>>>> for them, because then we can emulate them.
>>>> Its not that there is a better set. The point is that there are major
>>>> improvements that can be made
>>>>
>>>>> How did you like awt or swing or the microsoft native component sets?
>>> Did
>>>> you use the silverlight components at all? Tcl did the job?
>>>> Although I didn't always like their internals, the quantity and general
>>>> extensibility of many of the Silverlight components was quite nice
>>>>
>>>>> Did spark solve your problems? Please tell me how removing the ability
>>> to
>>>> change simple things like label positioning and styles, base colors,
>>>> enabled something to solve your problems?
>>>> It solves many of the problems simply by delegating the instantiation of
>>>> the visual components to a separate, swappable class
>>>>
>>>>> Things can always be better, but what then, in your mind is the gold
>>>> standard that we should strive for? Because in my experience, the mx
>>>> components were the best out of the box stuff that I've been able to work
>>>> with.
>>>> The mx components were the multi-tool of the world. When you buy a
>>> kitchen
>>>> appliance that does -everything- you often find that it doesn't do
>>>> -anything- with expertise. We spent millions of dollars doing nothing but
>>>> changing the SDK so we could begin to extend it. Components being created
>>>> inside of 500 line methods which access private variables so you can
>>> never
>>>> change the implementations via subclass. Hardcoded dependencies, hell,
>>> even
>>>> the methodology by which createChildren checks for the existence of a
>>> child
>>>> before creating a new one so that you have this primitive sort of
>>> override
>>>> mechanism. All code smells.
>>>>
>>>>> You had to recompile the whole sdk to add minimal functionality?
>>>> We maintain nearly 15 copies of the sdk each modified in different ways
>>> to
>>>> suit client needs. Try to fix the i18n issues of the framework when
>>>> internally every object is bound to a hard date instance or uses a set of
>>>> string utilities which don't work 100% with 3/5ths of the world's
>>> languages
>>>> and you will quickly find that, to change one of those pieces (due to
>>>> coupling and hard dependencies) you have to override an entire branch of
>>>> the framework class by class, not just a node.
>>>>
>>>>
>
Re: Why Spark? (was Re: s:Spacer (was Re: Missing Spark components))
Posted by sébastien Paturel <se...@gmail.com>.
Hi all,
Im new to the mailing list so sorry if i do mistakes :)
I'm personnally very concerned about the ease of learning curve of Flex
for new users.
Don't forget that the ease of use and power of this SDK suits to not
only enterprise scale projects. It will be more true when the cross
compilation to HTML5 will be a reality.
I intend to create a new thread about this subject in the mailing list.
But about Spark vs MX subject, i must say that MX components were very
important to easely learn flex, and new spark components were harder to
use at first to do only simple skinning, even if the flexibility made it
more powerfull.
That said, Spark vs MX war has no sens since they refer to very
different use cases with pro and cons:
MX: Ease of use and quick simple skinning
Spark: Flexibility and power to create complexes skins and layout
We need both!
We could say that when the Spark components complete list will be
finished, you will still have the possibility to choose between MX and
Spark for your specific projects needs.
BUT: The main drawback for MX components is that you cant use them for
Mobile!
Thats too bad to not have a simple quick way of skinning when working on
Mobile projects.
The fact that we oppose Spark and MX is only because of flex's history.
But you should consider a components list dedicated to use cases for
which we would have chosen MX components.
This NEW components library would be (not like MX) based on Spark
components and expose basic skinning attributes easely in MXML (as MX).
That way a new lib equivalent to old MX could be used for Mobile.
And when a developper is stuck by the limitations of skinning
possibilities (like he would have been with MX) he still can use the
Spark base to freely do what he wants.
It should not be that much work to achieve that.
It must be carefully defined to manage Desktop and Mobile for easy
skinning components.
In Conclusion in my opinion:
Spark should be the base for all components from now on.
MX should die mainly because we cant use it for Mobile and it is not
based on Spark (that makes the SDK more hard to maintain).
A new components list based on Spark should replace MX for easy and
simple skinning use cases.
What you think of it?
Thanks for reading
Seb
Le 03/03/2012 03:02, Om a écrit :
>> So if paying for the flex Ide is their only revenue point, to say that the
>> mx components were badly written is false. They hit exactly the crowd that
>> they needed to hit with them. You may be happy with the spark components,
>> but that's when flex died, after they were introduced. When the little guy
>> was pushed out.
>>
> This. I love the spark architecture, but that's because I have used mx
> exhaustively (pushing its limits) and I know all the pain points. So,
> moving to the Spark architecture was a logical progression for me.
>
> But, this also means that new folks that start using Flex 4+ for the first
> time, dont have an easy entry point. Changing the look and feel of an app
> - which was extremely easy in mx is now a chore. I know and have worked
> with design firms that created new application styles using the 'Flex 3
> Style Explorer' - which was an online flex application. Thats it. Thats
> how easy it was to work with mx components.
>
> I dont know if the answer is better tooling (Catalyst, Design view, etc.)
> or if it is a question of more exhaustive documentation, working examples,
> tutorials, etc. Or even a change to the way Spark approaches skinning and
> customizations.
>
> This kind of developer outreach (especially for newbies) should also be a
> goal for the Apache Flex project, IMHO.
>
> Thanks,
> Om
>
>
> On Fri, Mar 2, 2012 at 5:10 PM, Cortlandt Winters<co...@cortwinters.net>wrote:
>
>> Thank you, Micheal for a great response.
>>
>> I think what we have here are two radically different use cases.
>>
>> On the one hand flex needs to be a good enough framework that a team of
>> three can create something of real value on a 10-30 thousand dollar budget
>> in a few months. Without rock stars.
>>
>> On the other hand how can a team of 100 which was probably 10 times the
>> number of core flex developers, do world class stuff if the sweet spot is
>> for a team of 3-5?
>>
>> But frankly from Macromedia/Allaire and Adobe's standpoint, there are
>> probably a thousand times more users
>> in the first scenario than the second, maybe ten thousand more.
>>
>> So if paying for the flex Ide is their only revenue point, to say that the
>> mx components were badly written is false. They hit exactly the crowd that
>> they needed to hit with them. You may be happy with the spark components,
>> but that's when flex died, after they were introduced. When the little guy
>> was pushed out.
>>
>> I reiterate that there is not a single complete commercial spark component
>> skin on any marketplace after two years. Mx skins weren't in the 100's but
>> there were 30 or 40 attempts.
>>
>> Frankly, If you have a hundred developers, you had more than enough
>> resources to take the core as3 language and build your own framework that
>> covers this larger set of world class issues with a less feature rich end
>> point.
>>
>> I have no doubt that given this experience you are well suited to guide the
>> core framework internals in the future, but not if you can't recognize that
>> it's a niche case and that mx covered 95% of most user's needs.
>>
>> Most projects can't create components for the project. Most projects use
>> components to build the project. That's why they are called components.
>> They are reusable. Most projects are focused on the content and use the
>> components to display the content.
>>
>>
>> On Fri, Mar 2, 2012 at 9:36 AM, Michael A. Labriola<
>> labriola@digitalprimates.net> wrote:
>>
>>>> Ok. I'm totally willing to believe you and to think that I'm missing
>>> something here but I think you have to explain that a little bit more.
>> What
>>> kind of apps were these? Were they super detailed subcomponents? Or was a
>>>> combobox something that needed an item renderer? What other UI set are
>> you
>>> comparing them with?
>>>
>>> The need to build and extend these components for large enterprises
>>>
>>>> Or to put a hard number on it how big were these projects? Two people?
>>> ten? or more?
>>> Dozens sometimes hundreds.
>>>
>>>> But point me to a better set of standard ui components and make the case
>>> for them, because then we can emulate them.
>>> Its not that there is a better set. The point is that there are major
>>> improvements that can be made
>>>
>>>> How did you like awt or swing or the microsoft native component sets?
>> Did
>>> you use the silverlight components at all? Tcl did the job?
>>> Although I didn't always like their internals, the quantity and general
>>> extensibility of many of the Silverlight components was quite nice
>>>
>>>> Did spark solve your problems? Please tell me how removing the ability
>> to
>>> change simple things like label positioning and styles, base colors,
>>> enabled something to solve your problems?
>>> It solves many of the problems simply by delegating the instantiation of
>>> the visual components to a separate, swappable class
>>>
>>>> Things can always be better, but what then, in your mind is the gold
>>> standard that we should strive for? Because in my experience, the mx
>>> components were the best out of the box stuff that I've been able to work
>>> with.
>>> The mx components were the multi-tool of the world. When you buy a
>> kitchen
>>> appliance that does -everything- you often find that it doesn't do
>>> -anything- with expertise. We spent millions of dollars doing nothing but
>>> changing the SDK so we could begin to extend it. Components being created
>>> inside of 500 line methods which access private variables so you can
>> never
>>> change the implementations via subclass. Hardcoded dependencies, hell,
>> even
>>> the methodology by which createChildren checks for the existence of a
>> child
>>> before creating a new one so that you have this primitive sort of
>> override
>>> mechanism. All code smells.
>>>
>>>> You had to recompile the whole sdk to add minimal functionality?
>>> We maintain nearly 15 copies of the sdk each modified in different ways
>> to
>>> suit client needs. Try to fix the i18n issues of the framework when
>>> internally every object is bound to a hard date instance or uses a set of
>>> string utilities which don't work 100% with 3/5ths of the world's
>> languages
>>> and you will quickly find that, to change one of those pieces (due to
>>> coupling and hard dependencies) you have to override an entire branch of
>>> the framework class by class, not just a node.
>>>
>>>
Re: Why Spark? (was Re: s:Spacer (was Re: Missing Spark components))
Posted by Om <bi...@gmail.com>.
>
> So if paying for the flex Ide is their only revenue point, to say that the
> mx components were badly written is false. They hit exactly the crowd that
> they needed to hit with them. You may be happy with the spark components,
> but that's when flex died, after they were introduced. When the little guy
> was pushed out.
>
This. I love the spark architecture, but that's because I have used mx
exhaustively (pushing its limits) and I know all the pain points. So,
moving to the Spark architecture was a logical progression for me.
But, this also means that new folks that start using Flex 4+ for the first
time, dont have an easy entry point. Changing the look and feel of an app
- which was extremely easy in mx is now a chore. I know and have worked
with design firms that created new application styles using the 'Flex 3
Style Explorer' - which was an online flex application. Thats it. Thats
how easy it was to work with mx components.
I dont know if the answer is better tooling (Catalyst, Design view, etc.)
or if it is a question of more exhaustive documentation, working examples,
tutorials, etc. Or even a change to the way Spark approaches skinning and
customizations.
This kind of developer outreach (especially for newbies) should also be a
goal for the Apache Flex project, IMHO.
Thanks,
Om
On Fri, Mar 2, 2012 at 5:10 PM, Cortlandt Winters <co...@cortwinters.net>wrote:
> Thank you, Micheal for a great response.
>
> I think what we have here are two radically different use cases.
>
> On the one hand flex needs to be a good enough framework that a team of
> three can create something of real value on a 10-30 thousand dollar budget
> in a few months. Without rock stars.
>
> On the other hand how can a team of 100 which was probably 10 times the
> number of core flex developers, do world class stuff if the sweet spot is
> for a team of 3-5?
>
> But frankly from Macromedia/Allaire and Adobe's standpoint, there are
> probably a thousand times more users
> in the first scenario than the second, maybe ten thousand more.
>
> So if paying for the flex Ide is their only revenue point, to say that the
> mx components were badly written is false. They hit exactly the crowd that
> they needed to hit with them. You may be happy with the spark components,
> but that's when flex died, after they were introduced. When the little guy
> was pushed out.
>
> I reiterate that there is not a single complete commercial spark component
> skin on any marketplace after two years. Mx skins weren't in the 100's but
> there were 30 or 40 attempts.
>
> Frankly, If you have a hundred developers, you had more than enough
> resources to take the core as3 language and build your own framework that
> covers this larger set of world class issues with a less feature rich end
> point.
>
> I have no doubt that given this experience you are well suited to guide the
> core framework internals in the future, but not if you can't recognize that
> it's a niche case and that mx covered 95% of most user's needs.
>
> Most projects can't create components for the project. Most projects use
> components to build the project. That's why they are called components.
> They are reusable. Most projects are focused on the content and use the
> components to display the content.
>
>
> On Fri, Mar 2, 2012 at 9:36 AM, Michael A. Labriola <
> labriola@digitalprimates.net> wrote:
>
> > >Ok. I'm totally willing to believe you and to think that I'm missing
> > something here but I think you have to explain that a little bit more.
> What
> > kind of apps were these? Were they super detailed subcomponents? Or was a
> > >combobox something that needed an item renderer? What other UI set are
> you
> > comparing them with?
> >
> > The need to build and extend these components for large enterprises
> >
> > >Or to put a hard number on it how big were these projects? Two people?
> > ten? or more?
> > Dozens sometimes hundreds.
> >
> > >But point me to a better set of standard ui components and make the case
> > for them, because then we can emulate them.
> > Its not that there is a better set. The point is that there are major
> > improvements that can be made
> >
> > >How did you like awt or swing or the microsoft native component sets?
> Did
> > you use the silverlight components at all? Tcl did the job?
> > Although I didn't always like their internals, the quantity and general
> > extensibility of many of the Silverlight components was quite nice
> >
> > >Did spark solve your problems? Please tell me how removing the ability
> to
> > change simple things like label positioning and styles, base colors,
> > enabled something to solve your problems?
> > It solves many of the problems simply by delegating the instantiation of
> > the visual components to a separate, swappable class
> >
> > >Things can always be better, but what then, in your mind is the gold
> > standard that we should strive for? Because in my experience, the mx
> > components were the best out of the box stuff that I've been able to work
> > with.
> > The mx components were the multi-tool of the world. When you buy a
> kitchen
> > appliance that does -everything- you often find that it doesn't do
> > -anything- with expertise. We spent millions of dollars doing nothing but
> > changing the SDK so we could begin to extend it. Components being created
> > inside of 500 line methods which access private variables so you can
> never
> > change the implementations via subclass. Hardcoded dependencies, hell,
> even
> > the methodology by which createChildren checks for the existence of a
> child
> > before creating a new one so that you have this primitive sort of
> override
> > mechanism. All code smells.
> >
> > >You had to recompile the whole sdk to add minimal functionality?
> > We maintain nearly 15 copies of the sdk each modified in different ways
> to
> > suit client needs. Try to fix the i18n issues of the framework when
> > internally every object is bound to a hard date instance or uses a set of
> > string utilities which don't work 100% with 3/5ths of the world's
> languages
> > and you will quickly find that, to change one of those pieces (due to
> > coupling and hard dependencies) you have to override an entire branch of
> > the framework class by class, not just a node.
> >
> >
>
RE: Why Spark? (was Re: s:Spacer (was Re: Missing Spark components))
Posted by "Michael A. Labriola" <la...@digitalprimates.net>.
>I have no doubt that given this experience you are well suited to guide the core framework internals in the future, but not if you can't recognize that it's a niche case and that mx covered 95% of most user's needs.
Sorry, I seem incapable of getting all my thoughts out coherently tonight. Last thing, promise.
I don't expect, nor does the idea of Apache put me or anyone else in a position, to guide or lead any part of this project. The only thing I plan to do is contribute my thoughts in the form of code. Ultimately everyone, yourself included, will decide if those make sense across the scope of all projects represented here. So, I guess my point is, if I solve the problems I have and do it well, I think they will solve yours too. If I don't the whole of this project will reject them. Ultimately my only hope is that they are evaluated in terms of their ultimate utility in not just in terms of them being different than the way we have always done x. My biggest fear is that we cling on to an idea of what flex did in mx or some other timeframe and it can never be different.
Have a great weekend,
Mike
RE: Why Spark? (was Re: s:Spacer (was Re: Missing Spark components))
Posted by "Michael A. Labriola" <la...@digitalprimates.net>.
>So if paying for the flex Ide is their only revenue point, to say that the mx components were badly written is false. They hit exactly the crowd that they needed to hit with them. You may be happy with the spark >components, but that's when flex died, after they were introduced. When the little guy was pushed out.
If they hit their sweet spot at any point, they might have made enough money to fulfill both of our wishes. Further, whether or not something was commercially viable is not an indicator of its strengths from an architectural perspective. While there may be more small teams, those enterprises that were employing hundreds of developers were also the ones churning through people and effectively paying to train new developers which enter the market. This is good for everyone involved. They were also the ones that, marketed to effectively, could have paid for the features every product could use. Incidentally, I did not say I was happy with Spark. I said that parts of it were a step in the right direction.
Flex 'died' because it took 2+ years to develop the next, and still incomplete, version of a component set.
>I have no doubt that given this experience you are well suited to guide the core framework internals in the future, but not if you can't recognize that it's a niche case and that mx covered 95% of most user's needs.
I am a consultant. I worked on projects large and small and you are in the vast minority of people who believe that mx covered 95% of most user's needs. Incidentally, I never argued that we needed a complete component rewrite and I am not pushing for that now. I would have much preferred an iterative improvement model to mx over the years. I don't think our ideas on this are very far apart in truth. I was just pointing out that the spark architecture does give us several things mx never did. We can build on both of these to make something that is 'pay as you go'. That means we cover the small projects needs but don't handicap the bigger projects. That is all I am after. I don't want to change the model, I want to remove the barriers that prevent us from doing more.
>Most projects can't create components for the project. Most projects use components to build the project. That's why they are called components.
>They are reusable. Most projects are focused on the content and use the components to display the content.
We don't disagree on any of your major points.
Re: Why Spark? (was Re: s:Spacer (was Re: Missing Spark components))
Posted by Cortlandt Winters <co...@cortwinters.net>.
Thank you, Micheal for a great response.
I think what we have here are two radically different use cases.
On the one hand flex needs to be a good enough framework that a team of
three can create something of real value on a 10-30 thousand dollar budget
in a few months. Without rock stars.
On the other hand how can a team of 100 which was probably 10 times the
number of core flex developers, do world class stuff if the sweet spot is
for a team of 3-5?
But frankly from Macromedia/Allaire and Adobe's standpoint, there are
probably a thousand times more users
in the first scenario than the second, maybe ten thousand more.
So if paying for the flex Ide is their only revenue point, to say that the
mx components were badly written is false. They hit exactly the crowd that
they needed to hit with them. You may be happy with the spark components,
but that's when flex died, after they were introduced. When the little guy
was pushed out.
I reiterate that there is not a single complete commercial spark component
skin on any marketplace after two years. Mx skins weren't in the 100's but
there were 30 or 40 attempts.
Frankly, If you have a hundred developers, you had more than enough
resources to take the core as3 language and build your own framework that
covers this larger set of world class issues with a less feature rich end
point.
I have no doubt that given this experience you are well suited to guide the
core framework internals in the future, but not if you can't recognize that
it's a niche case and that mx covered 95% of most user's needs.
Most projects can't create components for the project. Most projects use
components to build the project. That's why they are called components.
They are reusable. Most projects are focused on the content and use the
components to display the content.
On Fri, Mar 2, 2012 at 9:36 AM, Michael A. Labriola <
labriola@digitalprimates.net> wrote:
> >Ok. I'm totally willing to believe you and to think that I'm missing
> something here but I think you have to explain that a little bit more. What
> kind of apps were these? Were they super detailed subcomponents? Or was a
> >combobox something that needed an item renderer? What other UI set are you
> comparing them with?
>
> The need to build and extend these components for large enterprises
>
> >Or to put a hard number on it how big were these projects? Two people?
> ten? or more?
> Dozens sometimes hundreds.
>
> >But point me to a better set of standard ui components and make the case
> for them, because then we can emulate them.
> Its not that there is a better set. The point is that there are major
> improvements that can be made
>
> >How did you like awt or swing or the microsoft native component sets? Did
> you use the silverlight components at all? Tcl did the job?
> Although I didn't always like their internals, the quantity and general
> extensibility of many of the Silverlight components was quite nice
>
> >Did spark solve your problems? Please tell me how removing the ability to
> change simple things like label positioning and styles, base colors,
> enabled something to solve your problems?
> It solves many of the problems simply by delegating the instantiation of
> the visual components to a separate, swappable class
>
> >Things can always be better, but what then, in your mind is the gold
> standard that we should strive for? Because in my experience, the mx
> components were the best out of the box stuff that I've been able to work
> with.
> The mx components were the multi-tool of the world. When you buy a kitchen
> appliance that does -everything- you often find that it doesn't do
> -anything- with expertise. We spent millions of dollars doing nothing but
> changing the SDK so we could begin to extend it. Components being created
> inside of 500 line methods which access private variables so you can never
> change the implementations via subclass. Hardcoded dependencies, hell, even
> the methodology by which createChildren checks for the existence of a child
> before creating a new one so that you have this primitive sort of override
> mechanism. All code smells.
>
> >You had to recompile the whole sdk to add minimal functionality?
> We maintain nearly 15 copies of the sdk each modified in different ways to
> suit client needs. Try to fix the i18n issues of the framework when
> internally every object is bound to a hard date instance or uses a set of
> string utilities which don't work 100% with 3/5ths of the world's languages
> and you will quickly find that, to change one of those pieces (due to
> coupling and hard dependencies) you have to override an entire branch of
> the framework class by class, not just a node.
>
>
RE: Why Spark? (was Re: s:Spacer (was Re: Missing Spark components))
Posted by "Michael A. Labriola" <la...@digitalprimates.net>.
>Ok. I'm totally willing to believe you and to think that I'm missing something here but I think you have to explain that a little bit more. What kind of apps were these? Were they super detailed subcomponents? Or was a >combobox something that needed an item renderer? What other UI set are you comparing them with?
The need to build and extend these components for large enterprises
>Or to put a hard number on it how big were these projects? Two people? ten? or more?
Dozens sometimes hundreds.
>But point me to a better set of standard ui components and make the case for them, because then we can emulate them.
Its not that there is a better set. The point is that there are major improvements that can be made
>How did you like awt or swing or the microsoft native component sets? Did you use the silverlight components at all? Tcl did the job?
Although I didn't always like their internals, the quantity and general extensibility of many of the Silverlight components was quite nice
>Did spark solve your problems? Please tell me how removing the ability to change simple things like label positioning and styles, base colors, enabled something to solve your problems?
It solves many of the problems simply by delegating the instantiation of the visual components to a separate, swappable class
>Things can always be better, but what then, in your mind is the gold standard that we should strive for? Because in my experience, the mx components were the best out of the box stuff that I've been able to work with.
The mx components were the multi-tool of the world. When you buy a kitchen appliance that does -everything- you often find that it doesn't do -anything- with expertise. We spent millions of dollars doing nothing but changing the SDK so we could begin to extend it. Components being created inside of 500 line methods which access private variables so you can never change the implementations via subclass. Hardcoded dependencies, hell, even the methodology by which createChildren checks for the existence of a child before creating a new one so that you have this primitive sort of override mechanism. All code smells.
>You had to recompile the whole sdk to add minimal functionality?
We maintain nearly 15 copies of the sdk each modified in different ways to suit client needs. Try to fix the i18n issues of the framework when internally every object is bound to a hard date instance or uses a set of string utilities which don't work 100% with 3/5ths of the world's languages and you will quickly find that, to change one of those pieces (due to coupling and hard dependencies) you have to override an entire branch of the framework class by class, not just a node.
Re: Why Spark? (was Re: s:Spacer (was Re: Missing Spark components))
Posted by Cortlandt Winters <co...@cortwinters.net>.
Ok. I'm totally willing to believe you and to think that I'm missing
something here but I think you have to explain that a little bit more. What
kind of apps were these? Were they super detailed subcomponents? Or was a
combobox something that needed an item renderer? What other UI set are you
comparing them with?
Or to put a hard number on it how big were these projects? Two people? ten?
or more?
I will admit straight out that most projects that I've worked on had one
Java or Coldfusion guy, one db guy, myself and if we were lucky, a part
time graphic designer.
But I just spent 18 months getting very familiar with the spark
architecture and an old app that we wrote 6 years ago with mx components
has just had some major new features added to it and I'm amazed at how easy
it has gone with the exception of design view in 4.6 totally not working
with a 3.2 code base.
I remember that it was a pain to try and figure out what was a style what
was a skin, etc. - there were a lot of properties to keep track of. That
part was definitely trouble.
But point me to a better set of standard ui components and make the case
for them, because then we can emulate them. I've used a lot of ui
components and these were the best in many ways that I can think of. How
did you like awt or swing or the microsoft native component sets? Did you
use the silverlight components at all? Tcl did the job?
Did spark solve your problems? Please tell me how removing the ability to
change simple things like label positioning and styles, base colors,
enabled something to solve your problems?
Things can always be better, but what then, in your mind is the gold
standard that we should strive for? Because in my experience, the mx
components were the best out of the box stuff that I've been able to work
with.
The sole caveat was that it was such a mish mash of css, native vectors and
embeded images that it was tough to figure out which way to go to for a
particular idea. But that's practically a documentation issue really.
You had to recompile the whole sdk to add minimal functionality?
Please elaborate.
But more importantly point us to the promised land because I'm obviously
missing some horizon here that I need to know about.
On Thu, Mar 1, 2012 at 11:18 PM, Michael A. Labriola <
labriola@digitalprimates.net> wrote:
>
> >the mx components were very well designed and complete and (though
> complicated) hit a nice sweet spot between many trade-offs.
>
> I do agree that it was often about what types of apps you were building,
> however, just to provide another perspective, the mx components were
> neither well designed nor anywhere near a sweet spot for the apps I was
> building. They were clunky, bloated, untestable messes that required
> copying and pasting gobs of code or recompiling the whole SDK to add
> minimal additional functionality. Every day we had to invoke an escape
> hatch to do the work we needed.
>
>
RE: Why Spark? (was Re: s:Spacer (was Re: Missing Spark components))
Posted by "Michael A. Labriola" <la...@digitalprimates.net>.
>the mx components were very well designed and complete and (though complicated) hit a nice sweet spot between many trade-offs.
I do agree that it was often about what types of apps you were building, however, just to provide another perspective, the mx components were neither well designed nor anywhere near a sweet spot for the apps I was building. They were clunky, bloated, untestable messes that required copying and pasting gobs of code or recompiling the whole SDK to add minimal additional functionality. Every day we had to invoke an escape hatch to do the work we needed.
Re: Why Spark? (was Re: s:Spacer (was Re: Missing Spark components))
Posted by Cortlandt Winters <co...@cortwinters.net>.
Actually this is a very good question and I think that folk have many
different opinions. Often based on the kinds of apps that they work on or
the kind of work that they do.
While I have no true window into the motivation, I believe that the
motivation of the spark component set is two fold. The first is to provide
a cleaner separation between visual appearance and core functionality. I
think the second was to support declarative visual tooling. From a high
level I think Adobe hit the nail on the head about what was needed but was
unable to come up with the implementation to fit the vision.
Spark seems, from a programmers standpoint, a better architecture from mx,
but it may be too formal and strict given the fact that it took so long to
create the spark components and the fact that there are still no complete
skins that anybody has created for them. I really don't know as I'm not
that clued into the design shops.
the mx components were very well designed and complete and (though
complicated) hit a nice sweet spot between many trade-offs. It's easy to be
very productive with the mx components in a small team without tooling. In
many cases simple things like changing the color of a scrollbar or the
layout of a label or the height of a part of a component was covered with
the mx components, and was left as a "reader exercise" in the spark ones.
For those of us who have applications out in the wild with mx components it
would be terrible for them to be depreciated. I doubt if the spark
components, despite their theoretical strengths will ever hit the sweet
spot of what folk want out of a component like the mx ones did.
Having said that the spark architecture has already shown that it will
certainly be the way to go for components that have one appearance on an
Iphone, another on an android and another in the web app. So it or a
simpler version of it is clearly the way going forward.
The plan at this point I think is to do new component development with the
spark architecture and try to use the skinning flexibility to target
android devices with android skins and ios devices wtih ios skins, web apps
with a web skin, desktop apps with os specific ones.
Wait for adobe to put out the key missing ones. Companies that want to make
their transition from mx to spark and tablets or phones easier should try
to contribute spark skins that make the transition easier for each other.
It is ok to have two totally different component sets. A legacy one and a
new one. Those of us who have had to go through transitioning apps from one
to the other could eventually offer direction and advice to those who would
like to but are afraid to because of the wildly different feature sets.
I understand Alex's desire to redo the spark architecture to something that
goes for a totally new and simpler sweet spot. And I think that after v5
that should be a core goal for folk, but the spark architecture doesn't
seem that bad to me and there are a lot of apps out there using the mx one,
which is why I think that providing a clear transition path is well worth
it if there are folk that are willing to do the work. If we had the workers
to put together a whole new component set that utilized the gamut of
experience in building components I'm sure we could do a great job, but not
in time for v5. I'm totally willing to say that I'm wrong if there is some
cohesive vision that shows how we could just do a simpler version of spark,
hit the necessaries with v5 and then migrate from mx to the new
architecture instead of spark, but I am not capable at this point of
figuring out what that other thing should be, so that may be a blind spot.
One that I'm willing to fix. I just need to hear and learn more about that
vision.
On Thu, Mar 1, 2012 at 6:25 PM, Om <bi...@gmail.com> wrote:
> On Thu, Mar 1, 2012 at 3:12 PM, Omar Gonzalez <omarg.developer@gmail.com
> >wrote:
>
> > >
> > > Maybe, I am completely off base here, but exactly what is the
> motivation
> > of
> > > the spark component set? Is it the new skinning paradigm, or is it
> > better
> > > performing versions of existing components or is it a completely
> > different
> > > set of components that happen to have similar names? If this is a
> > separate
> > > conversation, please reply in a new thread.
> > >
> > > Thanks,
> > > Om
> > >
> >
> > Personally for me the motivation to create Spark equivalents of some of
> > these components is the better skinning model. At least, in my opinion, I
> > much prefer the Spark skinning over MX. This is why I haven't done any MX
> > apps since Spark came out.
> >
> >
> Right, but why are mx components shipping when equivalent spark versions
> are available? This to me is the biggest sticking point. Can we nix mx
> components from future releases if that is the 'old' way of doing things?
>
> Was the original plan (by Adobe's Flex team) to get to 100% mx <=> spark
> parity before nixing mx in a future release? If yes, can someone explain
> the motivations for such a decision?
>
> (Non-rhetorical question) Is everyone okay with different components with
> completely different architectures and supporting different sets of
> features with the same names shipping alongside in the same SDK? If yes,
> what are the benefits?
>
> Or was the original plan was to support two different sets of components
> that support two different skinning architectures? It does not appear so
> from the code hints (Use s:XYZ instead) that appear when we attempt to use
> an mx component.
>
> IMHO, we need to pick one plan and make sure that EVERY component we ship
> with the SDK follows the same set of rules.
>
> Thanks,
> Om
>
Re: Why Spark? (was Re: s:Spacer (was Re: Missing Spark components))
Posted by David Francis Buhler <da...@gmail.com>.
I believe Adobe needed to support a backwards compatible product.
My own preference is to take the same approach as certain software
companies, and leave it to clients and companies to migrate to a faster,
better, leaner platform (because we're not supporting backwards
compatibility).
On Thu, Mar 1, 2012 at 6:25 PM, Om <bi...@gmail.com> wrote:
> On Thu, Mar 1, 2012 at 3:12 PM, Omar Gonzalez <omarg.developer@gmail.com
> >wrote:
>
> > >
> > > Maybe, I am completely off base here, but exactly what is the
> motivation
> > of
> > > the spark component set? Is it the new skinning paradigm, or is it
> > better
> > > performing versions of existing components or is it a completely
> > different
> > > set of components that happen to have similar names? If this is a
> > separate
> > > conversation, please reply in a new thread.
> > >
> > > Thanks,
> > > Om
> > >
> >
> > Personally for me the motivation to create Spark equivalents of some of
> > these components is the better skinning model. At least, in my opinion, I
> > much prefer the Spark skinning over MX. This is why I haven't done any MX
> > apps since Spark came out.
> >
> >
> Right, but why are mx components shipping when equivalent spark versions
> are available? This to me is the biggest sticking point. Can we nix mx
> components from future releases if that is the 'old' way of doing things?
>
> Was the original plan (by Adobe's Flex team) to get to 100% mx <=> spark
> parity before nixing mx in a future release? If yes, can someone explain
> the motivations for such a decision?
>
> (Non-rhetorical question) Is everyone okay with different components with
> completely different architectures and supporting different sets of
> features with the same names shipping alongside in the same SDK? If yes,
> what are the benefits?
>
> Or was the original plan was to support two different sets of components
> that support two different skinning architectures? It does not appear so
> from the code hints (Use s:XYZ instead) that appear when we attempt to use
> an mx component.
>
> IMHO, we need to pick one plan and make sure that EVERY component we ship
> with the SDK follows the same set of rules.
>
> Thanks,
> Om
>
Re: Why Spark? (was Re: s:Spacer (was Re: Missing Spark components))
Posted by Alex Harui <ah...@adobe.com>.
On 3/1/12 3:25 PM, "Om" <bi...@gmail.com> wrote:
> Right, but why are mx components shipping when equivalent spark versions
> are available? This to me is the biggest sticking point. Can we nix mx
> components from future releases if that is the 'old' way of doing things?
>
> Was the original plan (by Adobe's Flex team) to get to 100% mx <=> spark
> parity before nixing mx in a future release? If yes, can someone explain
> the motivations for such a decision?
Adobe would deprecate the mx components and think about removing them much
later. But I think that we've heard lots of folks who want Adobe to donate
3.x so MX is still very much needed. It isn't just about replacing mx: with
s:, there are lots of other differences that make the conversion risky.
>
> (Non-rhetorical question) Is everyone okay with different components with
> completely different architectures and supporting different sets of
> features with the same names shipping alongside in the same SDK? If yes,
> what are the benefits?
There are no benefits, but backwards compatibility is a reality.
>
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: Why Spark? (was Re: s:Spacer (was Re: Missing Spark components))
Posted by Om <bi...@gmail.com>.
On Thu, Mar 1, 2012 at 3:12 PM, Omar Gonzalez <om...@gmail.com>wrote:
> >
> > Maybe, I am completely off base here, but exactly what is the motivation
> of
> > the spark component set? Is it the new skinning paradigm, or is it
> better
> > performing versions of existing components or is it a completely
> different
> > set of components that happen to have similar names? If this is a
> separate
> > conversation, please reply in a new thread.
> >
> > Thanks,
> > Om
> >
>
> Personally for me the motivation to create Spark equivalents of some of
> these components is the better skinning model. At least, in my opinion, I
> much prefer the Spark skinning over MX. This is why I haven't done any MX
> apps since Spark came out.
>
>
Right, but why are mx components shipping when equivalent spark versions
are available? This to me is the biggest sticking point. Can we nix mx
components from future releases if that is the 'old' way of doing things?
Was the original plan (by Adobe's Flex team) to get to 100% mx <=> spark
parity before nixing mx in a future release? If yes, can someone explain
the motivations for such a decision?
(Non-rhetorical question) Is everyone okay with different components with
completely different architectures and supporting different sets of
features with the same names shipping alongside in the same SDK? If yes,
what are the benefits?
Or was the original plan was to support two different sets of components
that support two different skinning architectures? It does not appear so
from the code hints (Use s:XYZ instead) that appear when we attempt to use
an mx component.
IMHO, we need to pick one plan and make sure that EVERY component we ship
with the SDK follows the same set of rules.
Thanks,
Om
RE: Why Spark? (was Re: s:Spacer (was Re: Missing Spark components))
Posted by "Michael A. Labriola" <la...@digitalprimates.net>.
>Spark was supposed to enable fully-declarative skins for Flash Catalyst and leverage a lot of other lessons learned from MX. But that didn't happen.
True, however, just moving the child instantiation out of the component has made this architecture so much easier to work with and extend in practice. Often times we need half the code repetition than before
>Spark apps aren't always performing better than their MX equivalents.
No, but its always what is provided and how its used
Re: Why Spark? (was Re: s:Spacer (was Re: Missing Spark components))
Posted by Alex Harui <ah...@adobe.com>.
>>
>> Maybe, I am completely off base here, but exactly what is the motivation of
>> the spark component set?
Spark was supposed to enable fully-declarative skins for Flash Catalyst and
leverage a lot of other lessons learned from MX. But that didn't happen.
>> Is it the new skinning paradigm, or is it better
>> performing versions of existing components
Spark apps aren't always performing better than their MX equivalents.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui