More on Programmer Pages
I've been tossing around a bit on features that I could add to Facelets that would create more separation between the designer and programmer. But then I do days worth of 'soul searching' on the best approach and I keep sticking to my guns, backing off from some of the new designer-friendly features.
The reason is that all visual tools suck. Not even dreamweaver can render a page properly with CSS. So where's the advantage of accomodating those tools?
When we look at web design, or designing applications, the designer's job is to generate the look and feel. This is something that is done early on and is consistent throughout the application. I've written a couple times before on semantic contracts with CSS, they aren't hard to follow at all. The designer does their thing with their tools and viewing files from their local drive with whatever temporary text and and you do you your thing with rich components that use the same ids and class names as the designer used. Simple.
Even take something like Facelets with all of those templating/composition features. They work well for programmers, not for web designers. Their tools and their browser can't view the 'big' picture without a servlet engine and the data to back that process. What they can do is whip up a static html doc to play with CSS styles on the fly.
From designer experience, I will open up dreamweaver-- the html file and the css file and then hit F12 to view the html file in both IE and Mozilla (god knows dreamweaver isn't going to render it properly). Then I just sit there and futz with the CSS file. That same CSS file that would be used with my JSF components in a 'separate' deployment. The more I think about it, the more efficient it sounds, especially if prototyping comes into play.
It's just dumb to use 'jsfc' and 'jwcid'. Those two things would be great if the semantics were the same between html and components, but they aren't. And even if they do parallel, the next concern is that there should be dummy content for the designer to play with, you have to remove it. I say don't even bother with it in the first place and stop expressing concerns within the same document.
The reason is that all visual tools suck. Not even dreamweaver can render a page properly with CSS. So where's the advantage of accomodating those tools?
When we look at web design, or designing applications, the designer's job is to generate the look and feel. This is something that is done early on and is consistent throughout the application. I've written a couple times before on semantic contracts with CSS, they aren't hard to follow at all. The designer does their thing with their tools and viewing files from their local drive with whatever temporary text and and you do you your thing with rich components that use the same ids and class names as the designer used. Simple.
Even take something like Facelets with all of those templating/composition features. They work well for programmers, not for web designers. Their tools and their browser can't view the 'big' picture without a servlet engine and the data to back that process. What they can do is whip up a static html doc to play with CSS styles on the fly.
From designer experience, I will open up dreamweaver-- the html file and the css file and then hit F12 to view the html file in both IE and Mozilla (god knows dreamweaver isn't going to render it properly). Then I just sit there and futz with the CSS file. That same CSS file that would be used with my JSF components in a 'separate' deployment. The more I think about it, the more efficient it sounds, especially if prototyping comes into play.
It's just dumb to use 'jsfc' and 'jwcid'. Those two things would be great if the semantics were the same between html and components, but they aren't. And even if they do parallel, the next concern is that there should be dummy content for the designer to play with, you have to remove it. I say don't even bother with it in the first place and stop expressing concerns within the same document.