On 9/8/07, Andrew Robinson <[EMAIL PROTECTED]> wrote: > 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.
Yep, totally agree. AJAX is the easiest way for two component frameworks to be incompatible; and the Trinidad architecture very intentionally is separated from the components - there's a core JS API and a fairly simple Java API as well that aren't tied to any of the components. > > 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. Indeed, I would hope that JBoss users would have no reason not to use Trinidad. > > 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. Very true. > > > > 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. Total agreement. > > 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. I'll never really buy into a total separation here - the two *are* connected - but I do agree that Trinidad components should be layered on top of a component-independent AJAX framework, as in fact that's how I designed the thing. -- Adam > > > > > 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 > > > > > > >
