[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...
