That's why the stylesheet is specified at the application level - so it is clear that it affects (or has the potential to affect) all components within the application. I prototyped various other approaches that did not rely on static specifications and they all became extremely complex very quickly. The static approach is clean and fits in well with the existing architecture.
Note that named styles can use fully-qualified identifiers (e.g. package prefixes) to avoid ambiguity. That's what the Terra theme does with the "commandButton" style. Typed styles are meant to affect every component in an application. They are really just a convenience - the same thing can be accomplished by using a custom subclass of a default skin and overriding the default styles. In either case, the result is the same - every component of a given type is consistently styled. That's what a theme is for. :-) On Jul 20, 2010, at 4:15 AM, Noel Grandin wrote: > I must admit that the various bits of static state in Pivot make me nervous. > > Once people start building large applications with Pivot where you have > multiple teams working on different parts of the > UI, the probability of unintended interactions is pretty high. > > -- Noel. > > Greg Brown wrote: >>> It seems to me your stylesheet styles are locked-in to all instances of XYZ >>> component and all components using a certain style class name. In my >>> implementation you can apply any stylesheet to any component hierarchy at >>> any time. No static state is kept in the UI. >> Understood. But how useful is that in practice? How often are you going to >> want to apply a different set of typed (or even untyped) styles within the >> same application? I'd call that an edge case at best. >> >
