We could put it in a Component-specific subclass of BXMLSerializer, say,
WTKXSerializer, that assumes the classes are components. I'm not kidding.
Such a serializer could do a lot of UI-related stuff, too, while building
on the foundation of BXML.
Michael
On Thu, 15 Jul 2010, Greg Brown wrote:
I think it is OK. We can't put this logic in BXMLSerializer since we
can't assume that every class instance will be a Component. We just want
to ensure that every instance of a particular type is assigned these
styles, and setSkin() is the most centralized place to do that.
On Jul 15, 2010, at 9:40 AM, Noel Grandin wrote:
I'm fine with the general concept, except for:
Greg Brown wrote:
The only issue I ran into involves naming conventions. My original logic in setSkin()
looked for files on the classpath named <fully-qualified class name>.json.
Unfortunately, this conflicts with resource bundles, which use the same naming
convention.
Is it just me, or does it feel a little weird that Component#setSkin() is
digging around for files on the classpath?
I kind of liked that the loader classes were distinct from the runtime classes
- makes it obvious which files belongs to
which phase of the application, etc, etc.
-- Noel
