2 Replies Latest reply on Aug 6, 2011 7:07 PM by aappddeevv12

    CSS - why not Java?

    zonski
      Hi,

      I am loving the potential of JFX 2.0. The old scripting stuff was a do-not-touch for me and I am glad to see the back of it.

      One area that is still urking me ever so slightly is the use of CSS files. Why do we need an additional language in our code, what's wrong with Java for this too? I've got a nasty suspicion that the JFX CSS stuff is going to grow into another scripting language before long as people start trying to put effects and animations into it (either that or these XML definitions will start popping up as well). For the same reason that Java was a good language for JFX coding, I would argue it is a very good language for doing styles, effects and animations too. For those wanting to go down the script language aspect, then they can always use Groovy to create their Style classes.

      Don't get me wrong, the idea of 'styling' is brilliant, and sorely missing from Swing. My question is why a new styling language? We want to be able to extract out the styles away from our core GUI code, and also be able to extend and reuse styles. That's pretty much the goal of Object Orientation and that's what Java does oh so well.

      So, feedback and input welcome, but for me I would love to see JavaFX have the ability for me to write code like the following:
      LabelStyle myLabelStyle = new LabelStyleBuilder()
                      .font("Arial", Font.BOLD, 14)
                      .background(Color.RED)
                      .borderWidth(2)
                      .borderRadius(10)
                      .buildStyle();        
      Then I would just use this style in my code:
          Label myLabel = new Label("This is my styled label");
          myLabel.addStyle(myLabelStyle);  // or myLabelStyle.applyTo(myLabel);
      How I group my style instances is up to me, but probably I would create a MyStyleSheet class that then contains the myLabelStyle and all the other styles that I have in my application in it (or maybe I might break it down into smaller classes, totally up to me).

      I get compile safety (and IDE tab completion) on my attributes - so I can't mistype 'backgrund' for example and only find out about it at runtime.

      For complex styles, like Gradient fills, instead of this clunky stuff:
           -fx-background-color: linear (0%,0%) to (0%,100%) stops (0%, #cbd0d7) (100%, white);
      I can have helper methods like this:
      LabelStyle myLabelStyle = new LabelStyleBuilder()
                      .background(ColorHelper.createVerticalGradientFill("#cbd0d7", "white"))  // whatever parameters make sense
                      .buildStyle();        
      When you start talking about effects and animations, using Java methods like this would be much, much cleaner than CSS (or XML) in my opinion.

      I also get the option for dependency injection. So I can inject my label style into my View class using something like Spring or Guice.

      I wouldn't be surprised if combining something like this with the new 'property binding' in JavaFX could result in some pretty cool stuff. Could I bind my TextBox style to it's validation, so the field turns red magically when the user enters the wrong value? When we are in Java these things become possible, when we have to fall out to an external modelling language (be that CSS, JFX Script, XML, or whatever) we put limits on our own ingenuity.

      For example if a Java based styling system was the base model for JavaFX and then people still wanted CSS, someone could always implement a JFX-CSS parser that just builds these Style objects out of the text files. Going the other way is much less elegant (and depending on the JavaFX API, not always possible).

      I actually started implementing something very similar in Swing (i.e. class based Style sheets for Swing) and have only stopped because I think JFX 2.0 is going to make Swing obsolete. It does still provide a good reference for the sort of thing I am talking about:

      [Swing Style - Developers Guide|http://zenjava.com/Developers+Guide]

      Thoughts, opinions?

      zonski

      Edited by: zonski on 05-Aug-2011 18:12
        • 1. Re: CSS - why not Java?
          Narayan
          Helllo zonski,

          As I'm a programmer , I do have experienced.
          ...Why do we need an additional language in our code, what's wrong with Java for this too?...
          There are increasing rate of designer comparing to programmer in the world. Java is now trying to become more flexible than ever by using this css styles . Have you ever thought about the GUI maintainence/update? Many programmer don't like it much at all . So these gui stuffs are not made for the programmers but for the designer. Programmer things that it's easy to use set/get then using that scripting CSS. Yes, Probably I also do think so but actually it's not the way the software becomes perfect. Software must have proper management of it's codes and UI.Java programming will be used specially for the software engine.

          Designer would be feel very comfortable to design the Application UI only by using CSS. Further more now the FXML has evolved to make designer to work more comfortably. Coming CSS 3.0 are now capable of doing animation,transformation too. Infact by separating the application jobs makes the both programmer and designer clear about the software development.

          Thanks
          Narayan
          • 2. Re: CSS - why not Java?
            aappddeevv12
            I think the poster is also speaking to how different the environments/syntax/object semantics are between CSS and programming UI objects in java. I wrote an app in WPF and the XAML was really an object container and since styling was all handled through POJO/POCO properties and specifying styling properties through style objects, you could layout the interface and style it using consistent XAML syntax AND keep it physically separated so that a type of separation of concerns could be achieved. Styles and themes could be in their own XAML file and applied in a cascading fashion if desired. When you couple the ability to specify "cells" directly in XAML through templates, the consistency of fewer "things that are different" was nice. I like WPF's emphases on plain old objects and properties whether you are programming business logic or styling.