1. #1
    Sencha Premium Member
    Join Date
    Oct 2011
    Posts
    139
    Vote Rating
    4
    jvahabzadeh is on a distinguished road

      0  

    Default Unanswered: Appearance Design Pattern - uh, now what do I do with it?

    Unanswered: Appearance Design Pattern - uh, now what do I do with it?


    Ok, so I have some code running based off the Appearance Design Pattern article. The bulk of the code involved as I have it running is on the article's page, and also mentioned a bunch in this thread.

    I've changed my Entry Point class, though, to look as follows:
    PHP Code:
    public class GWT3BetaTest1 implements EntryPoint {

      public 
    void onModuleLoad() {
        
    VerticalPanel panel = new VerticalPanel();
        
    panel.add(new Label("Hello there!"));
        
    panel.add(new AppearancePushButton("An AppearancePushButton"));
        
    RootPanel.get().add(panel);
      }

    I've also taken a bit of a look at Google's Cell Backed Widgets article but haven't used any of the code there for my sample.

    All well and good.

    Now, what do I do with it?

    There's two points to that, I guess:
    1) The Sencha article shows as the Appearance interface the following:
    PHP Code:
    public interface Appearance {
         
    void render(SafeHtmlBuilder sb);
         
    void onUpdateText(XElement parentString text); 
         
    void onUpdateIcon(XElement parentImage icon);

    But the Google article shows:
    PHP Code:
    public abstract static class Appearance {
        public 
    void onHover(Context contextElement parentString value) {}
        public 
    void onPush(Context contextElement parentString value) {}
        public 
    void onUnhover(Context contextElement parentString value) {}
        public 
    void onUnpush(Context contextElement parentString value) {}
        public abstract 
    void render(Context contextSafeHtml dataSafeHtmlBuilder sb);

    So, I note that the only one in common is "render" and they take different parameters.

    What determines what methods and signatures can exist for an Appearance interface? Can I simply add an onHover and an onUnhover for the Appearance interface (and corresponding class that implements it)? How do I know what parameters they should have? etc.

    For example, I'd like my "AppearancePushButton" class to have some sort of change in its look when I hover, and want to know how to do this with appearances.


    2) How do I use this to be able to swap Appearances? Would each class of my own that I create need its own internal Appearance interface, and potentially multiple DefaultAppearance classes inside? Do I create a stand-alone Appearance interface, multiple implementations of it, and swap in and out which one I use with the "replace-with" directive in the project xml file? Can a single Appearance interface and a single implementation of it cover everything all my classes would need?


    3) What about classes that already exist? How do I apply this, to say, the GXT 3.0 Window class? I want the borders, titlebar, and background to have different than the default colors - how do I do this with Appearances?

    Thanks in advance... if there's some sort of reference guide that covers this, I'd be more than happy to use that . . I apologize if I'm coming off as needing a bit of hand-holding.

  2. #2
    Sencha - GXT Dev Team
    Join Date
    Feb 2009
    Location
    Minnesota
    Posts
    2,717
    Answers
    109
    Vote Rating
    88
    Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light

      0  

    Default


    The idea of an appearance is that it is just an abstraction for the elements and events, to pull them out of the logic of the widget. Each use case might have different things which need to be handled by an appearance - a button, for example, won't care about key strokes, whereas an autocomplete field will, and so its appearance will need some way of showing each key as it is entered.

    Almost every widget in GXT 3 has an appearance interface declared in it, with at least one default implementation. Some, such as ContentPanel, have more than one (see the BlueFramedPanelAppearance class as another example) so the widget can be drawn in another way.

    Each widget will have different data it will need to draw, and different events to receive. Once the interface is declared, and the logic of the widget is de-coupled from how the widget's content is drawn, multiple appearances can be created.

    An appearance instance is often a constructor argument, with another constructor that specifies a default version to use. In most GXT classes, that default is obtained by calling GWT.create, so GWT's own rebind rules will supply the default - this allows different themes to replace the appearances used in an entire app. Providing a specific instance when you create the widget can be a way of saying to that this widget is a special case, and should be drawn differently, for whatever reason.

    Besides GWT's own documentation on the basics of the appearance pattern and the blog post, the only documentation I'm aware of is the beta 1 release's code. We will work on better documentation, as well as alternate themes, as we get closer to a final release.

  3. #3
    Sencha Premium Member
    Join Date
    Oct 2011
    Posts
    139
    Vote Rating
    4
    jvahabzadeh is on a distinguished road

      0  

    Default


    Thanks - I'll admit that it's not clear to me, but I'll definitely start looking into those classes as starting points.

    On the other side of the coin, can the GXT widgets that use Appearance classes also still use the old way of having typical GWT entries in the .css file to change their looks?

    If so, is there documentation somewhere that says what style names correspond to what, without going through the source code to dig them up?


    Also, I guess the lingering question is - when creating an Appearance interface for a class, is there a listing or documentation somewhere of all the possible methods the Appearance interface can use?

    After all, who is calling these methods? For, onUpdateText for example, how would I know to have a method in my interface specifically called onUpdateText rather than, say onUpdateInternalText? How would I know to have called my hover method onHover rather than, say onMouseOver? etc.?

    Or am I missing something very basic here?

    EDIT: considering that the article on this site dealt with something called an AppearancePushButton, I decided to look at an existing Widget, so went with TextButton and followed the class hierarchy up. I guess that's not one of the widgets that uses Appearances? I couldn't seem to find any reference to an Appearance in it or its superclasses.....

  4. #4
    Sencha - GXT Dev Team
    Join Date
    Feb 2009
    Location
    Minnesota
    Posts
    2,717
    Answers
    109
    Vote Rating
    88
    Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light

      0  

    Default


    Quote Originally Posted by jvahabzadeh View Post
    On the other side of the coin, can the GXT widgets that use Appearance classes also still use the old way of having typical GWT entries in the .css file to change their looks?

    If so, is there documentation somewhere that says what style names correspond to what, without going through the source code to dig them up?
    Yes, your home-made appearances can use external css files, skipping the whole CssResource thing. Doing so means that you are defining your own css classes (the 'what style names correspond to what' part) - make them whatever you want. Since you are defining them, and building the dom, you get to decide what does what.


    Quote Originally Posted by jvahabzadeh View Post
    Also, I guess the lingering question is - when creating an Appearance interface for a class, is there a listing or documentation somewhere of all the possible methods the Appearance interface can use?
    Yes, for each class look at the *Appearance interface declared, and implement those methods. If there is a question as to what a method is for, javadoc should clarify (not all javadoc is complete, look for better docs in upcoming betas).

    Quote Originally Posted by jvahabzadeh View Post
    After all, who is calling these methods? For, onUpdateText for example, how would I know to have a method in my interface specifically called onUpdateText rather than, say onUpdateInternalText? How would I know to have called my hover method onHover rather than, say onMouseOver? etc.?
    When you implement the interface, you won't be able to compile your code until you have all the methods done correctly - your IDE should even have tools to stub out those methods so you know what you need to do.

    If you are building your own widget+appearance, you can call them what you want. One of the main design considerations in writing thses appearances has been to make sure that one could replace the html/css structure, and not affect the inner workings of the widget - sometimes it is required to add even more methods to the appearance to make this happen correctly.

    Or am I missing something very basic here?[/QUOTE]

Thread Participants: 1