API REVIEW: move com.sun.javafx.css.StyleManager to javafx.scene.StyleManager

[kimtopley at gmail.com]

It would be nice to have a way to set a global default UA stylesheet to completely replace the Caspian css file, without having to do so on all Scenes. This would allow the default stylesheet to be set by framework code, while allowing application code to create Scenes without having to know about the specific stylesheet in use.


Sent from my Verizon Wireless BlackBerry

-----Original Message-----
From: David Grieve <david.grieve at oracle.com>
Sender: openjfx-dev-bounces at openjdk.java.net
Date: Wed, 25 Jul 2012 13:15:14 
To: openjfx-dev at openjdk.java.net List<openjfx-dev at openjdk.java.net>
Subject: API REVIEW: move com.sun.javafx.css.StyleManager to
	javafx.scene.StyleManager

Background: 
This request is related to http://javafx-jira.kenai.com/browse/RT-23460. StyleManager's job it is to keep track of stylesheets, manage the cascade, and create StyleHelpers for nodes. StyleHelper is the code that applies css styles to nodes. 

Currently, there StyleManager is a singleton but it can manage stylesheets from many different scenes. To do this, it maintains a table that maps Scene to a StylesheetContainer which contains the list of declarations from all the stylesheets associated with the scene. RT-23460 seeks to eliminate the lookup of Scene to StylesheetContainer. One such way to do this is for Scene to own its StylesheetContainer, as is proposed in the bug report. Another way is to have Scene own its own StyleManager. This latter approach is preferred (well, by me at least) since it greatly reduces the complexity of StyleManager and makes other optimizations possible. 

Proposed changes:

I propose adding a StyleManager member to Scene and moving StyleManager to the javafx.scene package as an abstract class with the minimum required public API. 

Scene would add: 
    private final StyleManger styleManager; 
    public final StyleManager getStyleManager() 

Because Scene would have public API that returns a StyleManager, StyleManager itself needs to be public API and would need to be moved from com.sun.javafx.css to javafx.scene
 
I propose StyleManager's public API as: 
public abstract StyleHelper getStyleHelper(Node node) 
public final ObservableList<String> getStylesheets() -- the list of stylesheet URL strings for the Scene. Scene's getStylesheets() method would simply return styleManager.getStylesheets() 
public void setDefaultUserAgentStylesheet(String url) 
public final void addDefaultUserAgentStylesheet(String url) -- support Controls that have their own UA stylesheet, plus adding UA stylesheets for embedded 
public final List<String> getUserAgentStylesheets() - return immutable list of UA stylesheet URL strings 
Note that StyleManager returns a StyleHelper. Hence, StyleHelper would also need to be part of the public API. There are only two methods in StyleManager that need to be exposed
public abstract void transitionToState() - this method is called from Node when css needs to be applied
public abstract boolean isPseudoclassUsed(String pseudoclass) - this method is also called from node to determine whether or not the node's pseudo-class state would cause css to be applied

Note that neither the proposed StyleManager API nor the StyleHelper API pull in any other API not already part of the public API. 

Having Scene own a StyleManager also has the benefit of being able to avoid looking up the parent chain to see if the scene's window is a popup or not. That logic can be moved to the constructor. With this change, StyleManager can be further streamlined by eliminating the StylesheetContainer (StylesheetContainer gets moved into the body of the StyleManagerImpl) and the defaultContainer. 

Further, since a Parent can also have stylesheets, I also propose adding StyleManager to Parent with the same API as in Scene. 
    private final StyleManger styleManager; 
    public final StyleManager getStyleManager() 

This will help eliminate the parent stylesheet lookup that currently happens in StylesheetContainer.


David Grieve | Principal Member of Technical Staff
Mobile: +16033121013 
Oracle Java Client UI and Tools
Durham, NH 03824 
 Oracle is committed to developing practices and products that help protect the environment