Hans Bergsten

Hi Scott,

The best way to see what DbVisualizer has to offer is to download it and ask for an evaluation license. There is also lots of feature overview, online demos and the Users Guide that you can look at on our website.

Kind Regards,
Hans

Hi Gian,

DbVisualizer currently does not support any convention checking or similar analysis.

Kind Regards,
Hans

Hi Leandro,

Yes. You download the JDBC driver from Oracle's site:

http://www.oracle.com/technology/tech/java/sqlj_jdbc/index.html

Kind Regards,
Hans

Hi Leandro,

This matrix shows you the differences between the editions.

Kind Regards,
Hans

Hi,

You find a feature overview here, along with online demos for some of then:

<http://www.dbvis.com/products/dbvis/features/>;

Hans Bergsten

Originally posted by Vijay Venkat:
Hans thanks a lot. Hmm.. couldn't find a Indian edition of your book :-(. Is there any plans for Indian edition of your book?
Vijay V

I don't know. Translations are out of my control, but typically, a popular O'Reilly book is eventually translated to all languages there is demand for.

Originally posted by Vijay Venkat:
Once again Hans thanks for your explanation.
Couldn't get hold of a book today - should be getting it tomorrow.
Can you let me know in which chapter you talk about component-family and rendererType, render specific attributes in detail, so that i look directly in it.

Thanks,
Vijay V

I sure can; it's in Chapter 13, Developing Custom Renderers and Other Pluggable Classes.

Originally posted by Santosh Ram:
Hi folks!!
1. How can we use css (cascading style sheets) with JSF?
If yes can anyone post a simple example?
2. Is it possbile to use java script with JSF?

Yes, you can use both CSS and JavaScript with JSF.

CSS is very easy. All JSF components render an HTML element with a "class" and/or "style" attribute that you define. For instance, using the JSP tag libraries:
<h :-o utputText styleClass="message" />
Just the define the styling you want for the class in a regular style sheet, included or referenced from the page.

JavaScript can either be created manually and included or referenced from the page, or generated automatically by JSF component renderers.

You may want to read the spec, or a book (hint, hint), to learn more. There are also plenty of articles and tutorials online. Good places to start are:

http://java.sun.com/j2ee/javaserverfaces/
http://jamesholmes.com/JavaServerFaces/

You may also get quicker responses to your JSF questions in Sun's JSF forum:

http://forum.java.sun.com/forum.jsp?forum=427

Originally posted by Patrick Ferguson:
Thanks Hans,

I'm also posting this in the Java forum. But I tried what you said about putting the included page in <f:subview> tags, and it does something really odd. The included page is a menu page, it has some DIV tag stuff in it where it defines the links and to put my links in there I use the <h:commandlink> tag. If I used the <f:view> and bring up just that page by itself (not included in another page), it works fine. And if I include it in a page with no <f:view> tags, it works fine. But when I include it in a page with <f:view> tags and <f:subview> tags in the included page, it's like it pulls the JSF components out of the DIV tags in the included page. I don't know if this is a bug or just something I'm doing incorrectly, but I don't understand why JSF needed to make page includes so difficult.

Anyway, any opinion on this would be greatly appreciated.

That's what I meant with "there are many other issues regarding dynamic includes". You need to wrap all non-JSF elements within <f:verbatim> elements in the included page as well.

