Adam Winer writes in his blog, "JSF is not perfect, nor the greatest thing since sliced bread." But why this Java Champion and member of the JCP expert group come down so hard on a framework that he has been a strong advocate for?

What bugs me most (and remember, I'm still a big fan) is that JSF was supposed to be really easy-to-use. But the reality isn't quite so sweet.

In his estimation the real problem lies in the large stack traces that any error in the JSF seems to produce. According to Adam, these stack traces are simply not enough to fetter out the real problem. To do that you need information to connect the error with the source code that produced it and that information has to be more meaningful and concise.

The most annoying problem is that errors simply result in big stack traces. There's nothing wrong with stack traces per se, but by themselves they're totally insufficient for error diagnosis. Real diagnosis requires at a minimum. In addition there is the possibility of silent failures. Errors in configuration or validation halt execution and all you see is nothing. This doesn't even give you a clue as to where to start looking. If and when you do happen to find the problem you’ll most likely need to bounce the webserver to pick up the changes.


That is what Adam has on his hit list of usablity problems and now he is looking to expand it by adding yours. Drop him a note on his blog and let him know what is on your list.

So, rather than encouraging yet another debate on JSF (how many more do we need?) TSS is encouraging readers to add to a list of problems with JSF. Whatever the merits or otherwise of the framework, this seems to be extremely poor editorial judgement in my view.

Hrm, I'm not sure of your concern here: I'm a central JSF EG member, talk to the Sun RI folks all the time, and I'm also helping out on MyFaces, esp. with the ADF Faces donation. On my blog I'm specifically asking for the usability issues - not generic "problems" - that have most vexed users of JSF so I can follow up on them and get them dead and buried. Are you concerned with having this posted on TSS, or with the notion of my directly soliciting user feedback?

Hrm, I'm not sure of your concern here: I'm a central JSF EG member, talk to the Sun RI folks all the time, and I'm also helping out on MyFaces, esp. with the ADF Faces donation. On my blog I'm specifically asking for the usability issues - not generic "problems" - that have most vexed users of JSF so I can follow up on them and get them dead and buried. Are you concerned with having this posted on TSS, or with the notion of my directly soliciting user feedback?

The nature and content of recent debates on this technology would seem to me to imply that you are going to get more than the limited range of responses you are after. If not in your blog, then here. The entry here - taken out of context - may seem reasonable, but the context is that of recent threads such as 'Tim Shadel says JSF isn't their choice for the future', 'Malcolm Davis on why he's uninstalling NetBeans', 'Bob Lee: I Don't Get Spring' and 'Java: Dead Like COBOL, Not Like Elvis?'. Soliciting negative feedback on JSF in this context would seem to add to a general theme (here) of denigrating key Java technologies. I have no doubt that this was not your intention; just that things could have been worded better on TSS. Just look at how TSS editors put things:

"But why this Java Champion and member of the JCP expert group come down so hard on a framework that he has been a strong advocate for?"

Is this a fair representation of your opinion?

Just look at how TSS editors put things:"But why this Java Champion and member of the JCP expert group come down so hard on a framework that he has been a strong advocate for?"Is this a fair representation of your opinion?

Gotta sell hits-- but look at it this way, at least we're being critical of our own work, unlike other framework devs who, like their own child, think they are simply perfect. Let's get real people. I have a laundry list of gruffs with other MVC frameworks out there (including RoR), but it's much more constructive from our standpoint to openly focus/criticize our own framework in order to make it better (not that it always happens that way). Geert just posted a thing on Rife and how he wants to change all of his templating markup-- other framework leaders should be doing the same.

Hrm, I'm not sure of your concern here: I'm a central JSF EG member, talk to the Sun RI folks all the time, and I'm also helping out on MyFaces, esp. with the ADF Faces donation. On my blog I'm specifically asking for the usability issues - not generic "problems" - that have most vexed users of JSF so I can follow up on them and get them dead and buried. Are you concerned with having this posted on TSS, or with the notion of my directly soliciting user feedback?

The nature and content of recent debates on this technology would seem to me to imply that you are going to get more than the limited range of responses you are after. If not in your blog, then here. The entry here - taken out of context - may seem reasonable, but the context is that of recent threads such as 'Tim Shadel says JSF isn't their choice for the future', 'Malcolm Davis on why he's uninstalling NetBeans', 'Bob Lee: I Don't Get Spring' and 'Java: Dead Like COBOL, Not Like Elvis?'. Soliciting negative feedback on JSF in this context would seem to add to a general theme (here) of denigrating key Java technologies. I have no doubt that this was not your intention; just that things could have been worded better on TSS. Just look at how TSS editors put things:"But why this Java Champion and member of the JCP expert group come down so hard on a framework that he has been a strong advocate for?"Is this a fair representation of your opinion?

Totally agree with you Steve. I red Adam blog this morning and taught this article was not really given a good sumary of it. TSS seems to play the sensationalism card once again.
Is it me or the articles quality has been going down lately? I feel like I am watching FOX sometimes...

"But why this Java Champion and member of the JCP expert group come down so hard on a framework that he has been a strong advocate for?"Is this a fair representation of your opinion?

No, not really: I'm not coming down hard on the framework, mostly just stating realistically that there are problems that should get fixed (duh!). One of the big selling points of JSF was usability, and usability has a way of slipping any time you don't stay focused on it.

I cannot beleive that JSF Usability is in doubt focusing only on stack traces. You cannot say that the framework is under attack ... and then read "big stack traces"

Use best practices, set standards and conventions, order your development team ... and stack traces will become obvious

Will JSF adop simplicity like WebWork.

I love this link, will JSF can win agains Struts team esp the Struts Nexus

-- this statement from Struts team --

When JavaServer Faces arrived, our development community chose to "make new friends but keep the old". Some of us want to stick with a request-based framework. Others are ready to switch to a component-based framework that builds on JavaServer Faces. We offer both frameworks because we have volunteers to create and maintain both frameworks.

-- and this is the kick start --

http://struts.apache.org/kickstart.html

Another JSF problem (IMHO): the rendering order.
A jsf component mixed with HTML tags don't respect the sequence order of components in the rendered code.

Another JSF problem (IMHO): the rendering order.A jsf component mixed with HTML tags don't respect the sequence order of components in the rendered code.

This is fixed in JSF 1.2 and JSP 2.1 (tomcat will have JSP 2.1 support shortly)

Microsoft MCITP training and certification program is one of the elite certifications recognized globally. Every year many IT aspirants and professionals seek this certification

... not enough to fetter out the real problem ...

Perhaps you meant "ferret" (search and discover through persistent investigation as in "She ferreted out the truth" [syn: ferret out]) and not "fetter" (to put fetters upon; to shackle or confine the feet of with a chain; to bind.)?

I've had some very concrete problems with JSF which I described in my blog.

I have also tried to generalize a bit. This could certainly be used by JSF architects to improve this technology unless they intend to dismiss every criticism as a "blind bash against JSF by somebody who cannot understand component-oriented" ;-)

According to Adam, these stack traces are simply not enough to fetter out the real problem. To do that you need information to connect the error with the source code that produced it and that information has to be more meaningful and concise.

I think this is not only a JSF problem but a JSP Problem in general. If you have a simple EL error somtimes you only get a blank page, in a long page it takes you an hour until you find the error, you have to comment out line by line to find it.
That's really embarrassing that this doesn't work properly.
It works in fine Tapestry, Facelets etc. Even my first computer (Commodore 64) printed out the line number where the error occured.
This has to be fixed.

