On 4/6/07, Iordanov, Borislav (GIC) <[EMAIL PROTECTED]> wrote:
Now, two quick substantial issues since you insist (and I'd be more than
happy to be proven wrong, I might have misunderstood the spec or myfaces,
for that matter):
1) Component state management: all component state needs to be saved,
even static state that is defined at compile (or jsp translation time). This
is bad architecture. And I hope you are not going to argue that this is
fine, because we have so much computing power now ;)
No. I completely agree. I've brought it up myself.
IDEA: client-side state manager that restores majority of saved state
from initial tree state
http://www.mail-archive.com/[email protected]/msg19316.html
I've even considered creating my own state management (it's
pluggable), but I haven't needed it badly enough, yet. However, it's
on the potential todo list for JSF 2.0.
http://wiki.java.net/bin/view/Projects/Jsf2RequirementsScratchpad
SubCategory: State Saving
- saving page deltas
- mostly "stateless" state saving
- Re-do UIComponent State Saving, with a view towards making stateless
components the default.
2) No clear definition of development roles within the framework.
Being a complex and all encompassing webdev framework, one would expect that
it provides well for labor division between programmers and UI designers.
But what I see from a UI designer perspective is a new set of tags to learn
with not much control over how the output looks, with sometimes
unpredictable behavior and no more expressive power than regular HTML.
Having an extra layer on top of HTML (the JSF tags) is an opportunity to
insulate looks from behavioral logic. JSF didn't cease that opportunity. The
components mix appearance and functional attributes.
I haven't had an issue with this. There's a clear division of labor
where I work, and my html guys haven't had problems working on the
page code while I work on the java code. Specifying css styles seems
to work ok for them. There's probably a few places where the
components need to be improved to have more styles. Some components
are simply replaced by raw html (panelGrids with html tables). In
fact, I generally get the html pages pre-designed, and I drop in the
correct components in the right place before sending them back for
touchups. Again the facelets composite component templating makes it
all pretty easy. If you don't like how a tag works, replace with
with a custom one.
Finally, the whole API is designed around fat classes, not interfaces. This
is a serious and in my opinion unnecessary constraints on code that extends
JSF in one way or another.
I can't speak to this since I've had little need to extend the JSF
code. What few things I've needed to extend (validators, converters)
provided interfaces. The few components I extended extended a base
class, which is what I wanted anyway since I was just changing small
pieces of behavior.
