I made a research, but I didn't find anything to helps me answer this question
When you have a flex project, is it better to use different skins for different components or to use just one big css that has all the styles together?
It is not very clear from the question are you talking about standard components and their custom skins/styles or you're talking about custom components and ways to design them to be customizable?
Anyway I'll try to answer. Spark architecture isn't reject styles and using CSS for component's customization. All the standard components support styles and have out-of-the-box skins which support them. So if you're using standard components with standard skins and it fits your requirements it is better to use available styles for additional customization.
If standard skins of standard components don't fit your needs you have to decide which strategy to choose:
Create skins which support additional customization with CSS. You can choose this option if you're creating some skins for external use (for some other developers or teams). It gives them possibility to use your skins without modification and with additional customization. If you're creating custom components for sale or for a client you also should choose this strategy.
Create skins without additional customization possibilities (all the values such as colors, icons, fills, strokes, fonts are hardcoded). This is the easiest way to create skins. And it allows you to perform skin's modifications easily. You should choose this options if you're creating skins for the particular project with particular look and feel. The main advantage is you can create and modify skins very simple and fast with more flexible usage of external tools such as Flash Catalyst.
Related
I have something on my mind for quite a while but couldn't find an answer to it. Consider the following:
You like to build a fancy website with React and have to decide which front-end framework you should use. In my example I have chosen Material-UI.
Now you came to a point where you need more features like a responsive grid system, show/hide styles etc. Instead of implementing them on your own (or copying it from bootstrap/foundation, for example) you think: 'Hey, why wouldn't I include another framework beside Material-UI'.
Now comes the question. I know that most of the css frameworks available have their own normalisation css and basic styles for typography and other elements.
Can I safely include another (more featured) css framework beside Material-UI without breaking fundamental things or should I avoid that?
Furthermore, what is a good practice approach to extend the css features without copying parts from other frameworks and without reinventing the wheel all the time. Did you ever had a case or project where you had to combine multiple front-end frameworks and how did you solve this problem?
Thanks for your feedback.
Cheers
Gregor
FYI, there's a Material Design version of Foundation, you can check it out at http://eucalyptuss.github.io/material-foundation/
Now, talking about your doubts... one should be very careful when mixing and/or using more than one framework at the same time... one issue can be conflict, other can be unnecessary bloating which could make load time heavier.
However, if you are aware of that, most of modern frameworks (as Foundation) can be compiled partially, so you will be loading only the stuff you'll use, minimizing all possible issues.
Have been thinking this exactly thing lately.. I would choose one that has most of the features i need in my project. I usually go just with Bootstrap (sass version) and use only the styling part of that (css grids mostly).
Mixing frameworks will eventually be hard to maintain and you have to include lot of extra (unused) features into your application. When using some "cool", full featured components like Material-UI has, there will still be times when some component doesn't have just the property you would need.
So my opinion is:
Use some framework for styling only. This way you have uniform look in your site. Or even just some responsive grid library could be enough.
Usually basic html components are enough to fill basic needs, you can just build your own custom components for special needs (or use some from npm library). This way you have just the features you need.
This way my site is not depending just some single framework. I can change the styling part anytime, i can change one component to another etc. without having to re-write my whole application just because it's been developed entirely with some "full featured" framework.
I am starting a developement of a big project and I need to know if to use ViewEncapsulation None or Emulated.
From some reason the default is Emulated but I noticed that Angualr2 Material uses None.
We need to have reusable widgets within the projects and have different styles and also dynamic themes.
I know it's can be done with Emulated but is seems more difficult to manage and not as simple as using CSS rules or override.
What should be the recommended mode for such a project?
The benefits of using 'Emulated' option is, that You will be able to create encapsulated components(styles, template, etc.). Also it will help You to not only create component once(dropdown, table, popup) and reuse it within your current project, but also it can be used in different projects later or being open-sourced, if You will.
The recommended way is using the Emulated option.
It will give you the ability to encapsulate your component, not only the HTML template, but also the styles.
This is the future. It is called web components and I strongly advise you to read about it. For more details, see:
Modular future web components
Shadow DOM strategies in Angular 2
I have a project where we are trying to skin Spark components from a third party library that are built up from the drawing API primitives. Our first attempt involved creating a Flex skin (SWC) in Illustrator/Flash and applying that skin to the Spark components via CSS. We found that even with only a single instance of one of the components skinned in this way on stage, the application was brought to it's knees. For example, it failed to respond in repaint scenarios in a timely manner, and exhibited all the symptoms of being hung.
Our next approach will be to recreate the same skin artifacts in MXML classes that are in turn associated with the third-party components. Although the complexity of some of the skins leads me to believe that we might not avoid performance problems with this approach either.
My question is the following: Is there a correct or recommended way to apply either a SWC or based skin to a component that is built up from the Spark drawing API to begin with? Even as I ask the question I recognize that the approach means using the Spark drawing API in two places and will probably have unexpected consequences.
I've had good luck building the skins using MXML skin classes that inherit from s:Skin in terms of rendering performance. The recommended method (from Adobe) is to start by copying an existing skin file from the SDK and modifying the MXML to suit your needs. Regarding drawing, FXG works very well for defining how you want the skin to be drawn. FXG is XML based, so you don't need to write ActionScript to do your drawing, like we used to do for Flex 3 programmatic skins. You can also create skins using Adobe Catalyst. I have not used Catalyst, so I can't speak to its effectiveness, but many people seem to like it. Hope that helps.
This may be more of an opinion poll than a question, but here goes. I have a fairly complex Flex application that uses many different components. I want the application to be able to custom styling and/or skinning. I also want to be sure that the styling approach makes the most efficient use of system resources (memory, CPU, network), and that it does not adversely impact performance.
We currently are using a hybrid approach to styling the application that uses both CSS and a Flash skin created in CS3. It seems odd to me to have a two-pronged approach to styling an application and ideally would like to settle on one approach or the other. Can someone outline the advantages and disadvantages of using either exclusively CSS or a Flash skin? Is there a justification for using both within the same app?
Using CSS exclusively seems advantageous because it is approachable by anyone with a basic understanding of other uses of CSS, especially when using the Flex 2 Style Explorer. On the other hand, I know that the CS3 skin we use declares up/over/down/disabled/pressed skins for each component where these states are needed and Flex manages the transitions to the appropriate skins as each state is (de)activated. However, my impression is that creation of a Flex skin in CS3 requires somewhat specialized skills and tools.
So what would you recommend for styling a Flex application if performance, customization, and efficient resource utilization are priorities?
First, I would suggest using Flex 4 if you haven't started already. Flex 4 is just about to be released.
With Flex 4, they have a whole new skinning architecture. This means you'll never use Programmatic Skins again. Plus they have Advanced CSS Selectors, so you can do way more with CSS in Flex 4. Programmatic Skins are very hard to make dynamic anyways. In the end, you'll end up creating an architecture like Flex 4 Spark Skins if you try to abstract out the logic for Programmatic Skins.
Customization
What we're doing to make Flex 4 Skins and Styling as dynamic as possible is the following:
Style Palletes: Either static classes, or XML files
Custom Skins
CSS
Style Palletes: These are static classes that hold all of the variables you use in either CSS or Skins. For example, you can have a ColorPalette that has all of your colors: public static const ColorPalette.BRIGHT_RED:uint = 0xff0000;, etc. You can then use these in Flex 4 Skins via binding, such as <mx:Button color="{ColorPalette.RED}"/>. The only problem with static classes is they they're not dynamic (you couldn't define an arbitrary number of colors for them). Same with XML: you'd have to hard-code (eventually) a certain XML structure in order to use them in Skins. You could even have the XML define ColorPalette values (so ColorPalette.ACCENT_COLOR could be set to anything from XML (gold, bright blue, or any accent). Fun stuff.
Custom Skins: Flex 4 allows you to easily skin all the Flex 4 and Flex 3 (datagrid, accordion, etc.). So if you don't like how Panels only have 1 drop shadow and no gradients, you can add a background with 4 gradients and 2 dropshadows (for 2 angles of light), and maybe some rollover effect. And then you could apply your ColorPalette.BRIGHT_RED to the shadow (or a glow :)). And you could have XML configure the ColorPalette settings. Here's a cool custom Flex 4 Skin
CSS: Then in CSS, you could write a very simple Palette parser that applied your ColorPalette values (for example) to CSS. Check out the Degrafa CSS Skin for some code examples.
Performance
The only problem with Palettes and CSS is performance. By definition, static class and binding decrease performance. Binding causes lots of event dispatching in the background, so things like <mx:Button color="{ColorPalette.RED}"/> decrease performance (not noticeable of course, since there are much worse applications, such as using built in Adobe Tweens), but it does to some degree.
Same with CSS. In Flex, every CSS Selector (Panel { properties:values... } is converted into an Object. So if you have 100 selectors, you get not only 100 extra object, but 100 extra classes in your application, at least! And that definitely adds to your swf size. And all of their properties are dynamic, and by definition, dynamic classes are slower than non-dynamic classes. Plus, setting a style (with setStyle(property, value) in Flex is very slow because you have to loop through all the children. If you're setting styles via an admin system (or something like Flex Style Explorer like you suggested), then you don't really care. But because they use setStyle(), you can see a decent performance hit when changing styles.
So if performance was a super big issue, the best option would be to hard code every style value, and not change styles at runtime (who needs to do that anyway (unless your in the admin section)?). How do you hard code styles while still remaining agile? Use Palletes (ColorPalette.BRIGHT_RED) and the like, and convert the binding expressions (<mx:Button color="{ColorPalette.RED}"/>) to static declarations via some preprocessor (I use ruby to compile my swfs, so I just match patterns and replace). So it'd convert <mx:Button color="{ColorPalette.RED}"/> to <mx:Button color="0xff0000"/>, and you get a performance boost.
In the end though, it's best to create custom skins and define the styles there, either through:
static declarations <mx:Button color="0xff0000"/>
palette declarations <mx:Button color="{ColorPalette.RED}"/>
xml declarations <mx:Button color="{myxml.#button_color}"/>
Then you can define some really cool and advanced skins and have them wired up to a palette or xml file and have the user edit that. Trying to build a very cool and modular skin/styling system with Flash or Flex using their built in stuff is not easy (nor desirable). So it's best to
create a set of skins (and package them up as a theme)
wire skins to xml
let user modify xml
Avoid CSS, it's too processor intensive, unless you need advanced selectors like you'd use in HTML because it does make life easy. But for modularity and customizability (and performance), create Skins and wire them to XML.
I myself create a basic theme that I can use in all of my client projects, something that defines my style. That consists of 3 packages (myskins, mx, spark). In there, I copy/paste all the default Flex 3/4 skins and start customizing. You can download a Scale 9 Skin Project for free to have most components ready to skin and test. Then I just merge my design (photoshop or whatever) into Flex however you choose. For all the colors I reuse, I add them to a palette and eventually to XML. Then if I need a slightly different skin and I use that multiple times, I use CSS to define a new style for a skin (maybe a list with no background color or border). My CSS is very lean. Then I can just copy/paste my theme/palettes/css to new projects, modify it as needed, allow the user to edit the colors and positions via xml (or an admin interface) and I'm ready to go.
You can't do that much with just CSS.
Hope that helps.
Lance
I've always exclusively used CSS. You stated it best that it is approachable by anyone. We can delegate the design to people that have no idea how to code in actionscript and they have no problem working with the css and the style explorer (updated for flex 3 at http://examples.adobe.com/flex3/consulting/styleexplorer/Flex3StyleExplorer.html, haven't compared too much to find out whats different vs the flex 2 version).
If performance and flexibility are the two most important considerations for your skins, you should consider Programmatic Skins.
See: Programmatic skinning - QuickStart
To quote Adobe:
"One advantage of programmatic skinning is that it provides you with a great deal of control over styles. For example, you cannot control the radius of a Button control's corners with style sheets or graphical skins, but you can by using programmatic skins. You can also develop programmatic skins directly in your Flex authoring environment or any text editor, without using a graphics tool such as Adobe® Flash®. Programmatic skins also tend to use less memory because they contain no external image files."
Fore more info, you can also read "Creating programmatic skins" in the Adobe LiveDocs Help Docs.
I'm developing a Flex application. Since I'm not a very talented graphical designer, I leave all stylings etc. at their defaults. Once I finish the app, I would like to give it to a graphical designer, together with all the fonts, icons, styles etc. that Flex has put into my app, so she can swap them out and make my app pretty and theme it to my CI.
Also, I'd like to use this approach as the foundation for interchangeable themes at a later stage.
There's two parts to my question, really:
a) how do I get all the assets that are used in my app (not simply all that the Flex framework has bundled) extracted, and
b) how do I figure out which asset is used in which place, so the designer doesn't have to guess and reverse engineer.
There's a third part (how do I repackage the assets to make them swappable at run / compile time), but I think I know how that works, roughly.
I don't believe you can do that. You will have to set up skinning yourself. The default graphics used in the components are built into the flex framework and generated at runtime using the drawing api instead of embedding graphics.
Your best bet is going to be to use css and a graphics framework that supports skinning like degrafa ( http://www.degrafa.org/ ).
If you want to check out the code that generates the base skin for flex 3.x you can have a look in the svn repo here - http://opensource.adobe.com/svn/opensource/flex/sdk/trunk/frameworks/projects/halo/