Hi folks,

I agree with Jacob : open and constructive critics are what technology needs to mature. You'll probably go through storms all way long, but I guess that's the price to pay when you try do do things in a new way...

For my part, I really think that it's just the way it's explained (and thereby generally used) that sucks. As far as I understand JSF, I see it as something completely decoupled from HTML... and the regular way we develop webapps in general (JSPs, taglibs, HTML, request/response, etc.).
That's not how it looks like when reading, e.g., the J2EE tuto !

Actually I think most of the users are in trouble because they actually tried to mix components and "old-school web developement, and the nightmare began (JSPs, taglibs, HTML... everything you thought you'd forget with JSF !).
At least it's what I've done when trying JSF the first time : I was still thinking request-based in a component framework, because it's still using JSPs, you still design pages etc. I didn't *feel* in a very different world (I was, but I didn't realize) !

I see JSF more like Swing than Struts/WebWork/...
I think we have to forget a lot of bad habits we have in webapps if we want to move to the component level (and it's a hard move : Swing apps are far more complex in general than webapps and require good programming skills !).

Why not presenting it as is ? I mean, maybe you should show how you can develop JSF apps in pure Java, with no HTML, taglibs, facelets or other stuff that's "in the middle"...

JSF is supposed to be the next step isn't it ?

Then show us it's *really* different from the old stuff we use everyday.
Show us we can do without putting our hands in the request/response/HTML/taglibs... crappy stuff that usually comes along with webapps.

*That* would be usable. And *that* would make developers really consider switching : why should I learn JSF if I still have to work with JSPs, HTML and all what makes web developement a pain ? I have much more simple things here that I already know it works...

Looking at frameworks like ZK or Echo is actually far more exciting than reading the JSF tuto. I'm sure JSF is far more powerful than these, but it's just painful to use compared to them, because it hasn't really divorced from the old crap at the moment.

We're a lot, out there, waiting for a real component-based approach that leverages webapp development to a level of abstraction where you don't think request/response any more.

Maybe if you show us your spec allows this easily, we'll follow :-)

Have fun,

Remi

Hi folks,I agree with Jacob : open and constructive critics are what technology needs to mature. You'll probably go through storms all way long, but I guess that's the price to pay when you try do do things in a new way... For my part, I really think that it's just the way it's explained (and thereby generally used) that sucks. As far as I understand JSF, I see it as something completely decoupled from HTML... and the regular way we develop webapps in general (JSPs, taglibs, HTML, request/response, etc.).That's not how it looks like when reading, e.g., the J2EE tuto !Actually I think most of the users are in trouble because they actually tried to mix components and "old-school web developement, and the nightmare began (JSPs, taglibs, HTML... everything you thought you'd forget with JSF !). At least it's what I've done when trying JSF the first time : I was still thinking request-based in a component framework, because it's still using JSPs, you still design pages etc. I didn't *feel* in a very different world (I was, but I didn't realize) !I see JSF more like Swing than Struts/WebWork/... I think we have to forget a lot of bad habits we have in webapps if we want to move to the component level (and it's a hard move : Swing apps are far more complex in general than webapps and require good programming skills !).Why not presenting it as is ? I mean, maybe you should show how you can develop JSF apps in pure Java, with no HTML, taglibs, facelets or other stuff that's "in the middle"... JSF is supposed to be the next step isn't it ? Then show us it's *really* different from the old stuff we use everyday. Show us we can do without putting our hands in the request/response/HTML/taglibs... crappy stuff that usually comes along with webapps.*That* would be usable. And *that* would make developers really consider switching : why should I learn JSF if I still have to work with JSPs, HTML and all what makes web developement a pain ? I have much more simple things here that I already know it works...Looking at frameworks like ZK or Echo is actually far more exciting than reading the JSF tuto. I'm sure JSF is far more powerful than these, but it's just painful to use compared to them, because it hasn't really divorced from the old crap at the moment.We're a lot, out there, waiting for a real component-based approach that leverages webapp development to a level of abstraction where you don't think request/response any more. Maybe if you show us your spec allows this easily, we'll follow :-)Have fun,Remi

You should really give a look at Apache Tobago. This is exactly what they are trying to achieve using JSF and although I haven't tried it myself, I have heard great things about it.

My main concern with JSF is that it writting Renderer in Java. Hopefully, I heard one the MyFaces developper is working on a velocity Renderer. In my opinion, that's the true missing piece to JSF because right now it takes too much time to integrate third parties components if you use a css/html approach. But to be fair, it is a main issue for all the component frameworks.

You should really give a look at Apache Tobago. This is exactly what they are trying to achieve using JSF and although I haven't tried it myself, I have heard great things about it.

Out of curiosity, I went to their website, and checked the online demo... Well, that's not what I had in mind... far from it !

Look at some source code : it's completely opposite to what I'd expect !

My point is I want to be developing webapps Swing-like.
Coding-in-XML seems a very bad starting point to me ! Also, I can '''see''' the word "JSP" somewhere... :-)

So once again, it's really not gonna help in adoption of JSF IMHO. Even worse : it's yet another complicated stuff that comes on top of an already complex beast :-/

The thing here is you loose "average" programmers (yep, almost everybody can learn to create a dynamic webapp on regular MVC2 frameworks in a few days, but they're far from being able to understand JSF's internals !) that will go back to PHP screamin' their moms that "Java == overengineering", and the ones used to OO and rich-client development will find JSF overcomplicated for the result, in comparison with their usual environment...

My main concern with JSF is that it writting Renderer in Java [...]

I don't know what's your everyday work, but I think the main concern for '''application developers''' (not component/framework providers) is the fact that '''you have to know that a Renderer exist and what it does''' !

Once again, I don't dismiss JSF : I think that like many other specs it's been designed by responsible and smart people who have anticipated many things.

BTW this may be the problem : we (application developers) are not all that smart, so please try to explain your stuf with the ''application developer'' role in mind !

Before I tried it, I though JSF was about draggin' and dropping component, and coding events, a bit like I do with NetBean's Matisse Designer.
It reveals very complicated, with lots of problems out of the box that are supposed to be solved by other complex layers on top of it !!

That's why I agree with the article : the original goal has not yet been reached.

It's a pity that something that could increase our productivity is perceived as too complex, and thereby not widely used in favor of simpler (but at the end more expensive) approaches.

My $0.02

Have fun,

Remi

You should really give a look at Apache Tobago. This is exactly what they are trying to achieve using JSF and although I haven't tried it myself, I have heard great things about it.

