There are a couple of questions in this
thread, so let me address them in turn:
One thing that I found did not work was to use in the same page a Seam JSF Control with another JSF Control which is not from Seam? Is that possible?
There is absolutely no reason you should ever have a conflict using a Seam JSF control with any JSF component library. The reason is that Seam JSF controls are nothing more than utility tags. They do not import any other resource into the page (such as an Ajax bridge) and they don't modify the UI component tree in any way (a common problem with integrations). The JSF controls do three main things:
Fix bugs or annoyances in JSF (e.g., create select items from lists and provide a time-zone aware date converter) Propagate the current long-running conversation Create GET-based command controls The only real conflict from a design perspective is #3. JSF was designed to process user-generated events on a postback, which gets its name because it performs a POST and because it restores the UI component tree. The GET-based command controls are action-based, which means they create a fresh request and then execute an action at the start of that request (the possible actions are numerous). The GET-based command controls "break" JSF in that they don't follow the
philosophy (keep in mind that they don't submit form data either, so they are no good as form submit controls). But truthfully it is a personal preference about how you want to design your application. They certain don't cause conflicts with how the other component libraries work.
Also, is Seam still tied to specific JSF versions?
Yes, you have to use JSF 1.2. Seam is very adamant about not supporting older versions for no good reason. JSF 1.1 has serious flaws and Seam basically said, "The hell with it. You shouldn't be using it anyway." The recommended implementation is Mojarra (Sun), though you can use Apache MyFaces 1.2 as well.
Is Seam tied to JSF?
No, the core of Seam is now JSF-free. One alternative is Wicket. Keep in mind, though, that a good portion of Seam was designed to leverage JSF, so you do lose features by choosing not to use JSF, such as those that rely on Facelets templating (email, PDF, excel, etc).
[ October 08, 2008: Message edited by: Dan Allen ]
I think it should be ICEfaces / RichFaces / Whatever else you're using then Seam then JSF. The reason behind this that you get better integration if you use the Seam components <f:selectItem> for example. The Seam version is much easier to use if you're doing some value bindings. If you use <s:commandButton> and <s:link> then you can add some conversation propagation attributes to it. Also if you're using <s:link> then it actually goes through the JSF lifecycle even though it is a GET (someone correct me if I'm wrong there).
