RE: [Trinidad] Components provided by issues 663 and 664

[Steven Murray <st...@capgemini.com>]

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. 
 
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.  
 
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 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.  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.  The best component suite is the one in which you don't need HTML supplementation or have to write custom components.
 
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.
 
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.
 
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
 

Re: [Trinidad] Components provided by issues 663 and 664

[Adam Winer <aw...@gmail.com>]

On 9/8/07, Andrew Robinson <an...@gmail.com> wrote:
> Some quick responses inside
>
> On 9/8/07, Steven Murray <st...@capgemini.com> 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
> >
> >
> >
>

Re: [Trinidad] Components provided by issues 663 and 664

[Andrew Robinson <an...@gmail.com>]

Some quick responses inside

On 9/8/07, Steven Murray <st...@capgemini.com> 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
>
>
>