Out of curiosity, I went to their website, and checked the online demo... Well, that's not what I had in mind... far from it !Look at some source code : it's completely opposite to what I'd expect ! My point is I want to be developing webapps Swing-like. Coding-in-XML seems a very bad starting point to me ! Also, I can '''see''' the word "JSP" somewhere... :-)So once again, it's really not gonna help in adoption of JSF IMHO. Even worse : it's yet another complicated stuff that comes on top of an already complex beast :-/The thing here is you loose "average" programmers (yep, almost everybody can learn to create a dynamic webapp on regular MVC2 frameworks in a few days, but they're far from being able to understand JSF's internals !) that will go back to PHP screamin' their moms that "Java == overengineering", and the ones used to OO and rich-client development will find JSF overcomplicated for the result, in comparison with their usual environment...

My main concern with JSF is that it writting Renderer in Java [...]

I don't know what's your everyday work, but I think the main concern for '''application developers''' (not component/framework providers) is the fact that '''you have to know that a Renderer exist and what it does''' !Once again, I don't dismiss JSF : I think that like many other specs it's been designed by responsible and smart people who have anticipated many things.BTW this may be the problem : we (application developers) are not all that smart, so please try to explain your stuf with the ''application developer'' role in mind !Before I tried it, I though JSF was about draggin' and dropping component, and coding events, a bit like I do with NetBean's Matisse Designer.It reveals very complicated, with lots of problems out of the box that are supposed to be solved by other complex layers on top of it !!That's why I agree with the article : the original goal has not yet been reached.It's a pity that something that could increase our productivity is perceived as too complex, and thereby not widely used in favor of simpler (but at the end more expensive) approaches.My $0.02Have fun,Remi

Well, it depends of your organization goals. I work for the government right now. We have to conform to strict xhtml and to support a high accessibility level so indeed I do care about the generated HTML. Therefore I have to know about Renderers because I have to validate the outputted HTML. But at least using JSF or any components-oriented frameworks, I just have to do it once.

It's not all the organization who don't care about the generated markup. You can't compare Swing to JSF in that matter. Ultimately Swing output directly on your screen while JSF generates content to a lot of different clients.

Well, it depends of your organization goals. I work for the government right now. We have to conform to strict xhtml and to support a high accessibility level so indeed I do care about the generated HTML. Therefore I have to know about Renderers because I have to validate the outputted HTML.

Then, why components ?
I mean, if you still have to put your hands in HTML, what added value does JSF bring you compared to MVC2 frameworks (or others like Tapestry which makes components easier than JSF) ?

 But at least using JSF or any components-oriented frameworks, I just have to do it once.It's not all the organization who don't care about the generated markup. You can't compare Swing to JSF in that matter. Ultimately Swing output directly on your screen while JSF generates content to a lot of different clients.

Yep, but since the portability layer is at the VM level, I don't care :-)
That's one of the primary strenghts of Swing : write once, run everywhere !

Also, "generating content to a lot of different clients" is a bit of an utopy IMHO. All "clients" (or should we say "environments") don't allow the same things, they were not designed to do the same things !
I would bet that an UI designed for a web client would have to be at least partially rewritten for a mobile device... just like you would not be easily able to use VR applications in the browser because you have JSF...
Last but not least, has anyone here ever used such "UI meta-model" concept in practise in real-life apps ?
I think there's not that much...

Actually, I think Swing targets far more "platforms" than JSF ;-P

Have fun,

Remi

Well, it depends of your organization goals. I work for the government right now. We have to conform to strict xhtml and to support a high accessibility level so indeed I do care about the generated HTML. Therefore I have to know about Renderers because I have to validate the outputted HTML.

Then, why components ?I mean, if you still have to put your hands in HTML, what added value does JSF bring you compared to MVC2 frameworks (or others like Tapestry which makes components easier than JSF) ?

Because components have a lot more advantages and with tradional MVC-oriented frameworks I still have to validate the HTML anyway (Quality Assurance you know). At least, once a component is working correctly, I know the HTML outputted will be correct.

 But at least using JSF or any components-oriented frameworks, I just have to do it once.It's not all the organization who don't care about the generated markup. You can't compare Swing to JSF in that matter. Ultimately Swing output directly on your screen while JSF generates content to a lot of different clients.

Yep, but since the portability layer is at the VM level, I don't care :-)That's one of the primary strenghts of Swing : write once, run everywhere !Also, "generating content to a lot of different clients" is a bit of an utopy IMHO. All "clients" (or should we say "environments") don't allow the same things, they were not designed to do the same things !I would bet that an UI designed for a web client would have to be at least partially rewritten for a mobile device... just like you would not be easily able to use VR applications in the browser because you have JSF...Last but not least, has anyone here ever used such "UI meta-model" concept in practise in real-life apps ?I think there's not that much...Actually, I think Swing targets far more "platforms" than JSF ;-PHave fun,Remi

You didn't get what I meant by clients. Here I have to support Mozilla, IE 5 & 6 and some others. They will all get the same HTML, yet they all interpret HTML differently. Swing can adapt the output to your screen since it is the true renderer. Not JSF or any web framework, in the end the web browser will have the last word based upon its HTML interpretation.

I am not stupid, I know I will have to redevelopp new pages if I want to support WML. But HTML is an interpreted language after all and that is the real difference between any Web GUI frameworks and Client GUI frameworks.

Because components have a lot more advantages

I'm playing the devil's advocate here : I'm also for components... when they are useful and easy to use ;-P

and with tradional MVC-oriented frameworks I still have to validate the HTML anyway (Quality Assurance you know).

Well, someone less skilled than you could do this...
I mean, the entry level to JSF for a web designer is pretty high...
Talk about writing the Renderer to a dreamweaver person ;-P

Ho, and it's nothing to do with facelets, other templating stuff etc. I'm talking about rendering the components here.

 At least, once a component is working correctly, I know the HTML outputted will be correct.

Well once my JSP fragment / Velocity template / etc. is working correctly I know it's valid HTML as well...

Honestly, I don't see the benefits of a string component model for this.

You didn't get what I meant by clients. Here I have to support Mozilla, IE 5 & 6 and some others. They will all get the same HTML, yet they all interpret HTML differently.

What about applets/webstart and plaf then ?
:-)

 Swing can adapt the output to your screen since it is the true renderer.

Well it's very low-level but of course you can paint() your components yourself in Swing as well (as Jacob stated, I think it's a rare thing though... maybe as rare as people rendering JSF components themselves ;-P).
And the rendering has virtually no limits. It's the ultimate renderer actually : pixels, lines, ... :-)
Can you draw virtually anything to a canvas like this in JSF ?

 Not JSF or any web framework, in the end the web browser will have the last word based upon its HTML interpretation.

So back to my initial question : why JSF ? (I don't try to tease, it's a real question and I can understand many answers to this, starting by the fact it's a standard...)

I am not stupid,

I never meant you were... Just trying to understand a real-life user's point of view.

I know I will have to redevelopp new pages if I want to support WML. But HTML is an interpreted language after all and that is the real difference between any Web GUI frameworks and Client GUI frameworks.

Mmmh, I woudn't say so. IMHO what makes the web really different from desktop programming is that damn stateless HTTP, before everything else !
Trying to build a house on the water is always harder than on solid foundations...

Have fun,

Remi

http://xulfaces.sourceforge.net/screenshots.html

http://weblogs.java.net/blog/jhook/archive/2005/09/tomorrows_webto.html

http://xulfaces.sourceforge.net/screenshots.htmlhttp://weblogs.java.net/blog/jhook/archive/2005/09/tomorrows_webto.html

http://java.sun.com/products/javawebstart
:-)

I don't know what you refer to (maybe a sentence or two would have helped), but if you plan to convince people of adopting JSF with those kind of links, please avoid ;-P

Honestly, I've been writing webstarted Swing desktop apps, 3D applets, custom graphical components (e.g. an extension of JPanel that represents the 2D plan of a building storey - clickable, zoomable, etc.).
All this was almost a piece of cake with Swing... you tell me when there's a JavaScript/AJAX/XUL/other bullshit-based 3D engine available around !

Showing nice popups and sexy comboboxes in the browser does not convince. At least, not me !

Basically, what I'd have expected from JSF is to build webapps faster, by reusing components instead of JSP fragments/templates/anything.
Nothing more.
I certainly don't want to learn yet-another-XMLenstein-horror, just to have those sexy widgets that make my webapp look like a desktop app...

Have fun,

Remi

... then what the hell is MS doing with XAML in their new OS? IMHO, it's going to open up a whole different type of application deployment that JSF is perfectly adapted for. XUL is just one option at this point for early adoptors.

As for 3D-engine based bullshit, you should check out some of the mozilla developer stuff with SVG (which is fully integrated with XUL) :-)

I certainly don't want to learn yet-another-XMLenstein-horror, just to have those sexy widgets that make my webapp look like a desktop app...

Maybe that's the point though with JSF-- it encapsulates the xml/js/behavior crap and you just use higher level concepts to tie that into your application model. I'm just waiting for all of us to stop spinning our wheels, trying to make HTML/DOM/JS look and behave like what we have with XUL or XAML.

... then what the hell is MS doing with XAML in their new OS?

Marketing ?
;-P

IMHO, it's going to open up a whole different type of application deployment that JSF is perfectly adapted for.
XUL is just one option at this point for early adoptors.

Even if it may help for a majority of applications (yes, building "regular" forms is easy with this - I doubt more complicated things are that easy though), I don't see these "meta-UI-programming environments" as a silver bullet.

My point is Swing is almost that silver bullet...

Note that I'm not saying that webapps are dead yet : I'm just saying that WebStart/Swing is the best answer when you want to do multiplatform rich clients...

I don't think webapps are used for the same purposes (try to implement Eclipse in XUL for example !).
IMHO they are simpler (look : everybody knows how to use them !), so they should require simpler skills.

My initial point was that JSF should bring this simplicity...

As for 3D-engine based bullshit, you should check out some of the mozilla developer stuff with SVG (which is fully integrated with XUL) :-)

Erf, I'm working with VR folks all day long... Knowing how they **** the flies for one triangle or two, how they make use of GPU etc... I have serious doubts about the SVG option ;-P
BTW they don't use Java at all, they're C++ addicts !!!

Maybe that's the point though with JSF-- it encapsulates the xml/js/behavior crap and you just use higher level concepts to tie that into your application model.

Man, sounds like a dream ! When is it coming out ?
:-)

Seriously, I'm with you on this. That's exactly what I'd like to see in JSF, instead of struggling with JSP integration, <verbatim> stuff, etc. !

Maybe I should try a visual IDE also...

  I'm just waiting for all of us to stop spinning our wheels, trying to make HTML/DOM/JS look and behave like what we have with XUL or XAML.

We'll stop the wheel when we'll get rid of the whole web stack IMHO.
How can we all be sitting on this pile of crap since years now ?
Man, with all these great technologies (OO, high-level middlewares, Object persistence, transactions, lightweight deployments...) we're still hesitating ! Nonsense...

Anyway I guess we'll have to live a few years with this, so as everyone who builds webapps, I'd be happy with a working and simple encapsulation of all this.

Have fun,

Remi

Then this is what you are looking for :
http://smile.sourceforge.net/

This is what I like about JSF, support the pure components approach or the template view mixed with components approach.

Then this is what you are looking for :http://smile.sourceforge.net/This is what I like about JSF, support the pure components approach or the template view mixed with components approach.

Forgot to say, authors have now moved to Echo but well I still think their project looks good :)

Forgot to say, authors have now moved to Echo but well I still think their project looks good :)

Erf, baaad example : apparently the project is no longer supported, and there's a follow-up called jzeno which uses, I quote, "an optimized version of the Echo framework from NextApp" !
Apparently they didn't really enjoy JSF...

All these (ZK, Echo, etc.) are pretty interesting initiatives, and IMHO they illustrate my point : they are simple to set-up and use, that's why even if they're less powerful/extensible/whatever than JSF, they gain acceptance easier...

Have fun,

Remi

Out of curiosity, I read a few pages on jZeno's web...

 We decided to create jZeno after growing more and more frustrated with JSP and Struts over the years. We hoped JSF would improve things but have come to the conclusion that it is mainly a commercially-driven API that does not really make development life any easier

!

Have fun,

Remi

Out of curiosity, I read a few pages on jZeno's web...

&nbsp;We decided to create jZeno after growing more and more frustrated with JSP and Struts over the years. We hoped JSF would improve things but have come to the conclusion that it is mainly a commercially-driven API that does not really make development life any easier

!Have fun,Remi

I knew this when I submitted the page but I just don't necessarily agree with the authours (now no one can say I am a JSF zealot :p). I just wanted to point you that creating jsf components in Java is doable. By the way, they refer to the initial spec which indeed was very hard to use (alternatives to JSP like Faclets weren't existing).

But to me, they are going backward. This is the part of Swing I always hated, constructing my UI in Java. Next time, I will definitly use a template UI language or use a tool. Maybe it is a reason why you don't see so many projects using this approach but it is doable.

I knew this when I submitted the page but I just don't necessarily agree with the authours (now no one can say I am a JSF zealot :p).

he he :-)

Anyway, the point is not really that you agree or not with them. I think what they say is pretty revelatory of JSF's mis-interpretation in many developer's minds. Lots of us find it over-complicated in comparison to the "direct" benefits it brings (ROI).

 I just wanted to point you that creating jsf components in Java is doable.

Yep, I liked the example. It's far more close to the way I see UI development than XUL or such exotic XML-based stuff...

 By the way, they refer to the initial spec which indeed was very hard to use (alternatives to JSP like Faclets weren't existing).

Why didn't they start by... Java ?
:-)

But to me, they are going backward. This is the part of Swing I always hated, constructing my UI in Java.

Do you really prefer constructing it in XML ??? Seriously ?? Come on...

 Next time, I will definitly use a template UI language

To develop a complex app ??? I'd definitly use NetBeans RCP instead ;-P

 or use a tool.

There's a few Swing GUI design tools out there.
Honestly, writing UIs with e.g. Matisse & nbplatform is very convenient and damn faaaaast comparing to struggling with taglibs, unreadable .xhtml files everywhere, server restart, hundreds of config files... If you have good Swing libs too (e.g. ZValley's which is excellent compared to its price), then it's just... a piece of cake ;-)
And user experience is far better, of course.

Maybe it is a reason why you don't see so many projects using this approach but it is doable.

I know it's doable. All I ask from the JSF people is to show us how, in a simple way !!!

And btw, look at Echo etc. Are you that sure that there are so few projects using this ? I wouldn't bet...

Have fun,

Remi

I knew this when I submitted the page but I just don't necessarily agree with the authours (now no one can say I am a JSF zealot :p).

he he :-)Anyway, the point is not really that you agree or not with them.

Ok Please explain because this sentence doesn't make any logical sense. They have the right to disagree on JSF but I don't have the right to disagree? Or maybe you think they represent the majority???

I think what they say is pretty revelatory of JSF's mis-interpretation in many developer's minds. Lots of us find it over-complicated in comparison to the "direct" benefits it brings (ROI).

Yet many other developpers like me find it good, MyFaces mailing traffic list is one of the highest in all the Apache projects.

&nbsp;I just wanted to point you that creating jsf components in Java is doable.

Yep, I liked the example. It's far more close to the way I see UI development than XUL or such exotic XML-based stuff...

&nbsp;By the way, they refer to the initial spec which indeed was very hard to use (alternatives to JSP like Faclets weren't existing).

Why didn't they start by... Java ?:-)

Because not everyone believe in constructing GUI using Java like you. For my part, I don't like to bent Java to every possible use, template language is just more effective there.

But to me, they are going backward. This is the part of Swing I always hated, constructing my UI in Java.

Do you really prefer constructing it in XML ??? Seriously ?? Come on...

&nbsp;Next time, I will definitly use a template UI language

To develop a complex app ??? I'd definitly use NetBeans RCP instead ;-P

&nbsp;or use a tool.

Your opinion

I prefer things like
http://today.java.net/pub/a/today/2006/03/30/introducing-jaxx.html
It is a personal preference but I found it way more effective. It doesn't not mean I don't like or use tools, some tools works great and allow xml template languages. I find Java less productive to construct GUI.

There's a few Swing GUI design tools out there.Honestly, writing UIs with e.g. Matisse &amp; nbplatform is very convenient and damn faaaaast comparing to struggling with taglibs, unreadable .xhtml files everywhere, server restart, hundreds of config files... If you have good Swing libs too (e.g. ZValley's which is excellent compared to its price), then it's just... a piece of cake ;-) And user experience is far better, of course.

Have you ever tried JSF? There is one config file, faces-config.xml which is very simple and yet you can use
annotations using Struts Shale. Not hundred like you say.

Taglibs and server restart, never heard of it since I use facelets.

Maybe it is a reason why you don't see so many projects using this approach but it is doable.

I know it's doable. All I ask from the JSF people is to show us how, in a simple way !!!And btw, look at Echo etc. Are you that sure that there are so few projects using this ? I wouldn't bet...Have fun,Remi

A pure Java JSF API is not a main concern in the JSF community because most people prefer using a template view technology like facelets.

And I am not saying Echo isn't popular. I like JSF to have competition and I hope Echo or any other OSS project is going to be successful in the long run.

Ok Please explain because this sentence doesn't make any logical sense. They have the right to disagree on JSF but I don't have the right to disagree? Or maybe you think they represent the majority???

No no, everyone does what he wants, you have the right to disagree with anything, that's not the point.
What I meant is that your opinion is one thing, the fact JSF is perceived as over-complicated by many developers is another !

Yet many other developpers like me find it good, MyFaces mailing traffic list is one of the highest in all the Apache projects.

Erf. Swing's MLs are not so popular, for sure... Maybe in part because it works ? ;-P

Seriously, analysing traffic on MLs won't tell you if a technology has solid foundations or if it's usable.

Do you frequent tomcat MLs ? I don't. But still, I use tomcat on a daily basis and I'm happy with it, it's working and usable so I don't need to post in any ML...

Because not everyone believe in constructing GUI using Java like you.

I think this comes from the web. I mean, the most sophisticated UIs are built using Swing, QT, Delphi and other component-based systems.
Nobody, before the web and HTML became such a common thing, would ever have imagined to do this in a markup language...

Anyway, once again everyone uses technology as he wants, but honestly I can't believe templating is better than pure OO, sorry.
Don't hesitate to prove me wrong :-)

For my part, I don't like to bent Java to every possible use, template language is just more effective there.

Why ?

Have you ever tried JSF?

A little bit yep. It took me one hour to ask myself why everything was so complicated and ugly !!!

There is one config file, faces-config.xml which is very simple and yet you can useannotations using Struts Shale.

My point is precisely that it should be attractive out-of-the-box !

That's like if I go and buy a brand new car, that everybody talks about. On the way back home, I remark that I can't use the gearbox, and the lights are not working etc. I call the guy who sold me the car, and he tells me I have to add options so my car works as I expected it to work from the beginning ! Moreover the options are exotic stuff that I have to learn in order to drive this car !!!
At this point of time, I'm seriously thinking about buying a regular car you know...

Not hundred like you say.Taglibs and server restart, never heard of it since I use facelets.

Facelets look good, but same issue : it tends to prove that JSF in itself is not sufficient !

And btw, the server restart (or hot redeploy) is mandatory because you are running a server !
In Swing you only invoke a main() that pops up a screen.
No server bs, only pure UI.
That's why things are a bit quicker to test...

A pure Java JSF API is not a main concern in the JSF community because most people prefer using a template view technology like facelets.

IMHO, rich UIs in the browser will be easy to develop when frameworks will completely abstract the protocol and rendering. Proposing taglibs, JSP or XHTML in JSF is a mistake to me. It doesn't really show how JSF leverages web development.

Once again, it can look like PHP with increased complexity for a non-expert. So web developers will still do PHP, and complex UI designers will stick to WebStart or Echo.

And I am not saying Echo isn't popular. I like JSF to have competition and I hope Echo or any other OSS project is going to be successful in the long run.

At least we agree on this :-)

And btw, note that I'm trying to make contructive criticism about JSF. I would not spend energy doing this if I did not believe in such approaches.

Have fun,

Remi

Just had a quick look at Jaxx, and this time it took ine second to check it out !

Look at this, from the home page, this is one of the most crappy piece of code, and one of the biggest reinvention of the wheel I've ever seen :

<Application title='Greeter'>
  <script>
    protected void showGreeting() {
        String name = nameField.getText();
        JOptionPane.showMessageDialog(this,
                     "Hello, " + name + "!");
    }
  </script>
  
  <VBox margin='6, 6, 6, 6' spacing='6'
                 horizontalAlignment='center'>
    <HBox>
      <JLabel text='Your name:'
              displayedMnemonic='Y'
              labelFor='{nameField}'/>

      <JTextField id='nameField'/>
    </HBox>

    <JPanel layout='{new GridLayout(1, 0, 6, 0)}'>
      <JButton text='Greet!' mnemonic='G'
           onActionPerformed='showGreeting()'/>

      <JButton text='Close' mnemonic='C'
        onActionPerformed='dispose()'/>
    </JPanel>
  </VBox>
</Application>

The guys don't even know what they want themselves : they want XML but still you have Java in there... IMHO it's even worse than a scriplet-bloated JSP !

Good debugging sessions in perspective !!

How can you think you're more productive with this than Swing ? Please tell me, it's a mystery !!

Have fun,

Remi

Just had a quick look at Jaxx, and this time it took ine second to check it out !Look at this, from the home page, this is one of the most crappy piece of code, and one of the biggest reinvention of the wheel I've ever seen :

<Application title='Greeter'>&nbsp;&nbsp;<script>&nbsp;&nbsp;&nbsp;&nbsp;protected void showGreeting() {&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;String name = nameField.getText();&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;JOptionPane.showMessageDialog(this, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;"Hello, " + name + "!");&nbsp;&nbsp;&nbsp;&nbsp;}&nbsp;&nbsp;</script>&nbsp;&nbsp;&nbsp;&nbsp;<VBox margin='6, 6, 6, 6' spacing='6'&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;horizontalAlignment='center'>&nbsp;&nbsp;&nbsp;&nbsp;<HBox>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<JLabel text='Your name:' &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;displayedMnemonic='Y'&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;labelFor='{nameField}'/>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<JTextField id='nameField'/>&nbsp;&nbsp;&nbsp;&nbsp;</HBox>&nbsp;&nbsp;&nbsp;&nbsp;<JPanel layout='{new GridLayout(1, 0, 6, 0)}'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<JButton text='Greet!' mnemonic='G'&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;onActionPerformed='showGreeting()'/>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<JButton text='Close' mnemonic='C'&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;onActionPerformed='dispose()'/>&nbsp;&nbsp;&nbsp;&nbsp;</JPanel>&nbsp;&nbsp;</VBox></Application>

The guys don't even know what they want themselves : they want XML but still you have Java in there... IMHO it's even worse than a scriplet-bloated JSP !Good debugging sessions in perspective !!How can you think you're more productive with this than Swing ? Please tell me, it's a mystery !!Have fun,Remi

How is it worst then calling 50 different setter methods and using anonymous classes? I prefer a declarative UI approach, I don't need a programming language unless the UI is going to drastically change over time. I like using XML for declarative purpose. I think it is useful if you don't abuse it.

Since it is a declarative approach, it's not hard at all to debug if the error screen point me to the correct line and output the printstack like facelets already does. No need for a debugger. I haven't tried JAXX but I will next time I have to developp in Swing.

You might be interested :
http://www.jaxxframework.org/forum/viewtopic.php?t=13

You might be interested :http://www.jaxxframework.org/forum/viewtopic.php?t=13

The guy himself has no real justification. These kind of agruments simply don't make it :

XML is the "standard" format for user interface languages (XUL, Flex, SwiXML, Beryl, SwingML, and more).

I'm happy to learn this, I wasn't aware the "UI community" finally agreed on something !

XML is a naturally heirarchical language (tags contain other tags),

So what ?
Objects may contain other objects as well...

XML is (surprisingly) very compact and efficient for representing component trees.

Big surprise, for sure !

First off, it's compiled.

This is a revolution...

JAXX uses Java as its scripting language

Erf, what about being consistent ?

Anyway, there are a whole lot of things that I believe JAXX does better than the competition. But of course, that's just my opinion

You say it mate :-P

Have fun,

Remi

How is it worst then calling 50 different setter methods and using anonymous classes?

A pure Swing implementation of their example would actually be more concise and readable...

And even if it wasn't... Type-safety ? Compile-time errors ? Readability ? IDE integration ? Object-orientation ?
Seriously, what's the point in XML as a programming language ? I already find pretty weird that it's used for B2B, but programming with this... gee, do you enjoy hurting youself ? ;-P

 I prefer a declarative UI approach,

This isn't declarative. This is instantiation of some Java objects done in XML ! This is the implementation of a method, not a class declaration.
Writing it in pure Java would simply be more convenient, less verbose, easily testable and hundreds of other cool things :-)

I don't need a programming language unless the UI is going to drastically change over time. I like using XML for declarative purpose. I think it is useful if you don't abuse it.

Using it for programming is abusing, by definition. Don't forget it's been invented to represent data in a neutral fashion. At the early beginning, it was supposed to allow easy exchange of documents between heterogeneous systems. It wasn't supposed to replace programming languages, and actually I'm glad it hasn't !!

Since it is a declarative approach, it's not hard at all to debug if the error screen point me to the correct line and output the printstack like facelets already does.

What about stuff like <script>some java code here</script> in XML pages ?
Don't you need a debugger for that ??

Also, I was thinking, imagine the overhead for extending the components !!! Not only you've got to write the java code, now you have to "tagify" it just to... do the same things you did before in an easier way !

This is just nonsense, I may try to find, I can't get the point.

No need for a debugger. I haven't tried JAXX but I will next time I have to developp in Swing.

Well, let me know your feedback then. I must admit I can't see any advantage in this, I only see lots of disadvantages !!

Have fun,

Remi

How is it worst then calling 50 different setter methods and using anonymous classes?

A pure Swing implementation of their example would actually be more concise and readable...And even if it wasn't... Type-safety ? Compile-time errors ? Readability ? IDE integration ? Object-orientation ?Seriously, what's the point in XML as a programming language ? I already find pretty weird that it's used for B2B, but programming with this... gee, do you enjoy hurting youself ? ;-P

&nbsp;I prefer a declarative UI approach,

This isn't declarative. This is instantiation of some Java objects done in XML ! This is the implementation of a method, not a class declaration. Writing it in pure Java would simply be more convenient, less verbose, easily testable and hundreds of other cool things :-)

I don't need a programming language unless the UI is going to drastically change over time. I like using XML for declarative purpose. I think it is useful if you don't abuse it.

Using it for programming is abusing, by definition. Don't forget it's been invented to represent data in a neutral fashion. At the early beginning, it was supposed to allow easy exchange of documents between heterogeneous systems. It wasn't supposed to replace programming languages, and actually I'm glad it hasn't !!

Since it is a declarative approach, it's not hard at all to debug if the error screen point me to the correct line and output the printstack like facelets already does.

What about stuff like <script>some java code here</script> in XML pages ?Don't you need a debugger for that ??Also, I was thinking, imagine the overhead for extending the components !!! Not only you've got to write the java code, now you have to "tagify" it just to... do the same things you did before in an easier way !This is just nonsense, I may try to find, I can't get the point.

No need for a debugger. I haven't tried JAXX but I will next time I have to developp in Swing.

Well, let me know your feedback then. I must admit I can't see any advantage in this, I only see lots of disadvantages !!Have fun,Remi

Well this is where I strongly disagree with you. Constructing UI is declarative, the order of the operations doesn't mind at all, the hierarchy matters. I prefer to use the language statements order to express the hierarchy (like XML does) then using to specify it a construction order I don't care of. Just cleaner in my opinion.

he internal scripts are probably a bad thing but you can probably externalize it in a Java class. That maybe some issues but overall I agree with his approach. Well this debate could go on and on but I think we would never agreed, I think UI should be used in a declarative manner but you don't. No problem with it but I don't think a lot of people are interested in the Java pure approach in the JSF community. It is why you don't see any samples or development into this area.Well I know I am not ;)

Using it for programming is abusing, by definition. Don't forget it's been invented to represent data in a neutral fashion. At the early beginning, it was supposed to allow easy exchange of documents between heterogeneous systems. It wasn't supposed to replace programming languages, and actually I'm glad it hasn't !!

Actually, XML is just a general text markup technology. Using it for programming is not abuse, any more than using other ways of delimiting syntax (ascii text + semi-colons or line feeds) is abuse.

Using it for programming is abusing, by definition. Don't forget it's been invented to represent data in a neutral fashion. At the early beginning, it was supposed to allow easy exchange of documents between heterogeneous systems. It wasn't supposed to replace programming languages, and actually I'm glad it hasn't !!

Actually, XML is just a general text markup technology. Using it for programming is not abuse, any more than using other ways of delimiting syntax (ascii text + semi-colons or line feeds) is abuse.

Agreed, you choose your text representation depending of your needs.

The text order of an imperative programming language is used to specify the statements execution order, something totally not needed when you build an UI. In XML-based markup languages, it is used to represent the components hierarchy, something strongly needed when you build an UI.
This way, in a XML-based language, you don't need to specify a lot of things (calling setters, keeping a reference on every objects just to add some childrens components, ...). The language makes it implicit. This is why the XML syntax would always be more concise than the equivalent Java one.

Agreed, you choose your text representation depending of your needs.

That's exactly what I want to say :-)
Java for programming, XML for exchanging simple and small documents.

The text order of an imperative programming language is used to specify the statements execution order, something totally not needed when you build an UI.

Really ? We definitly don't build the same UIs !!!

To me an UI is a little of component layout and declaration, and a lot of coding (backing data models, observers, events etc.) ! I think you clearly have the regular "CRUD form app" in mind when you say such things.
Well, sorry you don't know this, but these kind of apps simply don't require you to code anything today (ever tried stuff like windev ?) ! No XML, no Java, just play with the mouse and you're done...

Most of the code in complex OO interfaces is not about adding JTexFields into JPanels but about handling events etc. Most of my swing code is about table/tree models, custom observers etc.

So IMHO putting some XML in there just 'cause it's fashion (it does not solve any problem : there is no problem to solve anyway !) is yet another way to confuse people (why should we learn something new whereas we have something that already works since decades ?).

This is why the XML syntax would always be more concise than the equivalent Java one.

Is this April's fool stuff a competition or what ??
Man, XML-coding less verbose than Java ? That's quite a news !

<class name="org.xyz.MyClass" extends="org.xyz.MySuperClass" mofifiers="public,final">
  <member name="myPrivateMember" type="String" modifiers="private,static"/>
  <method name="doIt" returnType="void" modifiers="public">
    <arg name="arg0" type="int"/>
    <arg name="arg1" type="int"/>
    <code>
      <!-- I can't imagine what to put here sorry :-P -->
    </code>
  </method>
...

Does this really look concise and understandable to you ??

Have fun,

Remi

!<class name="org.xyz.MyClass" extends="org.xyz.MySuperClass" mofifiers="public,final">&nbsp;&nbsp;<member name="myPrivateMember" type="String" modifiers="private,static"/>&nbsp;&nbsp;<method name="doIt" returnType="void" modifiers="public">&nbsp;&nbsp;&nbsp;&nbsp;<arg name="arg0" type="int"/>&nbsp;&nbsp;&nbsp;&nbsp;<arg name="arg1" type="int"/>&nbsp;&nbsp;&nbsp;&nbsp;<code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<!-- I can't imagine what to put here sorry :-P -->&nbsp;&nbsp;&nbsp;&nbsp;</code>&nbsp;&nbsp;</method>

Is this April's fool stuff a competition or what ??
We are not talking about configuration or an IoC container you know but UI design. Java is way more concise in a lot of places but not in the UI space (JSP vs outputting string in a Servlet for instance).

Here's a simple case :

Using a XML syntax
<label id="id" text="text" title="title" [...] />

Using a Java syntax
JLabel label = new JLabel();
label.setId("id");
label.setText("text");
label.setTitle("title");
label.setXXX

XML looks more concise to me in this case and this a very basic example.

And don't tell me the order matters, because I could set the text before setting the id without any problems, same with the title. No good UI components framework is dependant upon the order in which you add components or specify properties.

And by the way let's forget about tools. We are talking about semantic representation here. Of course, a good tool would make it very easy for both but it's not the point.

We are not talking about configuration or an IoC container you know but UI design.

IMHO, UI design is more about coding than just instanciating JLabels and adding them to JPanels...

 Java is way more concise in a lot of places but not in the UI space (JSP vs outputting string in a Servlet for instance).

The comparison does not stand. Compare JSPs with e.g. Echo instead...
A "out.println" servlet does not do anything more or different than a JSP : it's still about textual output.
And once again, many applications require more.

Here's a simple case :
Using a XML syntax
<label id="id" text="text" title="title" [...]/>
Using a Java syntax
JLabel label = new JLabel();
label.setId("id");
label.setText("text");
label.setTitle("title");
label.setXXXXML
looks more concise to me in this case and this a very basic example.

Yes it is ! Too simple, and moreover bias : you can also pass arguments to constructors in pure OO (check JLabel's JavaDocs)...
So your example would just be like :

JLabel l = new JLabel("Some Text", myIcon, ...);

which is strictly equivalent to the XML option...

Show me some code with listeners etc.
Show me the use of a custom subclass of a Swing Component (e.g. MyOwnTextField extends TextField - feck I have to write a taglib to wrap code that is already written and usable !!).
etc.
etc.
etc.

Have fun,

new Remi();
:-P

XAML allows to combine actual C# or VB code with UI definition in XML. Or you can define your listeners in a separate code-behind class. It is up to you. Most UI us quite static, so I am happy when I can define it externally from an application. I am not sure that I fond of XML per se, but at least I don't have to instantiate panels and fields manually in the code and then to hook up all the listeners. Yuck.

We are not talking about configuration or an IoC container you know but UI design.

IMHO, UI design is more about coding than just instanciating JLabels and adding them to JPanels...

&nbsp;Java is way more concise in a lot of places but not in the UI space (JSP vs outputting string in a Servlet for instance).

The comparison does not stand. Compare JSPs with e.g. Echo instead...A "out.println" servlet does not do anything more or different than a JSP : it's still about textual output.And once again, many applications require more.

Here's a simple case :Using a XML syntax<label id="id" text="text" title="title" [...]/>Using a Java syntaxJLabel label = new JLabel();label.setId("id");label.setText("text");label.setTitle("title");label.setXXXXMLlooks more concise to me in this case and this a very basic example.

Yes it is ! Too simple, and moreover bias : you can also pass arguments to constructors in pure OO (check JLabel's JavaDocs)...So your example would just be like :JLabel l = new JLabel("Some Text", myIcon, ...);which is strictly equivalent to the XML option...Show me some code with listeners etc.Show me the use of a custom subclass of a Swing Component (e.g. MyOwnTextField extends TextField - feck I have to write a taglib to wrap code that is already written and usable !!).etc.etc.etc.Have fun,new Remi();:-P

A constructor doesn't have the same flexibility :
1. In xml you chose which attributes you specify, any combination is possible. This not possible with constructors.
2. Using constructors, you need to remember the arguments order something very impratical. XML syntax is easier to remember because you don't rely on attributes order but on the attribute name.

About custom tags, you base your experience way too much on JSP. In most other view template technologies, you don't need to "write a taglib to wrap your code", this is a JSP-only problem because JSP is a general purpose view technology. Usually, in a more specialized template language, you can just link the tag name with the UI component and it works. That is what Facelets does. You don't need to write any Tag class. So basically, to use a custom subclass, I would do <MyComponent ... /> and nothing more spectacular. I don't know what you are expecting.

Now, what is the problem with listeners? I am not saying to write them using XML code, in the XML you should only find the method binding (using EL or another binding language). This is what JSF already does. For instance, in JSF you would write
<commandLink actionListener="${someObject.someMethod}"/>
which would tell the component to call the method "someMethod" of the object "someObject" when an action event happen.

So what is so bad about specifying the binding in the XML document? Because refactoring tools don't support it yet? By the way, why are you saying my code is biased?? Give me an example in which you think a static UI is better constructed using Java because really I can't think of one. Of course, if the interface is highly dynamic I would rather use Java to construct it, something quite easy to do in JSF using the "binding" attribute.

I would never put any Java code inside a template view because it is a bad practice indeed but going the other way around is not better, ie using Java to construct your static UI. A declarative approach is much more powerful there because the construction order doesn't matter. So an imperative programming language (notice how the name relates to the statements execution order?) is not very suited to this task. It's not because JSP got some parts wrong (tags) that every view template technologies are bad. They really fill a need.

Mhhh, I think I begin to get your points.

I'm not really convinced myself, but at least you both have arguments that begin to make sense to me.

Maybe I should try it out deeper and I'd find out it works fine... Actually I don't remember ever doing it really, apart from using taglibs which is an horrible example.

Have fun,

Remi

Actually, XML is just a general text markup technology. Using it for programming is not abuse, any more than using other ways of delimiting syntax (ascii text + semi-colons or line feeds) is abuse.

Is this the april's fool post ? :-P

Come on, even if you prefer building UIs in XML (which I already find crappy), did you really ever thouhgt about writing the event handlers in something else than Java ???
And it's not even worth talking about back-end implementation (XML-based POJOs : the ultimate horror !!!)...

IMHO, all this XML crap is probably the most useless reinvention of the wheel ever. I think I've never seen such a pitiful buzz for... nothing ! A good example of how marketing prevails on technology :-/

Anyway, I don't care, you can hurt yourself if you like it... :-P

Have fun,

Remi

Well, it depends of your organization goals. I work for the government right now. We have to conform to strict xhtml and to support a high accessibility level so indeed I do care about the generated HTML.

Are they okay with using Javascript? I've heard that many government organizations either totally prohibit Javascript or require an application to function with Javascript turned off. Also, I've heard that many of these organizations still use Netscape 4. Or was it true two years ago, but not anymore?

To me, [xulfaces team] is going backward. This is the part of Swing I always hated, constructing my UI in Java. Next time, I will definitly use a template UI language or use a tool.

Agreed. I never could understand why Swing does not have resource files for dialogs, menus, images, etc like Windows and other windowing environments has had for at least 15 years. I am not saying the resources must be defined in XML, but I would prefer to define my dialogs outside the code anyways.

Constructing UI is declarative, the order of the operations doesn't mind at all, the hierarchy matters.

For things like dialog windows - yes, for things like putting an image inside text editor - no. But the good thing that most UI arifacts in a business application have pretty static dialog-like appearance. Remi mentioned Delphi as a good example of code-based GUI. Remi, do you know that Delphi uses resource files (DFM) behind the scenes? You can even translate DFM into regular Windows resource file.

Well, it depends of your organization goals. I work for the government right now. We have to conform to strict xhtml and to support a high accessibility level so indeed I do care about the generated HTML.

Are they okay with using Javascript? I've heard that many government organizations either totally prohibit Javascript or require an application to function with Javascript turned off. Also, I've heard that many of these organizations still use Netscape 4. Or was it true two years ago, but not anymore?

Fortunately, nowadays it's ok to require JavaScript and Cookies to be enabled (at least here in Quebec, Canada) but indeed it wasn't before. It was a bit crazy if you ask me. But we still have to support a lot of navigators and good XHTML for accessibilty reasons. For instance, blind people need to be able to use a text-to-speech synthesizers, which are very dependant upon a good syntax. It's not something developpers naturally think about but it is very important in a public organization.

Remi, do you know that Delphi uses resource files (DFM) behind the scenes? You can even translate DFM into regular Windows resource file.

Yes I remember DFMs. But you know that when programming with Delphi you're not supposed to look into it (apart from the system goes crazy you don't know why and you have that ugly popup with hexa stuff ya know - who complains about Java's exception stack traces btw ??? ;-P).
DFMs are some kind of internal stuff that's used by the system, not by the programmer.
The programmer has some kind of WYSIWIG, which of course is far better than writing the UI yourself, whatever the language, so he doesn't care about the underlying stuff.

And, btw, I almost don't build the UIs in pure Java anymore : I also use a visual builder as much as I can (e.g. Matisse which I find pretty cool for a free-of-charge tool)...
But still if I want to have a look in there, it's full Java, I can put breakpoints where I want, etc.
Not to mention dynamic UI construction (sometimes you manipulate some widgets programmatically) or extending components etc.

Anyway, as Alexandre said, I guess it's more a question of feeling than anything, like scripting vs compiled for example...

Have fun,

Remi

I think we have to forget a lot of bad habits we have in webapps

Did you mean that *you* have to forget a lot of bad habits *you* have in webapps?

Show us we can do without putting our hands in the request/response/HTML/taglibs... crappy stuff that usually comes along with webapps.

Oh no, this is the good stuff. The argument has not changed from old times: some like to use plain C and WinAPI, others prefer Visual Basic.

I think we have to forget a lot of bad habits we have in webapps

Did you mean that *you* have to forget a lot of bad habits *you* have in webapps?

Well I'd like to.
You seem to be happy with web developement... Think about it : are you really building Webapps as fast as Desktop apps ?

And btw, we're all moving in that direction : look at the abstraction levels we have now, and it's getting higher and higher.
As far as I see it, we *all* try to abstract the protocol (built-in state handling etc.) and markup (components etc.) so that we develop faster... like we develop Desktop apps.

Show us we can do without putting our hands in the request/response/HTML/taglibs... crappy stuff that usually comes along with webapps.

Oh no, this is the good stuff.

<c:if> in JSPs ?
Come on...
I love components, I love objects, I don't see the need for that XML everywhere and other freakin' <verbatim> tags or I don't know what !
I don't want to see all this ! Especially to develop UIs which are amongst the most simple existing ones (Swing's not only about formatting textual documents - which is what HTML is all about) !!!
Do you get my point now ? ;-P

And once again, I really think that JSF is a good initiative and will be a good answer to all my problems... when it'll be more mature.
As many, I've been quite disappointed with JSF/JSP, but I could live with a working XML-based version of it for the moment (I'll certainly give a shot at facelets when I'll have time). I only said that I'd even prefer a full-Java version...

 The argument has not changed from old times: some like to use plain C and WinAPI, others prefer Visual Basic.

???
Are you currently comparing Swing with the first one, and JSF with the second ?

You must be jokin'... Oh yes I get it : it's the first of april today !!! You almost got me ! Ha ha !
;-P

Have fun,

Remi

I have to agree, it's certainly not the friendliest framework I've ever used. But it is one that works, given enough time to understand its subtleties and complexities.

I believe you can write excellent usable applications using JSF components - I think it can make great web UIs work. But as a developer writing components for JSF, I think it is hard work and does require a lot of time investment to understand the framework well before diving in. However I do believe the highly reusable nature of JSF components makes them worth the struggle to implement.

Myself a colleague wrote an article on our JSF development during the first few months of writing the framework and custom JSF components for the Alfresco Content Management System web-client interface:

http://www.jsfcentral.com/articles/trenches_5.html
http://dev.alfresco.com/

I believe JSF was the right choice - the app is very usable and the components ARE reusable and work well. The main issues have been the complexities of writing some of the more advanced JSF components - particularly dynamic components that fall in the trap mentioned above with the HTML/JSF rendering ordering issue.

I think now we will try and integrate AJAX into our JSF stack so we can create even more dynamic and usable UI.

So I wouldn't stop using JSF - and I would give up if you are finding it difficult as a developer writing JSF components.

My 2c

So I wouldn't stop using JSF - and I would give up if you are finding it difficult as a developer writing JSF components.

I look at it this way-- how many people have created their own components in Swing? I'm not talking about customizing existing components, but starting from the ground up? How about implemented their own JTable? Most developers find solace in being able to extend existing components, even with JSF, and rely on composition to abstract out re-usable pieces ala JSP Tag Files or Facelets.

I'll be honest, when I worked on ui:repeat for Facelets, I was about to cry ;-) But, when I saw it used in a practical app of adding/editing a page full of objects at once, the trade off of initial development is well worth it since now we have a building block to create more interesting/complex things.

oops - as the start of the sentance probably indicates, that was meant to read: "So I wouldn't stop using JSF - and I wouldn't give up if you are finding it difficult as a developer writing JSF components."

Doh! :)