1. #11
    Sencha - GXT Dev Team
    Join Date
    Feb 2009
    Location
    Minnesota
    Posts
    2,639
    Answers
    107
    Vote Rating
    80
    Colin Alworth is just really nice Colin Alworth is just really nice Colin Alworth is just really nice Colin Alworth is just really nice Colin Alworth is just really nice

      0  

    Default


    Code:
    .appWindow window1 {
         background-color: Green;
    }
    I'm not sure what this is trying to do - this might be again a question of knowing CSS. Here's what the first line means in CSS:

    "Select all items with tag name 'window1' inside any element with class 'appWindow', and apply these styles..."

    However, there is no such thing as a html tag 'window1', so this query will do nothing.

    The reason my query worked is that there *is* a tag named textarea - that is how you render a multi-line text input. The query finds all textarea tags anywhere inside any tag with class "newData".

    My suggestion was to actually change the class names on the element that is the body of the window - calling getBody() should get a reference to the element that is the body of the window. Adding a classname to that directly *should* allow you to style it, but there are other considerations - existing styles (your selector must be 'stronger', i.e. more specific), other widgets added that set their own backgrounds (the color might be inherited, or bleeding through, and the child widget is the problem in one theme vs another), etc. Knowing more about the widgets you have set up and how you've set the styles will make it easier to help. Learning CSS will help too - I can't explain that in a forum post unfortunately.

  2. #12
    Sencha User
    Join Date
    Apr 2013
    Posts
    6
    Vote Rating
    0
    kym is on a distinguished road

      0  

    Default Dynamic changing of color

    Dynamic changing of color


    Thank-you for your assistance. From your earlier example with TextArea, it was not clear if you were referring to the classname or the instance of the class, that was where my confusion was. How do you know what are the proper tag names? Is it required to use firefox to display that information? I will get there eventually, now that I know that is my lack of knowing css (I had only picked it up by example) that was causing most of my problems.

  3. #13
    Sencha - GXT Dev Team
    Join Date
    Feb 2009
    Location
    Minnesota
    Posts
    2,639
    Answers
    107
    Vote Rating
    80
    Colin Alworth is just really nice Colin Alworth is just really nice Colin Alworth is just really nice Colin Alworth is just really nice Colin Alworth is just really nice

      0  

    Default


    That's how CSS works - declarations are more or less tagname[#id][.classname][:psuedo-selector], with lots of other operators including space (descendent), > (child), +/~ (siblings), etc. The . and space operators are the most common, especially in GWT code, as >, ~, +, and psuedo-selectors are not always supported in other browsers, and IDs can easily paint you into a corner when building a dynamic web application.

    Proper tag names? What elements are in the rendered widget, either by default, or due to changes that you've made? Same goes for class names - what classes have you added to (or already exist on) the dom structure? Firebug and Chrome's Inspector are two good ways to discover details like that. I'd usually start with firebug/inspector, try to make changes directly in the running app, then pull out those changes into CSS and try to make that work.

    Important thought when making more than just one or two simple changes - strongly consider building an appearance implementation that makes the changes you are after. By setting up a rebind rule, you will *remove* the existing, unused CSS/images from your compiled app, and will not need to load external css files, making for a faster loading application. Additionally, fewer and simpler css rules in an app make for a faster rendering/updating dom, so there are lots of benefits of keeping things simple. The approach we've been discussing is good for a one-off change - akin to writing a quick bash script to get a simple task done - but to make it maintainable, you'll want to look into longer term options where the compiler can report back potential mistakes. We didn't rebuild GXT in 3.0.0 to use appearances lightly, and we've seen very significant performance improvements in compiled applications as a result.

  4. #14
    Sencha User
    Join Date
    Dec 2011
    Posts
    18
    Answers
    1
    Vote Rating
    0
    the.wizard is on a distinguished road

      0  

    Default


    Quote Originally Posted by Colin Alworth View Post
    kym - you can still do all of this via CSS - have you tried it? Create a css file, either with or without CssResource, and change the css class name on the widget each time the color needs to change. This is how you had to do it in GXT 2, this is how you do it with GXT 3.

    Or, just change the backgroundColor property of the style object.

    How did you do this in 2? Can you show how you tried to do the same thing in 3?

    The theming point is totally different - to change a theme in 2.x, you would load another css file into the page, which would cause it to re-render each dom element, but would not necessarily re-layout the app, which could cause issues. GXT 2 didn't really 'support' changing the theme on the fly, it just happened to work. The GXT 2 process to change themes was expensive for the browser to change, the 3 process takes more compile time but is easier for the browser.

    In general, this is a big theme of GXT 3 - to better follow the general GWT directive of using the compiler to produce code that is built for the browser. It does require an extra file to declare 'this app, but with that theme', and it does require an extra compile, but once this is done, you have finished, optimized apps that only run the code that is needed to get the app going with that theme.

    With bug fixes present in GWT 2.5 an 2.5.1, there is another option available - if you set the configuration property "CssResource.style" to "stable-shorttype" or "stable", you will get consistent (and unoptimized!) css class names, so that you can build your own external css files using those classes, and load them on the fly as you see fit. As with GXT 2, as long as those only change colors after the app is loaded, you should be fine, but if sizing or paddings are changed, layouts may need to be performed, which you'll need to kick off manually.
    Hi Colin, finally you come back to this thread, been waiting for your reply all this time. I have tried your suggestion to change the gwt.xml file to inherits the gray theme, but when I run the application is still using the blue theme
    After reading your post that I quoted above, I really confuse how to achieve my need for changing the gxt 3 theme without compiling my code. My requirement is to build one application and deploy it to a lot of customer with different theme. My customers is dynamic, where there are a possibility of new customers every month. What I want to achive is write my application code once, and when deploying to customer, I just need to do the configuration outside of my application code without changing or recompile my application code to change the application theme. Is there really no good solution for my need? Please kindly advice me Colin. I will looking forward for your advice, thanks.

  5. #15
    Sencha - GXT Dev Team
    Join Date
    Feb 2009
    Location
    Minnesota
    Posts
    2,639
    Answers
    107
    Vote Rating
    80
    Colin Alworth is just really nice Colin Alworth is just really nice Colin Alworth is just really nice Colin Alworth is just really nice Colin Alworth is just really nice

      0  

    Default


    As always, if an issue is urgent, please open a support ticket so we can try to help more directly. This will also enable you to share aspects of your application that you seem to not want to share in this public forum.

    I'm still not sure what you are trying to achieve that my first post in this discussion doesn't resolve. Build the application once, then compile with each added theme as needed. Once that first application is written, each new theme can be added by making a new module and inheriting a) the original app, plus b) the theme you now want to use. There is no *re*compile necessary - the original app can stay the same. It is only necessary to compile a version of the app where the only change is the theme used.

    The question for you is: how do you plan on declaring which theme you want to use when the page loads? Are you able to change the name of the js file being loaded (like you could change the css file)? Or since this is a different customer entirely, do you want to have a complete different html file so that each has their name on it, perhaps in the title, or perhaps has some other details changed?

    If you really want to change nothing and deploy the same app to all users, then you must have all possible themes that every customer ever might want to use already declared and baked into the build. While our approach does seem to make *development* more difficult, the end result is to make the application load faster for the users - any code/style/image that isn't needed will be completely removed from the code that is downloaded into the browser.

    For more specific details, you'll need to give specifics about your application. Have you tried what I suggested in my first post? Why doesn't it work?

  6. #16
    Sencha User
    Join Date
    Dec 2011
    Posts
    18
    Answers
    1
    Vote Rating
    0
    the.wizard is on a distinguished road

      0  

    Default


    how do you plan on declaring which theme you want to use when the page loads?
    yes when the page loads.

    Are you able to change the name of the js file being loaded (like you could change the css file)?
    no. in gxt 2 we deploy the application and replace the style.css with appropriate css file for the customer.

    Or since this is a different customer entirely, do you want to have a complete different html file so that each has their name on it, perhaps in the title, or perhaps has some other details changed?
    yes. what I want is really simple :
    write the code, build, compile, packaged into war file.
    deploy to every customer we have, and replace the style.css with the customer-specific-style.css, ie. customer AAA will get the style.css that contains the color for all text is red, and customer BBB will get the style.css that contains the color for all text is green, and so on.
    so what we do in gxt 2 is just simply replace the style.css with the customer-specific-style.css and the customer will get a different look for their own application.
    I know why you guys implement this Appearance pattern, its a good thing to implement, and have a good benefit, but I still not found the best strategy to achieve my needs.

    For more specific details, you'll need to give specifics about your application. Have you tried what I suggested in my first post? Why doesn't it work?
    yes, I have tried it. Nothing happen, the application still show up with the blue theme, which is the default theme I think.

    If I have another extra time, I will open a ticket for this issue.
    Thanks and regards.

Thread Participants: 2

Tags for this Thread

film izle

hd film izle

film sitesi

takipci kazanma sitesi

takipci kazanma sitesi

güzel olan herşey

takipci alma sitesi

komik eğlenceli videolar