Hi Jan-Kees,
>JSF doesn't put any restriction on the way you write components. If you prefer JSP, FreeMarker or whatever, it can be implemented.
I doubt that current JSF architecture allow adapting for example FreeMarker as complete replacement for JSP or facelets.
Probably you mean possibility to use additional markup languages strictly for templating purposes.
But I fail to see how is possible to write components with different than facelets markup language.
>but since 2.0, you can even write components using only markup.
I believe you mean only composite kind of components can be written using only markup language.
You will have hard time to implement such components as h:inputText or h:selectOneMenu using only markup language.
There is one very important thing related to using different markup languages.
It could be a little bit confusing in some aspect.
Let me try to explain what I mean.
Markup language can be used strictly as language directly connected to template engine. Good example is XSLT.
Another case when markup language could be used only for describing UI.
The term "view description language"(VDL) describe the second case.
I suppose that JSF oriented on support only one connection between VDL and related rendering process.
But in case of JavaFX we could try to use it as VDL but without hard coded connection to rendering technology.
What I’m trying to say that if JSF will follow approach described in the plan someday it will be possible to use practically the same JSF application to render web application or desktop application :)
This kind of power impossible until we remove rendering functionality from java components. After all the main purpose of the server-side is to serve data handling and logic not align to requirements of UI components.
What we have now is that server is servant of client.
You know better than me how much UI related java code located on server-side.
>You're talking about the programming model (@compile time). I was talking about the runtime characteristics. GWT compiles into JavaScript and has stateless server side services. JSF is a server side framework. That's a very fundamental difference.
You are right. It’s really fundamental difference and in this respect GWT has advantage in my opinion.
Now I understand why you have pointed to GWT.
From another hand it’s one more argument to support the plan :)
>GWT uses a specific kind of remoting mechanism to let the client communicate with the server. JSF uses POST (or GET/"Ajax" since 2.0) for everything. This is very different.
I agree it’s different and it have to be considered even it’s definitely less important difference than previous one.
Anyway you pushed me in direction to create some kind of table where we can present JSF position among other frameworks.
Using the table we will see current position of JSF and future position of JSF according to the plan.
This way there is chance to see more precisely if future version of JSF will hold indeed distinguish position.
Call it marketing positioning for JSF.
>Where state management is implicit in an Ajax application (the state is in the DOM and the DOM is kept alive across requests),
>state management is one of the key features of JSF (and this is necessary, because it's a server side application).
Having UI component state management on server-side in my opinion one of the biggest problem of JSF.
In this regard I suggest to do the same thing that GWT do - keep all UI components on client-side.
To illustrate majority of the problem see the following fragment from Alexander Smirnov’s letter:
"The problem is far worse then you think :-( UIData itself has transient
properties, the most important of them is dataModel. Standalone UIData
caches model between phases, but resets it if you have enclosed
iteration components that gives huge impact on performance if data model
does not cache results itself. In Mojarra, UIRepeat knows about UIData
but latest has no clue about repeater, so if you put data table inside
the <ui:repeat> , results will be unpredictable."
Also it is interesting to see how ICEfaces is fighting the problem:
"ICEfaces renders into a server-side Document Object Model (DOM) with only incremental changes to the DOM being delivered to the browser and reassembled with the light-weight Ajax Bridge . This is a revolutionary technique known as Direct-to-DOM (D2D)."
That what I mention before - the server-side is trying to adapt, align, repeat/replicate/imitate client-side functionality.
I would call it dancing around functionality :)
One more other developer's comment that is not require much explanation in the current context:
IS> I still think about some kind of representation of the component tree on
IS> client in some Javascript API.
>Maybe someone else can correct me here, but JSF is limited to markup that is rendered by the browser, like HTML. I think implementing a RenderKit for JavaFX is very difficult with the current framework, because it impacts almost all other parts of the framework.
>For example, if I understand your proposal correctly, phase 1, 2 and 6 can be removed. And I'm sure there are big implications on the other parts.
Only reason is that currently both facelets and JSP are hard coded to servlet/JSF life cycle.
Of course you could use some kind of work around to use JSF for different purposes than render HTML.
In fact my application already using JSF to render HL7 messages and I know that people use JSF to render PDF and other stuff.
It looks like part of the plan "Possibility to run facelets outside JSF context" has some support inside JSF team.
So hopefully soon the situation will be improved in this regard.
>I think implementing a RenderKit for JavaFX is very difficult with the current framework, because it impacts almost all other parts of the framework.
That exactly is my point. That why it doesn’t make much sense to try to integrate JavaFX without implementing phases 1,2,4 and 5.
>For example, if I understand your proposal correctly, phase 1, 2 and 6 can be removed. And I'm sure there are big implications on the other parts.
These are the most important parts and without them the plan will lose much value.
You effectively killed my argumentation for this part of debate with your Scala support ;)
>But you're suggestion sounds to me like changing something well-balanced to something less-balanced.
It’s hard to discuss this part without a clear criteria’s in place.
>So you're saying: Let's rewrite a very large portion of JSF 2 but keep the old stuff?
>This doesn't sound like a good idea to me.
It’s hard to define precisely on this stage what to keep and what to throw out.
Personally I’m very radical in this respect.
But Ed Burns will do everything in his power to keep the old stuff in order to have backward compatibility in place.
So I don’t really bother to think precisely regarding this matter.
>I also don't think the comparison with the 1.2-2.0 migration is valid, since 2.0 works the same as 1.2 if you used Facelets. You get some extras with 2.0, but your application still works fine without them.
>You can simply start using one feature at a time, for example starting with an event tag, adding some Ajax support and then migrating to bean validation, one page at a time.
To some degree you are right, but I still think it’s possible to have smooth migration even with so radical changes.
>I don't see this simple migration path in your strategy, because some of the fundaments are either removed or changed. As said, his didn't happen in 2.0.
I have some ideas in this regard but I need to work more on it.
One of idea is that simple configuration change could put application in mode using complete Ajax lifecycle instead of traditional JSF lifecycle.
>My main concern regarding those rich clients is that they are more powerful than JavaScript will be.
>They have big advantages with the programming model (in Flex it's really easy to modularize your app into standalone, reusable components) and also have performance benefits, because they have better access to the graphics card, etc...
I'm not that sure. Please take a look on the following articles to see my point:
http://www.sitepen.com/blog/2010/01/19/commonjsjsgi-the-emerging-javascript-application-server-platform/
http://www.sitepen.com/blog/2010/03/10/can-flash-thrive-going-forward/
http://www.sitepen.com/blog/2008/04/03/flash-silverlight-and-the-open-web/
It seems that rise of JavaScript server platform will hit both Flex and SilverLight.
Regarding performance of Flex I'm sure modern JavaScript library that running by modern browser have more advantages in this respect.
>PS. About the JSF team having very limited resources. At MyFaces we have something like 50 committers.
And you are one of them :)
Also I found out that you have a quite active blog.
I'm trying to say that you are in good position to promote the plan.
Only problem is that you still don't like it ;)
Thank you,
Vladimir
[Message sent by forum member 'vladperl']
http://forums.java.net/jive/thread.jspa?messageID=393497