Craig,
Some other thoughts:
* At TSSJS, I talked with folks on the Spring and Beehive projects. Both of them have abstractions to do what DialogController is focused on, and I want to experiment with both of them for this responsibility, to see if we can avoid having to reinvent that particular wheel.
Interessting! Are the Beehive guys are working on a "wizzard" or something similar to that, inside their *Page Flows* "subproject" ?
* Also, for the back end of XmlHttpRequest-sending components, we need to support APIs and message formats in addition to raw XML. Need to look at JSON and othe Ajax-ish things to see what we can harvest.
yeah, AJAX came up on this list some days before: http://tinyurl.com/4j8sx
Also, I noticed that Matt Raible blogged about JSON;
* Implementations of support for file upload, client side validation support, and Tiles support have been promised.
-a basic Tiles support is done for now, but it depends on MyFaces' core -file upload is ready in MyFaces' custom components and should work with RI. -David Geary blogged about the client side validation he and Cary did during writing "Core JSF". He also pointed out to contribute it to Shale.
Regarding cooperation, that makes perfect sense ... among other things, I periodically make sure that Shale works with snapshots of MyFaces. One interesting question would be how to deal with components that want to be Shale-specific in order to use the remoting support. Maybe a sandbox subproject here at MyFaces, now that it's a TLP?
Fine! Working together should be the best JSF user could get, independent from which Impl of JSF Spec they might use.
It is very important, that Shale works with MyFaces (it does, I am "playing" with both during learning Shale ;))
Also MyFaces' extra components should work with Shale; haven't looked at the remote thing in Shale. "Only" looked in "ViewController" and I am fascinated about that! But session scoped "DialogController" seams also to be very usefull.
As you also pointed out, that we are discussing the subproject issue, does it make sense for you, to host Shale at MyFaces?
Shale should be build on top of JSF API, like our components.
Since Shale is a framework that tries to leverages JSF,
I see some "overlap" in MyFaces' custom components and Shale (and its components). Also both "teams" will have some util classes, that do the
same stuff for providing helper methods, independent from a specific
implementation.
see: http://tinyurl.com/4zhd7
or the mentioned "client side validation" or "file upload component" for instance.
-Matthias
sean
Craig
PS: On the general topic of subprojects, I endorse what was suggested earlier about splitting the JSF implementation and component library, with separate milestones and deliverables. There's going to be lots of attention on both, and you won't want the delivery schedule for one of these negatively impacting the other, or have to worry about synchronizing them.
If you go this way, the MyFaces PMC is still responsible for all releases for all subprojects. If you do things the way we did at Struts (which I would suggest), you'll also want to have universal committer access across subprojects to avoid potential barriers to increasing the communities around each subproject.
-- Matthias We�endorf Aechterhoek 18 DE-48282 Emsdetten Germany phone: +49-2572-9170275 cell phone: +49-179-1118979 email: matzew AT apache DOT org url: http://www.wessendorf.net callto://mwessendorf (Skype) icq: 47016183
