We Keep Coding

Adding a java.awt.frame to a vaadin layout

I'm working on a vaadin page, but one of the elements I want to put in my VerticalLayout is a java.awt.Frame. Is there a way to do this in vaadin?

As said in the comments, you can't use Swing/AWT stuff in Vaadin since it will be converted to Javascript and DOM to be used in a browser.
If you get a hold on the JS file TeeChart uses you can basically implement a custom client-side widget that will use it.
Take the basic demo here what you have to take care of is that there is a <canvas> tag to render the content in and that the draw() is called at a phase when Vaadin is done creating the surrounding DOM structure.
Please have a look at this tutorial to get an idea on how to wrap a JavaScript library to a Vaadin component.

GWT - DecoratorPanel - dynamic background color

I wondering how to set background color for DecoratorPanel dynamically? All examples I could see just showing CSS static modification but I couldn't find any dynamic examples. If you have some helpful snippets please share

For dynamically editing styles, you can use the Style object, reached via the underlying DOM Element. Something like the following should work:
DecoratorPanel panel = new DecoratorPanel();
panel.getElement().getStyle().setBackgroundColor("#000000");
Doing this will assign an inline style to your element in the DOM. You'll find methods for most properties on the Style object, with "setProperty(String, String)" available for your more rare style needs.
If you are only changing backgrounds between a few preset color, you may also consider simply changing a css class name on the panel. This gives you the benefit of keeping all background styling within css. You can do this via:
panel.addStyleName("css-class-name");
and
panel.removeStyleName("css-class-name");

JSF 2.0 Dynamic Views

I'm working on a web project which uses JSF 2.0, PrimeFaces and PrettyFaces as main frameworks / libraries. The pages have the following (common) structure: Header, Content, Footer.
Header:
The Header always contains the same menu. This menu is a custom component, which generates a recursive html <ul><li> list containing <a href="url"> html links, this is all rendered with a custom renderer. The link looks like 'domain.com/website/datatable.xhtml?ref=2'. Where the ref=2 used to load the correct content from the database. I use prettyfaces to store this request value in a backingbean.
Question 1: Is it ok to render the <a href> links myself, or should I better add an HTMLCommandLink from my UIComponent and render that in the encodeBegin/End?
Question 2: I think passing variables like this is not really the JSF 2.0 style, how to do this in a better way?
Content:
The content contains dynamic data. It can be a (primefaces) datatable, build with dynamic data from the database. It can also be a text page, also loaded from the database. Or a series of graphs. You got the point, it's dynamic. The content is based on the link pressed in the header menu. If the content is of type datatable, then I put the ref=2 variable to a DataTableBean (via prettyfaces), which then loads the correct datatable from the database. If the content is of type chart, I'll put it on the ChartBean.
Question 3: Is this a normal setup? Ideally I would like to update my content via Ajax.
I hope it's clear :)

It's ok to just output link yourself, commandLink is out of the question (it does a postback using javascript, it's not what you want);
Parameter are all in the param implicit object. You can insert them by a #ManagedProperty annotation, like this:
#ManagedProperty("#{param.ref}")
String ref
// .. getters, setters (obligatory!)
You can also use (if you are on JSF 2) the f:viewParam tag (a nice description http://blogs.oracle.com/rlubke/entry/jsf_2_0_bookmarability_view), you get the bonus of validation and conversion.
The way I understand it, your setup is rather complicated. Using a handwritten custom component for a menu is a huge overkill (at least judging from the provided description), a composite component would probably do. JSF has no special way of making ajax calls between views or embedding views one into another, so - unless you use iframes - your only choice would be to include all the possible pieces of content into a single view, wrapped in panels, and render them as required:
<h:panelGroup rendered='#{backingBean.ref == 2}'>
... content 2 ...
</h:panelGroup>
and so on. Careful, this would be heavy on resources.
You could also write your own ajax solution in javascript. This would require all the pieces of content to be fully independent views, with their own forms. Also, all their postbacks would have to go through ajax, so the main page does not get reloaded.

Understanding Tapestry Principle 1. "Static Structure, Dynamic Behaviour"

I'm learning tapestry 5 web framework but I don't understand the principle 1 about it:
"Static Structure, Dynamic Behaviour", what does means it ?
If I don't add components to the components, how can I create a dynamic page?
anyone can help me?
Thanks in advance

It means that you can't choose or replace components at runtime effectively.
If, say, you'd want to build a portal solution where users could arrange components on a screen any way they wanted, Tapestry would not offer an effective way to do that, because components have static structure, i.e. you must define what goes into them at compile-time in their template file.
Or you might have a specialized menu for administrators, so you might want to just replace the Menu component with a derived component, AdminMenu - but you can't, you have to use if statements in the template or use a block to inject different menus into your layout component.
There's an anti-pattern related to this limitation: The God or über-component tries to solve this problem by effectively having a giant template file with all the available components, like this:
<t:if t:test="displayComponentA">
<span t:type="ComponentA" ... />
</t:if>
<t:if t:test="displayComponentB">
<span t:type="ComponentB" ... />
</t:if>
...
This, however, is horribly ineffective, as Tapestry assembles the entire component tree, including components that are not displayed, to do the rendering of the page.

Tapestry uses templates to define static content. These templates are usually html pages with placeholder variables which are replaced by some code dynamically by the framework. Templates allow for segregation of things that not change from the ones that change. Usually structure is less prone to change then behavior. Even if you want to change some element of a component dynamically you're going to use some component that itself is defined by a template that is dynamically filled with data. This dynamic data again can insert some other component etc.

Static structure doesn't mean that you cannot output dynamic content nor that you cannot add components to components. You just cannot add a component to another at runtime. You can define a page or component structure using other components, but this is all defined in the template, before the page is rendered, never while it's rendered. A component can choose not to render itself, to render part of its template (If and Unless components), etc.
One of the few practical situations caused by the static structure of Tapestry is that a component C cannot use another instance of the same component inside it.

The default look of Icefaces and how to customize it

I have a question about styling Icefaces. I have a minimal application that can use Icefaces components, but when I use them and view the page, the components are not styled (for example the buttons have the default look and tabs have no look at all, no images, nothing). I was wondering why that is and what I should do so I would get the default Icefaces look to work.
Next thing I don't get is how do I customize the look by changing some default css style classes that get applied to the components automatically, so every component I use gets the changed style.
Thank you for your answers!

I suggest that you take one of the existing style-sheets, which are included within the ICEfaces package (check the resources folder of the downloaded ICEfaces-1.8.1-bin.zip):
rime
royale
xp
You can preview them in the ICEfaces showcase
Include it within your *.xhtml file via the <ice:outputStyle> tag:
(portlet)
<ice:outputStyle href="/xmlhttp/css/rime/rime-portlet.css"/>
(servlet)
<ice:outputStyle href="./css/demo_template.css"/>
Starting from here, feel free to either manipulate the chosen stylesheets or - which I favor - include your own stylesheets after ICEfaces' ones and overwrite the needed styles.
Regarding your second question:
Basically every ICEfaces component has its own style class. Just browse around the showcase and inspect the components with Firebug. I've not found many classes, which have been reused between different components. Therefore, you'll have to customize each and every component on your own - or apply your own common style class to every component you use via the styleClass property.
<ice:panelGrid styleClass="myCommonStyleClass">
<ice:inputField styleClass="myCommonStyleClass">

There are three predefined ICEfaces style sheets included:
(1) xp.css
(2) royale.css
(3) rime.css
Developers may also create their own custom style sheet based on a predefined ICEfaces style sheet. If the style class names match those defined in the ICEfaces style sheets, the ICEfaces components will use the specified styles by default, without the need to specify the style class names explicitly on each component.
(1) Where to find CSS class names ?
IMPORTANT : The default CSS class names associated with each component are listed in the component's TLD (taglib) description.
(2) How To use a predefined style :
<link rel="stylesheet" type="text/css" href="./xmlhttp/css/xp/xp.css" />
OR
<ice:outputStyle href="./xmlhttp/css/xp/xp.css" rel="stylesheet" type="text/css" />
(3) Is there any Advantages of using ICEFaces OutputStyle ?
The ice:outputStyle component has the following advantages over the HTML link tag:
- Automatically includes browser-specific variants of the main style sheet in the page to adapt the theme styling to account for differences in each browsers' CSS support. See the TLD (taglib) documentation for the ice:outputStyle component for details.
- Provides the ability to dynamically change the theme style sheet at runtime via a value binding on the component's `href` attribute.
(4) What is meant by xmlhttp ?
The xmlhttp->css->xp path is automatically resolved by ICEfaces and all needed resources are loaded from the ICEfaces.jar
Hope this helps..!! :)