jkva,
First of all I'm very thankful for your response.
Let's strictly logically take a look at your argumentation.
>Why modify JSF if you really want to standardize GWT?
Honestly I don't know much about GWT that why I went to their site and took a look.
Here is the first example I found there:
"final Button sendButton = new Button("Send");"
To me personally this example just show how far GWT is behind of JSF.
If I'm fighting here to remove rendering code completely from java components then what I can say about approach where content of UI described in Java code. It's just disaster to use in such manner java for web applications. As proof of my point read the following:
"What's New in GWT 2.0?
With UiBinder, GWT now allows you to create user interfaces declaratively in XML instead of having to assemble them programmatically. The XML file supports the following features to make your UI code smaller, more readable, easier to maintain, and faster to develop:
* Specify CSS styles locally, without having to worry about duplicate CSS names.
* Intermix GWT widgets with native HTML for faster, more efficient apps.
* Conveniently support bundled resources and internationalization."
Looks like they just moved to the stage JSF 1.2 :)
I would say why modify GWT if you really want to standardize JSF?
>You're suggesting to change some of the most fundamental aspects of the framework:
>In your story, I see major changes to the component tree, state management,
>probably EL, remoting must be added, probably another view markup language (if any,
>Java might be better, like GWT), different event handling, an entire new standard
>component library and more.
That's mostly is correct interpretation of my suggestions except for part related to markup language. Java language is not markup language by nature and frameworks who are trying to use Java as language describing user interface eventually will fail if they don't change the approach. Take for example Delphi they never used Pascal as language describing user interface. For this purpose they used specific markup.
Here is example:
object RequireMonitoringYes: TQRShape
Left = 709
Top = 512
Width = 12
Height = 12
Frame.Color = clBlack
Frame.DrawTop = False
Frame.DrawBottom = False
Frame.DrawLeft = False
Frame.DrawRight = False
Size.Values = (
31.750000000000000000
1875.895833333333000000
1354.666666666667000000
31.750000000000000000)
Pen.Width = 2
Shape = qrsRectangle
VertAdjust = 0
end
Regarding using different markup languages I suggest it because if all main architecture recommendations will be accepted it will be pretty easy to adapt additional markup languages. You could adapt any kind of markup languages. Good examples are bindows, JavaFX. With moving rendering functionality to client side no big problem to create migration path from Desktop applications such as javafx/swing to powerful JSF based applications. There is a real chance for JSF framework to become technologically superior framework. Only JSF has a chance to close the circle between desktop applications and web applications. More of that! There is a chance that JSF could become language agnostic. JSF already has support for Groovy. Kill rendering functionality on the server side and you will see how much power JSF will get.
>When changing so much, why bother rewriting JSF while there's another framework >that simply fits your suggestion better?
Two main reasons
1) There is no framework that has server and client side correctly balanced and implemented on high level.
2) Migration to another framework will take too much resources. Beside there is no guaranty that in future a new framework will be right choice.
>No offensive intended, but if your scenario becomes reality, I think everyone's better off with a brand new framework, instead of a retrofitted JSF.
For developers who already used JSF for years is the best choice - adapt JSF to new requirements.
I have migrate from JSF 1.2 to JSF 2.0 without much efforts even there was some significant changes. Also keep in mind that regular JSF developer will be able to continue working in the same manner that was before. After all nobody here is suggesting to deprecate facelets syntax or managed beans.
>And personally, I prefer Flex/JavaFX/Silverlight over a 100% JavaScript solution (like GWT or your plan).
If you are not component developer you don't have to use Javascript at all.
Even in situation when all UI components moved to client side you should able to work with Java. So I don't see much trouble to JSF developer.
Anyway they used to design UI with help of HTML template.
After all you could use Flex/JavaFX/Silverlight as VDL languages with JSF if the plan will be accepted.
In case I didn't change your mind please send me -1 again :)
-1: no
0: not sure
+1: yes
[Message sent by forum member 'vladperl']
http://forums.java.net/jive/thread.jspa?messageID=393195