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
