myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Robinson" <>
Subject Re: Thoughts on Trinidad
Date Mon, 29 Sep 2008 14:57:25 GMT

Somehow I royally messed up the Jira query and re-ran it this morning.
There are 285 issues that were either improvement, wish or new feature
requests that have been made to Trinidad.

After thinking more about this email, I should have taken a different
approach. After mulling it over some more (I had been writing the
email for a while, but for some boneheaded reason, I don't re-think
things until after I send the darned emails), I don't think that
creating a new library is a good choice at all. I was just thinking
that a new library would not solve anything and in fact probably would
lead to a less involved library anyway.

I guess what I really wanted to know, was:

1) How many people are willing to work on the lingering Trinidad
issues (bugs or improvements) that have been open for many months?

2) How can we as a community get some of the old code cleaned up?

3) What is holding us back on things like removing UIXNode-based renderers?

4) What do people thing is a good way to get some excitement around
Trinidad to get these old issues cleaned up?

5) What is the best way to tackle issues of changes to the API in
Trinidad that don't belong in the Rich Client and be able to keep both
frameworks happy?
5a) for example, how can functionality that only belongs to Trinidad
be added to UIXComponentBase without causing problems?

6) Are people interested in making Trinidad's API more open (more
public, non-final methods in API classes, more hooks to be able to
customize aspects of Trinidad)?
- Possible examples: adding PPR hooks to allow renderers to do more
than just DOM element replacement on client ID, adding onComplete like
functionality to use with autoSubmit.

I think this is really want I want to get at. For me to see no
progress for over 6 months on many issues, not see people's patches
applied, etc., is disheartening. I am part to blame and should also be
helping close some of these issues.

So what do you think?


