> ...
> 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:
JSF doesn't put any restriction on the way you write components. If you prefer JSP, FreeMarker or whatever, it can be implemented. Before 2.0, you always needed some Java, at least to bootstrap the rendering process, but since 2.0, you can even write components using only markup.
> 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 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. 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. 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).
> 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
...
> 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.
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.
> 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.
I don't see the relation with Groovy. We already support Groovy, and at MyFaces, I hope we soon support Scala too. No need to move rendering to do this. Remember, all supported languages compile to Java bytecode.
> >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.
But you're suggestion sounds to me like changing something well-balanced to something less-balanced.
> 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.
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. 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.
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.
>
> >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.
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...
> 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.
I think this is not a simple task with the current architecture.
> In case I didn't change your mind please send me -1
> again :)
>
> -1: no
> 0: not sure
> +1: yes
Sorry, still -1. It just doesn't look like JSF to me.
PS. About the JSF team having very limited resources. At MyFaces we have something like 50 committers. I don't know the size of the Mojarra team, but I think JSF is the biggest web framework for Java. JQuery, for example, is a one-man-project.
[Message sent by forum member 'jkva']
http://forums.java.net/jive/thread.jspa?messageID=393246