They can certainly be on the same page, but you might want to consider the order in which you use things. My friend Jason may chime in on this one because we discussed this a while back, but I believe we determined it was best to use first ICEfaces/Richfaces tags if you're using them, then JSF, then Seam. So if the first framework has it, use it, if not, move to the second one and use it etc.
Jason, is that how you remember it?
As to the version question, I'll have to defer, but there are some limits to which version of Seam works with which version of JSF.
What controls from other frameworks are you talking about? There are some that do not work (I remember people talking about Tomahawk controls being bad). As far as the version you should be able to use a JSF 1.1 or JSF 1.2 version. Most people are using 1.2 and the RI at that as Myfaces 1.2 is fairly new.
Ray has it pretty much on the order. I have since changed my mind though 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).
EDIT: Make sure you have the namespaces setup in your XHTML files for those other controls otherwise facelets will not know what they are. [ October 08, 2008: Message edited by: Jason Porter ]
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 ]