Will the CTOs go for it?

Question

Please excuse the non technical nature of this topic... But quite a few of us are dependent upon currently established web development processes that have been in place for a while and our creative talents are limited by such folks as product managers and the like that have usually pulled the graphical artists under their wing for developing "click throughs" and JPG screen images as needed for the dog and pony shows du jour.
This has created a whole class of graphical artists that generate markup. And usually this markup is the "deliverable" to the code hacks like myself. For instance, on the first development effort where I had the honor of using struts, I was not allowed to use the taglibs. Why? Because the "look-and-feel" was embedded way down at the HTML level by the artists and it was easier to just pull the static html pages into a jsp file and dynamitise(sp) using plain java.
For this reason, i believe that for web development tools to advance smoothly, all teams involved with the development process have to be addressed.
So what is my point?
I feel that JSF may be taking too much of a baby step toward becoming mainstream. I see a day when the JPEG ( or whatever ) artistic design proofs can be directly generated from a layout manager that can also be used to generate the JSP content. But with the current JSF spec, the magic 8 ball says "reply hazy, try again later". I'm afraid that by the time this is available, XFORMS (http://bugzilla.mozilla.org/show_bug.cgi?id=97806) will be the dominant markup. (OK, this was a cheesy cut... but it was supposed to mean sometime in the distant future.)
The sort of thing that I can see useful is a photopaint (pardon the reference to Corel) sort of tool where the "objects" can be nested on top of each other to make panes (think tiles) that are composed of the sort of components currently described in the JSF spec. This tool can be used both by the artists and... well... the rest of us.
...So in the end, the back-enders are happy, the front-enders (including the artists) are happy, the product managers and marketing types have the materials they need. Everyone does their job efficiently and subsequently the CTO is happy (and decides to --M$).
-Tony

Answer 1

This has created a whole class of graphical artists
that generate markup. And usually this markup is the
"deliverable" to the code hacks like myself.
For this reason, i believe that for web development
tools to advance smoothly, all teams involved with the
development process have to be addressed.
So what is my point?
I feel that JSF may be taking too much of a baby step
toward becoming mainstream. I see a day when the JPEG
( or whatever ) artistic design proofs can be directly
generated from a layout manager that can also be used
to generate the JSP content. But with the current JSF
spec, the magic 8 ball says "reply hazy, try again
later". I'm not sure I get exactly what you want to see, or what your beef with JSF is, but if you're under the impression that JSF is only usable with JSP, let's clear that up.
JSF offers an API that you can use to programatically configure UI components, handle events, etc. and decouples the rendering from the components (through RenderKits) so that the JSF UI components can be used with a number of different rendering technologies; JSP is only one of them, included in the spec because it's believed it will become a popular one.
But you should also be able to use JSF components in frameworks similar to Barracuda and Tapestry, i.e. with clean HTML files as "templates" that a "graphical artist" can develop in any standard HTML tool, and separate Java classes (and/or XML configuration files) that configure the UI components through the API. This set up gives you complete separation of HTML (or whatever ML you use) and the presentation logic, with no need for special tags in the template files.