But again, do you really have to use a dynamic include? A static include (i.e., <%@ include file="..." %> doesn't have all these issues; you just include the file without adding any wrapping elements. Dynamic includes should be used (in JSF) only when you don't know the name of the file at design/compile time to avoid all this extra complexity.

Originally posted by Vijay Venkat:
Hi
I am able to understand the concept of a render kit - which is something similar to different look feel in swing.

It is clear that a Component has a renderer associated with it for it to be rendered.

Why do we associate a renderer type with a component family?

Is it that many components can share the same renderer?

<renderer>
<component-family>javax.faces.Input</component-family>
<renderer-type>com.company.sometype</renderer-type>
<renderer-class>com.company.SomeRenderer</renderer-class>
</renderer>

Does it imply that there can be components whose renderer types are not set and in these cases we can get the renderer based on the component-family?

but why is the component-family specified with in the renderer and not in the component itself?

I am seriously missing the concept which connects the components, family and renderers

Any pointers to this would be very useful.

Thanks,
Vijay V

This is tricky, and I explain it in much more detail in my book, but basically, this is how it works.

There may be many different render kits with renderers of the same type, say one with renderers for HTML and one for WML. Components are associates with renderer types (symbolic names for the renderers), so that by switching the render kit for a view, all components will use the same type of renderer from the new kit without having to reassign new renderers for the components.

Each components belongs to a component family, for instance "javax.faces.Command", and each renderer supports components that belong to the same family. This makes it possible to use the same renderer for all component classes with the same basic behavior, e.g., that of a "command". A concrete example, say you want to subclass the UICommand component to add additional behavior. By declaring that your subclass belongs to the "javax.faces.Command" family, you can automatically use the standard Link and Button renderers supporting this component family.

Hope this helps some. If not, you may want to ask for clarifications in Sun's JSF forum: http://forum.java.sun.com/forum.jsp?forum=427

You must use <f:subview> instead of <f:view> for the included page if you use dynamic includes. There are many other issues regarding dynamic includes, so I recommend using static includes whenever you can instead. If so, no <f:subview> element is needed because the content of the statically included file ends up as part of the including page before it's compiled.

For questions about JSF, I recommend Sun's JSF forum:
http://forum.java.sun.com/forum.jsp?forum=427

I try to answer some questions here, but you have a much better chance of getting an answer in the JSF forum.

Originally posted by Vijay Venkat:
Hi

I would really appreciate if any one can let me know what is a property of a component and attribute of a component in jsf world.
[...]

The core components in JSF are "rendering independant", meaning that they define behavior that is the same no matter how they are rendered. For example, a UICommand component can be rendered as a link or a button, but the behavior is the same. Another examples is a UIInput, which may be rendered as one input field for text input, or as three fields for year, month and day input, or as four fields for credit card number input; the core component behavior is the same no matter how it's rendered.

The rendering and decoding of input for a component is delegated to a separate Renderer attached to the component. So, for instance, if you want a UICommand rendered as a link, you attach a Link renderer; if you want a button, you attach a Button renderer.

With that background, it's easy to describe the distinction between a component "property" and an "attribute".

All rendering independent configuration items for a component are specified as a set of regular bean properties, i.e., by type-safe get and set methods. For the UICommand component, "action" is one example, used to bind the component to a method invoked when the command is triggered.

All rendering dependent configuration items are specified as generic attributes, represented by entries in an attributes Map that the Renderer attached to the component reads. UICommand/Button examples are "alt", "disabled", "style", and all the other HTML attributes that are supported by an HTML <input type="submit"> element. Using generic attributes for rendering dependent stuff makes it easy to develop new Renderers that need new configuration items, because the component class doesn't have to be modified with new bean get/set methods.
[ June 12, 2004: Message edited by: Hans Bergsten ]

Originally posted by Blake Minghelli:
I'm just starting to delve into JSF. I read a user post (I think maybe on theserverside.com) that criticized JSF because you are forced to use a single servlet to process all requests.
Can anyone comment on the validity of that statement?

Is it a valid statement? Yes. The JSF specification requires that all requests for JSF views go through the single JSFServlet, which sets up the JSF environment and delegates the processing to the requested view.

Is that a problem? Of course not! I don't know why the user you quote used this to critize JSF, but I'm seen other misguided souls think that forcing all requests through a single servlet results in a bottle neck. That's totally wrong. A servlet is multithreaded, so it handles as many concurrent requests as the server can handle. Using more than one servlet, on the other hand, theorethically has a performance impact because of increased memory usage and more context switching.

Note that Struts, Tapestry and probably most sother ervlet based frameworks also use a single servlet as the entry point; this is common practice.
[ June 12, 2004: Message edited by: Hans Bergsten ]

I promised last week to alert you when my JSF article about problems related to the JSP layer, and how they can be fixed, was published. Well, now it is:

http://www.onjava.com/pub/a/onjava/2004/06/09/jsf.html

I hope it will lead to some interesting discussion regarding a better alternative than JSP for the JSF views in a future version of the spec.

If you've used Tapestry, you may also want to read it to see how JSF applications can use the same kind of true separation of HTML templates and the components that generate the dynamic content.

Originally posted by Alvin chew:
hi, have a nice day ! i have try coreservlet struts tutorial before , it cool ..and make me little bit understand on struts , can anyone please suggest some struts tutorial website ? besides, i'm new in JSF, kindly please provide me some good link as well ..thank in advance !

[ June 08, 2004: Message edited by: Alvin chew ]

This is a good place to start: http://jamesholmes.com/JavaServerFaces/