Some quick responses inside On 9/8/07, Steven Murray <[EMAIL PROTECTED]> wrote: > I have been watching this thread and I think this is an important topic. > However I want to make the following comments. > > 1. Since the JSF specification has no input on AJAX and to me there are > several viable AJAX frameworks, none of which really play well together, I > don't buy the argument that Trinidad's AJAX implementation has to be separate > from the Trinidad framework.
The reason to make it separate was the idea to allow Tomahawk and its sandbox to use a common AJAX framework. It doesn't seem like the best solution to have a separate PPR for the tomahawk/sandbox project that makes tomahawk and sandbox incompatible from Trinidad. The schedule component is problem the most important Tomahawk component as no other component library has done anything remotely similar to it, and it is very robust in its feature set. > 2. It is clear that Trinidad's approach is conceptually different than > AJAX4JSF approach for JSF. Maybe this is good, both should learn from each > other but keep true to their own concepts. Underlying Trinidad is an Oracle > approach and underlying AJAX4JSF is a JBOSS/Exadel approach. The reality is > that while both are open source each is controlled by a company with a > particular vision or technology ownership. Until the JSF community decides > on how AJAX and JSF *should* work together I don't see any reason for > Trinidad to accomodate a different approach over the one it is using. I agree that a different approach is good, I just don't agree that the PPR functionality should be private to the inner workings of components. A few more components to expose this functionality for use in views without any coding necessary would be extremely helpful to users. > > 3. The argument that we are going to want to mix JSF component suites (plus > maybe build a few custom ones) is desirable but at this early stage in JSF > often impractical. I wonder why Andrew, who seems to be JBOSS centric, feels > the need to be using Trinidad components. I am not JBoss centric, I just use the best tools for the job. JBoss-Seam has no competition in the JSF space with its functionality offerings. Trinidad components are the best components for the job. Seam has components, but it isn't a component library, Trinidad has some back-end functionality, but is a component library, they should work together. I have used A4J in the past and its AJAX based components provide a lot of required functionality that isn't provided by Trinidad, so is necessary to have to write custom components to expose these capabilities. > I suspect it is because overall Trinidad has the most comprehensive set of > components available and he is sprinkling in one or two other components from > various other suites for special needs. I am using other component libraries, MyFaces Tomahawk included, but the only one I am using with built-in AJAX support is Trinidad. If you feel that developers can only one component suite, you must never have built a JSF based web site for a large project. Have you? > My recommendation to most JSF developers is to stick with a single suite > because mixing and matching suites that have significant AJAX capabilities is > difficult if not impossible. If you were tracking this thread carefully, you would have seen that that was my assessment. There are other non-AJAX component libraries out there that should work (like the JBoss-Seam components -- their AJAX is a JavaScript function invocation framework, not a PPR framework, so the two don't conflict). > The best component suite is the one in which you don't need HTML > supplementation or have to write custom components. There is no such thing, and never will be. That is the same as saying that Swing components provide all the functionality ever needed by all companies of the world and no one should ever have to write a Swing component again. > > 4. I have voiced this before but I am concerned with Trinidad being a > subproject of MyFaces (not Apache) because I can never figure out if MyFaces > is about a reference implementation, components (Tomahawk, Tobago, Trinidad > none of which really play well together), or add-on features (Orchestra). > Then we have Sun over there in java.net doing their own thing with Dynafaces > etc. Trinidad should be project level. Why shouldn't Tomahawk and Trinidad play well together? I know why Tobago doesn't because if its architecture, but there is no reason why the other two shouldn't. > > 5. There are too many JSF component suites that are poor quality and few that > are of sufficient quality to do production level work. I am more interested > in a stable component suite then in having all kinds of side feature > discussions. Moving this feature outside of the "core" trunk is the right > thing to do. We can make it an add-on feature and in the process of making > it an add on the discussion should be more at the level of exposing the > necessary "core" public API's required to construct the add-on. Eventually > the community will look at these add-on features and determine which ones > should become core. If your component library is the only library that uses AJAX that users are allowed, then the AJAX features have to be exposed in an easy to use way. You are contradicting yourself here from your earlier comment saying users have to chose only one library and live with it. Using similar arguments to your own, an AJAX framework has nothing to do with a component library, and a very good argument should be made that Trinidad shouldn't have a built-in AJAX framework, as it should only worry about rendering components and not about AJAX. > > 6. I would like to see Trinidad come out with more information for those who > feel the need to write their own custom components when using the Trinidad > framework. > > Steve > > >
