regarding the current ajax hype... what I don't want to see the JSF.next (aka 2.0) is ajax-based components or even new components like calendar or what ever. Nobody needs them in a standard! let's work on the API.
what should be there? -Jacob already pointed out to look at Tapestry 5, maybe the user/dev community is more pragmatic since they managed their 4.x release early this year... ;) However, I'd like to see -bookmark support -action based support or at least a "soft" integration hook *There should be a "standardized" way for a (real) front-controller for getting access in a GET URL to the MB facility. Sure there are several ways like NonFacesReq_FacesResponseServlet/Filter, PhaseListeners or custom lifecycle, or what a ever. -in DynaFaces / Avatar there is a JavaScript api. That would be funny to see a *jsf-driven* client side api for sending events back to the server. And at least, don't invent a "super" framework like Rails is... That should be more up to WebBeans. Than WebBeans be one (and only one; more are possible) perspective on JSF (and other stuff like EJB), or the developer can use it naked/plain. @Martin: cool thread :) have fun in munich! -M On 9/26/06, Werner Punz <[EMAIL PROTECTED]> wrote:
[EMAIL PROTECTED] schrieb: > It might be worthwhile to check out some of the stuff proposed by HLS for tapestry 5-- I do like the way he/others are handling bindings instead of exposing them to the end developer. The way bindings/attributes are handled in JSF are by far the worst aspect of the API (maybe a close second to statesaving requirements). > > Some of the other ideas he's proposing around queuing commands/events for post processing on submit are pretty interesting, but I'm intrigued as to how the N iteration cases will be handled and if the state size would get just as bad as with JSF, where JSF forces some of these events to backing beans in other scopes, not serialized. I had discussed some similar ideas around pushing a 2 phase component lifecycle (encode/decode) and queueing events for processing with literal references, consolidating to only 2 tree walks. > > Also, avoiding mapping parent/child relationships within the component itself might be something to look at. This would allow us to have components that exist in different lifecycles, much like EJBs, instead of forcing transient relationships upon child branches. This can be solved a couple ways: either through injection like the other APIs, or via the filter pattern, passing in a pointer to the children when you process a given event. > > It'd be cool if Sun started a JSF 2.0 project on Java.net to start publishing ideas in wiki format to get better community input. > > -- Jacob I have to admit i have not looked to deeply into jsf 1.2 but there is one area which is a constant pain to say it mildly the componet api generally, way too much glue code, way too verbose way too much non java glue. all i can say is, for the jsp part, move the taglib code into annotations get rid of xml wherever possible and move most of the component property glue into annotations as well or have a sane autodefault with overrides. on renderer level, add some templating mechanism to the mix so that most stuff can be handled directly on a markup level instead of having to go into the writer api, which is a major pain once the markup becomes more complicated. think about ways to enable easy componentization on pure markup level without any gluecode at all (just like you did in facelets) also a standardized way to have some kind of dialog like statefulness should be thought of...
-- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
