I do not think adding another component library to MyFaces will be good as well.
On Mon, Sep 29, 2008 at 12:45 PM, Martin Marinschek < [EMAIL PROTECTED]> wrote: > Hi Andrew, Bruno, > > the mail was pretty long, and raised some interesting points, but I > honestly don't think adding another component library to MyFaces will > help. What we should really do is consolidation - if we can work into > this direction, we will have more success as a group. > > @Oracle-committers hindering progress: I am not sure about this. There > has been some pretty hard discussion, but no vetos against the actual > coding. However, it seemed like this - when the discussion had settled > down, people were so pissed off by the discussion that they did not > want to do actual coding anymore. So maybe we should all try to back > off from too heavyweight discussion up front. > > regards, > > Martin > > On 9/29/08, Bruno Aranda <[EMAIL PROTECTED]> wrote: > > I am very much surprised after reading your mail. I don't have the > > feeling that Trinidad is stagnating, at least we use it more and more > > ourselves. And as I have no idea about the rich client I cannot > > comment on that, but Trinidad development should not depend on such a > > project, on the contrary. As long as there is quorum in the community, > > and people willing to do the job, any change in Trinidad should be > > possible and not bound in any way to the rich client. > > I have the impression that most of the most active developers in > > Trinidad are Oracle employees and maybe that gives the impression that > > Oracle controls the thing. However, I have been trying to understand > > Trinidad internals, because I like the project a lot, but still I > > don't have the know how to do any changes. > > I am, however, open to any change proposed if that is for the better > > (Trinidad's better). Are the issues open stopped because of the rich > > client, or because there are not enough committers working on that? > > > > Trinidad should be enhanced, it is a great library, and using stuff > > common to all the MyFaces subprojects is always a big plus. > > > > And as long as there is people, starting a library for JSF2 can be > > interesting as well. > > > > Good (long!) mail and it is good to bring some discussion on the topic, > > > > Cheers, > > > > Bruno > > > > 2008/9/28 Andrew Robinson <[EMAIL PROTECTED]>: > >> 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: > >> > >> http://www.oracle.com/technology/products/adf/adffaces/index.html > >> > >> Looking at the javadoc > >> ( > http://www.oracle.com/technology/products/adf/adffaces/11/doc/multiproject/adf-richclient-api/apidocs/index.html > ) > >> 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 > >> ( > http://www.oracle.com/technology/products/adf/adffaces/11/doc/multiproject/adf-richclient-api/apidocs/oracle/adf/view/rich/component/rich/RichDocument.html > ) > >> 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: > >> http://wiki.apache.org/myfaces/RCF_Proposal > >> > >> This one looks newer: > >> http://wiki.apache.org/incubator/RCFProposal > >> > >> The donate source code is here: > >> https://svn.apache.org/repos/asf/incubator/rfc > >> 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. > >> > > > > > -- > > http://www.irian.at > > Your JSF powerhouse - > JSF Consulting, Development and > Courses in English and German > > Professional Support for Apache MyFaces > -- Hazem Ahmed Saleh Ahmed Web blog: http://www.jroller.com/page/HazemBlog [Web 2.0] GMaps Integration with JSF + Apache Tomahawk + JBoss a4j: http://code.google.com/p/gmaps4jsf/ Author of (The Definitive Guide to Apache MyFaces and Facelets): http://www.amazon.com/gp/product/images/1590597370/ref=dp_image_text_0?ie=UTF8&n=283155&s=books
