On Thu, Mar 1, 2012 at 7:34 AM, Jonathan Campos
<jonbcam...@gmail.com>wrote:
On Thu, Mar 1, 2012 at 2:13 AM, Omar Gonzalez <omarg.develo...@gmail.com
wrote:
I've added a page to the wiki to keep track of the current
inventory of
MX
components, their Spark counterparts, and whether they are currently
missing.
I don't want to just go editing your work without some discussion,
so I'm
throwing the discussion here. There are some components that I
don't see
the need to be "spark'ed" nor do I consider them missing.
Specifically:
Grid (group + tilelayout)
I disagree here. We should have the convenience class, it makes things
easier to find and illustrates proper use of the framework and its
layout
objects.
Also writing:
<s:TileGroup>
</s:TileGroup>
Is a lot less verbose than:
<s:Group>
<s:layout>
<s:TileLayout />
</s:layout>
</s:Group>
Plus it falls in line with the other convenience classes such as
<s:HGroup/> and <s:VGroup/> and it helps with migration for people
that
will immediately look to replace some MX layouts.
LinkBar (button bar + skin) <- new skin could be made easily
LinkButton (button + skin) <- new skin could be made easily
Again, while creating skins that mimic LinkButton and LinkBar I
still see
that convenience classes can help here. Instead of subclassing
s:Button,
writing a custom skin class, adding a click listener and writing up a
navigateToUrl() this call all be conveniently wrapped into a
component u
can use like this:
<s:LinkButton href="http://www.site.com/"; target="_blank />
That is far more convenient and less code to write for a simple link
and
again helps to mitigate the migration path.
PopupButton (calloutbutton) <- needs to be generalized from just
mobile
specific
Agreed on this one.
Spacer (mx:spacer or rect)
My pet peeve here is having to still use the mx namespace. I wouldn't
really care if the s:Spacer was line for line identical to
mx:Spacer, its
just the lack of consistency that really drives me up the wall. Also,
couldn't we just use s:Rect and again make a convenience class just
to keep
the LoC shorter?
TileList (9as already posted list+tilelayout)
Again, this class would be a convenience class and would help mitigate
migration path from MX to Spark. It also falls in line with other
convenience classes such as s:HGroup and s:VGroup.
I'd prefer to have:
<s:TileList />
than
<s:List>
<s:layout>
<s:TileLayout />
<s:/layout>
</s:List>
ToggleButtonBar (buttonbar + skin) <- new skin could be made easily
ToggleButton !== Button, I think another component is needed here
no? Or
does s:ButtonBar have some properties that allow it to behave like a
ToggleButtonBar?
VRule and HRule (rect)
Again, a convenience class to help with migration. This could very
well
subclass s:Rect and just provide convenience setters to its styling
properties
All Charting (they are already very spark-ish)
I'm not sure on which way to go with these. They are definitely not
Spark-ish as they do not follow the Spark skinning model at all.
However
they have been deemed as performant enough by Adobe that they've
openly
said they're ok to work in mobile environments. I just think we
should at
least look at how the charting components can be improved in their
skinning
to be more inline with the Spark skinning model.
While I get the intention I think that to go down this path will
cause
confusion and also reduce people's abilities to see new features and
functionality (specifically in the case of TileList, HRule/VRule,
LinkButton... well all of them).
I would think that these can just be marked as resolved and ended.
I think the convenience classes are important as they both provide a
cleaner migration path while at the same time help to illustrate the
use of
core features of the framework, such as layouts.
With charting I could agree that there could be an update to make
skinning
them simpler but I have done many custom skins already with these
components.
--
Jonathan Campos
I agree its possible to customize the skins of these components. I
just
find it flawed that if we keep these MX charting components then
there are
two skinning approaches that have to be taken, and that's just not
nice. We
should try to Spark-ify the skinning model in the charting components.
--
Omar Gonzalez
s9tpep...@apache.org
Apache Flex PPMC Member
