>>>>> On Sat, 06 Mar 2010 20:31:38 -0800 (PST), webtier_at_javadesktop.org said:
VP> I believe it's time to design the future strategy for JSF. The
VP> corresponding plan have to be written in honest and clear manner to
VP> provide a real benefit. Suddenly I have found the perfect example
VP> of this kind of plan. The plan is written by person with weird name
VP> "JESSE COSTELLO-GOOD". I suppose that he could take a new name for
VP> himself such as "JESSE COSTELLO-GOOD-STRATEGIC-PLAN" :)
Yes, this seems like a decent plan. Believe it or not, we did
exactly this kind of thing when we started development of JSF 2.0 in
earnest, but we did it on a wiki [1] and solicited community input.
Furthermore, we continued to fold in communyity input as we went. [2]
VP> Please read the following plan:
VP>
http://www.generalinterface.org/docs/display/OS/GI+4.0+Planning
VP> The plan is interesting because it show the way of thinking when
VP> many strategic moves have to be activated. He is ready to redesign
VP> completely many parts of existing architecture in case to succeed.
VP> It looks like the JSF expert team should take the same approach.
So, in essence, you are really saying that it looks like the JSF expert
team should take the same approach they did with JSF 2.0.
>>>>> On Sun, 07 Mar 2010 16:10:18 -0800 (PST), webtier_at_javadesktop.org said:
T> I've only recently come back to JSF, so I don't know, but do you
T> think that the existing JSF requirements and design processes are
T> lacking in some way?
Thank you for pointing out this perspective.
>>>>> On Mon, 08 Mar 2010 10:29:20 -0800 (PST), webtier_at_javadesktop.org said:
T> can't afford to do a complete redesign that will break backwards
T> compatibility all over the place.
VP> JSF 2.0 introduced several radical changes. Good examples of such
VP> changes are composition components, partial rendering and supporting
VP> parameters with EL.
We worked very hard to introduce those changes in a way that users could
easily adopt them without breaking backwards compatibility.
T> but if you start to make fundamental changes to the architecture that
T> are exposed to external interfaces then you're usually better off
T> starting (yet another) new framework entirely.
VP> I believe that breaking backward compatibility more affordable path
VP> than switching to a new framework :)
Vlad, I appreciate and respect your enthusiasm. I think what you're
looking for is a community roadmap for JSF. I've started the page, I
want *you*, Vlad, to throw some ideas up there
<
http://wiki.java.net/bin/view/Projects/JsfCommunityRoadMap>.
T> Skimming the GI 4.0 document, I don't really see anything
T> extraordinary about it. It seems to be a mishmash of ideas from the
T> main developer mixed in with a discussion of some of the requirements
T> and requests that users have made.
VP> I understand your point. You are right it's not definitive strategy
VP> document. But this kind of document is the good start to make such
VP> plan. I never see that JSF team layout in such manner the issues
VP> related to the architecture of JSF. That is the reason why it looks
VP> so extraordinary to me :)
Just because you haven't seen it, doesn't mean it does not exist.
VP> Here is the small illustration of my point:
T> GI is too coupled to XML, it has no XML-JSON equivalence, it has no
T> source- and format-agnostic data API, and its data controls cannot be
T> populated with domain objects
VP> JSF has no support for JSON, there is no language-agnostic data API,
VP> DataTable is not very flexible and we can't use Dojo Datagrid
VP> directly.
Why should *JSF* have support for JSON? Clearly JSF isn't the only part
of Java that would benefit from JSON (as shown by the existence of
several Java JSON solutions). Doesn't that seem like something the core
Java platform should have? Your suggestion lets me illustrate one
aspect of specification development that is not obvious: placing things
in their proper context. Sure, it's easy to say: "JSF should have this,
and JSF should have that" but JSF is a part of the JavaEE platform. We
can't just grab features left and right, as non-platform frameworks *can
and should* do.
T> GI includes synchronous APIs for server communication even though
T> such calls >> always cause performance problems
VP> JSF life cycle defined around synchronous server communication so we
VP> have the same problems
Yes, leveraging HTML5 WebSocket is important.
T> Formal interface is too heavyweight for many cases where you want to
T> declare a simple contract.
VP> JSF is too component oriented and every java based JSF component
VP> indeed is very heavyweight considering how many methods and
VP> properties it includes. If you saw DataTable component code you
VP> will know what I mean.
I love this. Some say JSF is not component oriented enough. Now you're
saying it's *too* component oriented.
T> I've only recently come back to JSF, so I don't know, but do you
T> think that the existing JSF requirements and design processes are
T> lacking in some way?
VP> Yes, I do think we have some problems in this respect. JSP as
VP> rendering engine was outdated many years ago and only recently they
VP> switched it to facelets.
Only recently? Users could switch to facelets as soon as facelets
existed, which was in 2005. You are confusing the date of specification
with the date of availability. As long as I'm spec lead, the date of
availability will always predate the date of specification.
VP> Supporting parameters with EL was included
VP> also just a few months ago.
Doch, JBoss EL (written by Jacob Hookom at the request of Gavin King)
has had this feature since Seam came out.
VP> You will no see link from JSF project
VP> page to place where you can make suggestions to improve JSF
VP> specification.
I've been soliciting such comments via my blog entries, occasionally
pointing to wikis for more detailed discussion, for years.
VP> JSF team never organize real discussion regarding
VP> strategy of JSF.
Become an observer on JSR-314-OPEN. You'll see the
discussions.
<
http://weblogs.java.net/blog/edburns/archive/2009/03/response_to_a_c.html>
This is from MARCH 2009! How can you say NEVER?
VP> The plan is going to be very radical by nature but I will try to
VP> keep constructive tone with it. Hope you personally will provide
VP> your insight on future of JSF.
As I said, I welcome and encourage your participation. Put it up on the
wiki page I started.
[1]
http://wiki.java.net/bin/view/Projects/Jsf2Requirements
[2]
http://wiki.java.net/bin/view/Projects/Jsf2RequirementsScratchpad
--
| edward.burns_at_oracle.com | office: 408 884 9519 OR x31640
| homepage: | http://ridingthecrest.com/