>can't afford to do a complete redesign that will break backwards compatibility all over the place.
JSF 2.0 introduced several radical changes. Good examples of such changes are composition components, partial rendering and supporting parameters with EL.
It was very ease to integrate the new stuff and it provided significant benefits to the whole process of software development.
Yes, sometimes it breaks backward compatibility, but in most cases it takes very little time to work it out.
Of course for component developers it's a bigger issue to deal with breaking backward compatibility.
>but if you start to make fundamental changes to the architecture that are exposed to
>external interfaces then you're usually better off starting (yet another) new framework
>entirely.
I believe that breaking backward compatibility more affordable path than switching to a new framework :)
Do not break backward compatibility too long and market will break it for you :)
Without exception every framework have to be revised radically time from time in case to be in line with a new reality.
Now it's the time to do it because JSF 2 provide solid ground for this move.
>Skimming the GI 4.0 document, I don't really see anything extraordinary about it.
>It seems to be a mishmash of ideas from the main developer mixed in with a discussion
>of some of the requirements and requests that users have made. It goes into plenty of
>detail, that's true, but it reads more like one person's stream of consciousness then a
>definitive strategy document.
I understand your point. You are right it's not definitive strategy document.
But this kind of document is the good start to make such plan.
I never see that JSF team layout in such manner the issues related to the architecture of JSF.
That is the reason why it looks so extraordinary to me :)
Beside it many issues described in the plan relevant in some way to problems that JSF is faced.
Here is the small illustration of my point:
>GI is too coupled to XML, it has no XML-JSON equivalence, it has no source- and
>format-agnostic data API, and its data controls cannot be populated with domain objects
JSF has no support for JSON, there is no language-agnostic data API, DataTable is not very flexible and we can't use Dojo Datagrid directly.
>GI includes synchronous APIs for server communication even though such calls
>always cause performance problems
JSF life cycle defined around synchronous server communication so we have the same problems
>Formal interface is too heavyweight for many cases where you want to declare a simple contract.
JSF is too component oriented and every java based JSF component indeed is very heavyweight considering how many methods and properties it includes.
If you saw DataTable component code you will know what I mean.
>I've only recently come back to JSF, so I don't know, but do you think that the existing
>JSF requirements and design processes are lacking in some way?
Yes, I do think we have some problems in this respect.
JSP as rendering engine was outdated many years ago and only recently they switched it to facelets.
Supporting parameters with EL was included also just a few months ago.
You will no see link from JSF project page to place where you can make suggestions to improve JSF specification.
JSF team never organize real discussion regarding strategy of JSF.
They mostly oriented towards software vendors as opposite to community of JSF users.
Partially I can explain this situation because most of the JSF users never challenge wisdom of the specification.
I know that JSF team have started some activities related to future of JSF as usually in silence mode ;)
So I'm going to present very soon my strategic plan for them to see.
The plan is going to be very radical by nature but I will try to keep constructive tone with it.
Hope you personally will provide your insight on future of JSF.
Of course you can keep silence that is usual practice with JSF users but don't be too
upset if JSF will become irrelevant in some near future :)
[Message sent by forum member 'vladperl' (vladperl_at_hotmail.com)]
http://forums.java.net/jive/thread.jspa?messageID=390706