>-bookmark support Have seen more than one project go to Rails and Struts because of bookmarks and the learning curve argument.
Dennis Byrne >-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 >