On Sun, Sep 28, 2008 at 4:40 PM, Andrew Robinson <> wrote:
> After working and using Trinidad for about a year now, I have noticed
> that although there have been many releases, the project just doesn't
> seem to be progressing. I am curious what other MyFaces members think
> about this. Just by browsing JIRA, it seems that almost all the work
> is done is bug fixing, but not enhancing Trinidad. Here are some
> disturbing JIRA statistics from last week:
> - 331 open issues in Trinidad
> - 239 are bugs in an unresolved state, 14 with a patch available and
> 154 of which are over 6 months old
> - 14 bugs are marked as blockers or critical, 9 of which over 6 months old
> - 140 unresolved improvement, wish or new feature requests, 21 with a
> patch available and 114 of which are over 6 months old
> - Only 4 issues are in progress, only 1 with recent updates (although
> many don't both to set "in progress" so this number is probably not
> very meaningful)
> - Only 45 improvement, wish or new feature requests have ever been
> fixed over the lifetime of Trinidad (less than 25% of those filed and
> not rejected) of which only 8 committers were involved
> Another sign of stagnation is that Trinidad has plenty of legacy
> UIXNode code from the early Oracle ADF days, there has been no
> movement to address this and bring Trinidad fully into the JSF
> architecture. Many of the components that are still ADF based are
> major ones like the tree and the navigation tree.
> New features seem to be debated harshly on the dev@ mailing list,
> there is always a strong resistance, sometimes by just a few people
> and silence from much of the rest of the community that results in
> lack of adopting any improvements. No new components have been added
> to Trinidad to my knowledge since the lightweight popup control (for
> which the author is no longer active). Only one new skin has been
> included, and that was donated by Oracle (suede skin). The demo has
> not improved, nor has the documentation or website undergone any major
> improvements.
> I think a large part of the lack of progress, but a high involvement
> for some bugs is the contribution of Oracle in their development of
> the rich client offering. By the way, as many know on this list, but
> some may not, I am an Oracle employee, but I am "wearing my Apache
> hat" for this email, and none of what I say here is representative of
> Oracle's standpoint. To make sure this is an Apache point of view, I
> have only included public information that anyone can learn about the
> rich client.
> Some may be aware that ADF development did not cease after Trinidad
> was donated. From that donation ADF has become the rich client:
> Looking at the javadoc
> (
> you can see that the rich client is based on Trinidad's framework and
> some of the components but none of the renderers. What this means is
> that Oracle is very involved in assisting Trinidad's framework and
> UIXComponents, but not the Core components or the renderers. This is
> truly great to have such a large Java-based company backing an open
> source project, but there are some serious draw backs as well. Since
> the Rich Client just doesn't use Trinidad, it uses Trinidad as a
> foundation, this means that any changes to UIX components or the
> framework will appear in Rich Client as well. For example, the
> RichDocument (
> extends Trinidad's UIXDocument. This means that adding new
> functionality, attributes or changing the API of UIXDocument also
> affects RichDocument. So if say a Trinidad user or committer wishes to
> add an attribute onto UIXDocument that would not be beneficial for
> RichDocument, most likely and with past experience, you will find
> Oracle employees on the Apache list tent to resist the improvement and
> have sometimes vetoed the idea. As a result, any changes that would be
> beneficial to Trinidad, but harmful or even not ideal in some way to
> the Rich Client will be met with strong resistance or at least
> negative feedback.
> Also due to the fact that the rich client does not use all of the
> components and uses none of the Trinidad renderers, there will has
> never been any significant support from Oracle to fix, improve or
> document this code. This is why, I think, that Trinidad's Jira state
> is stale when it comes to new features and why there are no new
> components. For a hypothetical example:
> As a Trinidad committer, I put out an idea for a new attribute or new
> component. This feature may need a change to the trinidad-api in
> something like UIXComponentBase in order to work. Oracle is not
> interested in this feature as there is a good chance that since much
> of their code is written in JavaScript, that this change may be either
> redundant or harmful to the rich design and only apply to Trinidad. As
> such, Oracle Apache members disagree the improvement as they do not
> wish to have this functionality exposed on Rich* classes.
> Another problem is that if functionality is added to Trinidad at the
> core foundation or at the UIX* class level that needs support by the
> renderer, then it is also pushed back against. So if I were to change
> UIXColumn and add a new attribute that the
> org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.ColumnRenderer
> would take advantage of, Oracle would have to either (1) implement
> that same functionality in its column renderer or (2) try to hide the
> attribute from the developers on RichColumn. What becomes more easy is
> that the feature is prevented by negative feedback on the mailing list
> or even vetoed so that it doesn't have to be ported.
> Now since the rich client is heavily JavaScript based, it is very
> dangerous to that product for Trinidad to change its PPR functionality
> significantly. Therefore, large performance improvements, more
> declarative AJAX support, XHR usage changes all are very detrimental
> to the rich client.
> The result of all this is that Trinidad becomes bound by the rich
> client, although I do not feel that any of this was on purpose to be
> this way. If the functionality is not deemed valuable to rich client,
> there is often negative feedback on the dev@ list just do to the
> nature of Oracle trying to protect the Rich Client and make it a solid
> component offering.
> If you follow the incubation process at Apache, the rich client was
> approved. There has been no code drop though, and it is unsure when
> this will ever happen (Oracle has not made any public statement on the
> progress of this to my knowledge). The information on Apache is very
> old:
> This one looks newer:
> The donate source code is here:
> Oops 404 :)
> So, as someone that cares about Trinidad, and not just Rich Client
> (yes I like the Rich client a lot, it is truly a great work with a lot
> of code and a great number of terrific features and I decided to work
> for Oracle to help build it), I also want to improve Trinidad and feel
> that the Rich Client is not a replacement to Trinidad, but rather an
> alternative. Here is why I think that Rich Client will not deprecate
> Trinidad if it is open sourced:
> 1) Trinidad supports more browsers (if you need IE6 support, the rich
> client will not be an option)
> 2) Trinidad is much faster due to less overhead for simple pages and
> people that visit one or two pages or your site (for at least the
> javascript footprint alone)
> 3) Rich client is more geared for web-applications rather than web
> pages and Trinidad seems more suitable for web sites in comparisson
> (not that the rich client cannot be used for web pages, but I don't
> see it being adopted for that niche for its mainstream usage)
> 4) Trinidad has a smaller learning curve to extend it (not many
> JavaScript APIs to learn)
> 5) Trinidad is server-side rendered with little javascript, appealing
> to many developers that would rather avoid heavy JS usage or are
> simply looking for a lighter client side component library.
> Basically the goals of rich client and Trinidad are not the same, one
> seeks to be a slick, robust, heavy-weight, JS feature rich platform
> where the other seeks to be a server-side rendered set of JSF
> components that supports AJAX.
> So I have been thinking lately, how can Trinidad get out of the shadow
> of the rich client and improve on its own? I think the major areas to
> address this question are:
> 1) Allowing improvements to Trinidad without them being brought into
> the rich client without intent (like a choice to merge code)
> 2) Fixing and refactoring old, antiquated and sometimes "broken"
> pieces of the Trinidad API, or just making it more possible from an
> Apache commiters point of view to update Trinidad's API
> 3) Removing all legacy code including for the most part UIX code (UIX
> node renderers for the most part)
> 4) Flexible and extensible. Trinidad is open-source, it is not a
> commercial product, but it often gets treated as such (hands off the
> code attitude, if you want to extend our code, use a different
> product), but I have heard from many users that they would appreciate
> it if Trinidad were more extensible and be more open for extending or
> adapting the code.
> 5) Fine grained building blocks to improve customization to allow
> components to look and behave . Example, the table should not have
> "select all/none" links, that should be a separate component so that
> people can create a table that works the way their company would like
> it to work, not always the way that was good for Oracle companies to
> have one standard look and feel.
> Would be nice things, but not required by any means:
> 1) use of a common AJAX library at MyFaces
> 2) use of a common validation framework at MyFaces
> 3) use of a common filter framework at MyFaces (specifically handling
> file uploads)
> 4) make Trinidad a component set instead of a render kit (Trinidad
> does not need custom renderers for h: core components, so why is it a
> render kit?)
> 5) hooks in the APIs to improve compatibility with other component
> libraries (allow someone to write a bridge library to join two
> normally incompatible libraries, like maybe A4J/RichFaces)
> 6) Better support for the user community to give back (Trinidad hosted
> plug-ins, easier to donate and maintain components in the sandbox,
> user donated skins, etc.)
> I believe that it is important to try to preserve Oracle's support of
> Trinidad at the bug fixing level, but allow Trinidad to live a
> separate life from the rich client so that it can grow. By creating a
> separation of Trinidad and the rich client, Trinidad could live a life
> of its own, becoming more open-source developer friendly and not
> having it be constrained to having only new functionality that is
> written for the rich client.
> A couple of options to address this that have come to my mind, are to
> either create a new branch for Trinidad (like 1.5.x or 2.x) that the
> rich client would not adopt, or spin off Trinidad into a new MyFaces
> project.
> In terms of a new project, the specifics could vary, but no matter how
> it was done, it would live as a library under MyFaces like Tobago and
> Tomahawk and would use pieces of Trinidad code to start with. This
> approach would give us a clean slate to start with and also plenty of
> experience and code to leverage from the existing source. APIs could
> be enhanced and cleaned up, removing any legacy methods or aproaches,
> and the UIXNode architecture would be easily removed.
> Such a port, being a lot of work, could have several advantages
> though. It would allow us to add more fine grained methods, more
> declarative base attributes, more flexible components. Since it has
> been proven that no one has the desire to clean up the old Trinidad
> code, this would be a way to get developers excited. Instead of just
> cleaning up code, it would be re-writing it with much less of a
> learning curve. Besides, new code is always something that inspires
> open source developers as opposed to maintaining someone else's code.
> Since it would be based on Trinidad (taken from, not using), it would
> still meet the same goals and therefore still have a home in MyFaces.
> With a new project, we could try to design it so that it would work
> with other MyFaces projects better (like Tomahawk). Having a new
> project would also allow developers who like Trinidad to be able to
> add new robust features and make new components and make other changes
> without the problem of Oracle trying to stop it from affecting the
> rich client.
> In such a new project we could even enhance the sandbox to not just
> components, but sub-projects. For example, there could be jQuery, YUI,
> Dojo based Trinidad components shipped as separate jars for those that
> want a little more JavaScript integration and want to not re-invent
> the wheel (there are so many JS libraries out there that would work
> fine in a JSF environment that no one has really embraced to help
> users do this).
> In summary, I love both Trinidad and the rich client, but I really
> feel that something needs to be done to help Trinidad out of its
> apparent stagnation. The Trinidad community has too restrictive to new
> features and too slow on Trinidad updates from what I have seen. The
> components with their renderers have not improved in a very long time
> (practically since the donation).
> This is not a vote, this is just a discussion I wanted to spark. To
> help find out what people think, here are some ideas on a quick
> response:
> 1) I like the idea of a new library based on JSF 1.2 and taken from
> Trinidad as a starting point
> 2) I like the idea of a new library, and I think it would be great to
> start it as a JSF2 only set of components
> 3) I like the idea of two separate Trinidad branches, not creating a new library
> 4) I think something should be done, not sure what, but I really don't
> want another component library offered at MyFaces
> 5) I'm indifferent
> 6) I like things the way they are and do not want change with respect
> to Trinidad
> 7) Other: (enter here)
> Thanks for reading this through.
> -Andrew
> PS, my preference is #1 in the list above.

View raw message