Adam, I looked through some of my archived emails on this subject. A common theme amongst the MyFaces developers (in addition to myself) was that the ADF code should be refactored to use the MyFaces "commons" code when possible. At one point in time the ADF team seemed to agree with this but reminded us that their may be cases where the ADF way was superior to the MyFaces way and the refactoring would be done to the existing MyFaces code in those cases. (IMO a perfectly reasonable point.)
At one point the ADF developers began to review the MyFaces code and reported back that such a merger was going to be more difficult then Oracle had originally thought. Over time Oracle's position seemed to have drifted away from these assuarances that the code would be refactored (I found a private PMC email thread discussing this changing position.) I think there is a pretty strong interest in taking a look at the ADF code at this point. The only person to look at it from the MyFaces PMC was myself and that was (as you described) the reverse engineering of one of your more complicated components. If Oracle's position is that they are not interested in significant changes to their code to fit nicely with the rest of MyFaces, then my personal position is that I am not in favor of ADF becoming part of the MyFaces project. I think its a major mistake to have 60% of tomahawk components use one approach to solve a problem and 40% use a completely different approach. This will become a maintenance disaster. I'm also not wild about duplicate components. So I think some consolidation is in order. Instead of two data tables, take the best of both and have a single data table. More is *not* better. Not when it comes to maintaining code and documentation. I am still not wild about tree and tree2. We certainly don't need dataTable and dataTable2, etc. There are two important challenges here. 1.) Oracle needs to be ready, willing and able to do significant refactoring of their code (beyond renaming the packages.) 2.) MyFaces committers (or potential committers) need to be ready to step up and assist in the massive integration effort. Significant changes to the existing code will have to be made to accomodate the new components and to take advantage of areas where the ADF approach is superior. So far Oracle seems to be backing away from #1 and we have one volunteer for #2. I don't even think its worth moving the code to the incubator if we can't get more support in these two areas. Please don't get the impression that I'm against ADF becoming part of MyFaces. Tthe idea is a great one in theory. Oracle has some cool components and a lot of JSF know how. Oracle has been at the forefront pushing JSF and MyFaces can only get better with people like yourself involved in the project. A lot of this has already been said on a private email chain with Oracle way back when. I think these issues need to be revisted again - this time in public. Not only am I concerned but the incubator and project committees are getting jumpy. What does the ADF team envision happening here? Regards, Sean On 12/29/05, Adam Winer <[EMAIL PROTECTED]> wrote: > On 12/29/05, Sean Schofield <[EMAIL PROTECTED]> wrote: > > > I seem to recall hearing that ADF uses a custom viewhandler, much like > > > tobago. That's going to make it difficult to trivially merge > > > Tomahawk and ADF . > > > > You are absolutely correct. This is a serious concern that has yet to > > be addressed. Oracle has said they would refactor to use the MyFaces > > codebase but I have seen no evidence that this has (or will) take > > place. > > Sean, I don't remember anyone making such a promise. > > What I know was said (when you started diving in to the > implementation of the table component, I'm guessing after > decompiling some of our source) was that we had a large base > of rendering code built as an adapter layer around an old framework > (UIX), and that this was going to be rewritten to go directly to > JSF APIs. A large amount of that has happened, incl. the table. > > (BTW, w/o having looked at the Tobago code - our custom > ViewHandler is an adapter only; we're still using ordinary JSPs > - and Facelets - for our rendering. I don't see that specifically > as being of great concern.) > > -- Adam >
