Hi Matthias and all, Yes I could add it to a wiki, but I think I'll have to revisit what will be required per alpha release as I'm currently implementing latest spec snapshot on the MyFaces base (cannot commit it yet since it's not public though) and there are more change on that version than between 1.2 and the first early draft. So far I added in the codes 2 kinds of TODO:
// TODO: IMPLEMENT API and // TODO: IMPLEMENT IMPL where the first mean that there's missing code in myfaces-api (new non abstract method or modified contract) and the second means that the method should be added on the myfaces-impl side (mainly new methods that throws the really crappy UnsupportedOperationException). I didn't create JIRA tickets for now, but from previous experience I think it should rather be a per classe basis instead of a per todo basis that I first used for 2.0. As for the big lines of 2.0, I see the following high level modules: - Facelets PDL - Resource API - JavaScript API - SystemEvent API - Error handling API (and run through existing classes to make sure the new exception specification is enforced) - Tree visiting API - Partial view API - Annotation support - New tags (mostly linked to Facelets) - New validators (Bean and regex mainly) - Unit tests - Utility methods (ExternalContext mainly) - Config ordering Am I missing anything? Also, assuming this list is correct, would it be acceptable to base the alpha releases on full implementation of some of those modules? I thknk there's more or less 3 teams working at the same time on 2.0, so maybe we could implement 2 modules per release (in case one team is less active during a given release cycle)? Regards, ~ Simon On Thu, Feb 26, 2009 at 1:06 PM, Matthias Wessendorf <[email protected]>wrote: > Simon, > > can you add that content to a wiki ? > > -Matthias > > On Thu, Feb 26, 2009 at 6:03 PM, Simon Lessard > <[email protected]> wrote: > > Hi Micheal, > > > > Help on Facelets would be most welcome, it's quite big and not a code > base I > > know that much. I can see 6 main tasks to that integration, 4 required > and 2 > > nice to have: > > > > Relink the classes to JSF 2.0 FaceletContext and other Facelets API from > > myfaces-api. 100% done. > > Package renaming. Someone suggested to keep the same names before, but > that > > won't work as JSF 2.0 must work if you drop in the latest Facelets JAR > and > > keeping the same names would imply some name clashes. So we have to > figure > > out either where to place each sub module or keep it with the original > > structure but with different root packages. 0% done. > > Set Facelets as the default ViewHandler (as of JSF 2.0 Facelets > superceede > > JSP). 0% done. > > Since I used the latest Facelets code for integration, there's already > some > > difference between the spec and Facelets, namely with FaceletHandler > where > > the API only has the apply method while latest Facelets uses > > applyDefinition. Therefore, we have to revert the Facelets code back to > > apply only and get rid of the applyDefinition code. 30% done. > > Convert Facelets to Java 5+ (generics). 50% done. This is a nice to have, > > but I use this task to get comfortable with the code base at the same > time. > > Get rid of the JSF version code switches. Facelets sometimes switch > between > > "Facelets" EL and "native" EL based on the current JSF version to support > EL > > in JSF 1.1 mainly. However, in MyFaces 2.0, this is irrelevant and a > > performance overhaul so we need to get rid of that and always use > "native" > > EL. 99% done. (I think I've got them all already, but I need to do > another > > run on it to be sure) > > > > Points 2, 3, 4 are the ones I need the most help with. For 4. we started > > fixing it using the JIRA tickets about the various Facelets tags for > patch > > attachment purposes. > > > > > > Regards, > > > > ~ Simon > > > > On Thu, Feb 26, 2009 at 11:46 AM, Michael Concini <[email protected]> > > wrote: > >> > >> Good point about the size of the facelets work. Simon, is there part of > >> the facelets work that we could pick up for you guys? We're looking to > help > >> out where our efforts would be most useful instead of just grabbing > random > >> issues to work on. > >> I agree for the most part about your proposed contents for an alpha > >> release. I would also like to stress the importance of regression > testing > >> with JSF 1.1/1.2 apps as part of any alpha release. > >> -Mike > >> > >> [email protected] wrote: > >>> > >>> I'm currently working on the annotation processing stuff (@ManagedBean, > >>> @ManagedProperty...). Already made a first attempt for the managed > beans, > >>> but there is still some work to do (converters, components, event > listeners, > >>> etc). I hope I can apply the same logic for those other components as > well. > >>> > >>> With Werner working on Ajax and Simon on Facelets, we already cover a > >>> large portion of JSF2. Facelets is big, though, since it also contains > tags > >>> for all components, EZComp, JSF2-Facelets/Original-Facelets switching, > >>> etc... Resource handling/relocation is also a mandatory requirement for > Ajax > >>> to work. > >>> > >>> But I think an alpha release should at least contain these essential > JSF2 > >>> components: AJAX, Facelets, annotation based configuration. I think > those > >>> components are the base of the JSF2 work. Adding in other features > should > >>> not be too hard when those three are in place properly. > >>> > >>> About Shale-test, is it right to use Shale classes in MyFaces Core? Of > >>> course it's just the unit tests, but in some way it's still a cyclic > >>> dependency which is usually a bad thing... > >>> > >>> /Jan-Kees > >> > > > > > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf >
