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.
posted by Jacob Hookom at
2:24 PM
9 Comments:
the statement with regard to dummy content is not vald. Most component-oriented web frameworks (e.g. Tapestry, Wicket) allow you to put in dummy content for static display, which is ignored when the component is rendered dynamically.
By
Anonymous, at 9:55 AM
of course they do, so does JSF, just because you can, doesn't mean you should convolude your document with meaningless data. that was my point.
By
Jacob Hookom, at 9:57 AM
Yeah, each group will have their own skillsets, but delegating knowledge between the Model and View is a pretty big leap and slows development a bit, when really, the webdesigner should concentrate on supporting the Java developer's use of components/models via external resources such as CSS and JS.
By
Jacob Hookom, at 2:13 PM
HTML is not an external resoure! what framework are you using? forcing programmers to deal with the concept of static, html pages does nothing for what can be done today with component development.
So yes, let the designer develop their 'static' HTML pages for 'viewing' their CSS and JS external resources, but don't drag the programmer into dealing with the designer's HTML documents. It's like forcing the programmer to reverse engineer every page, while dealing with dummy content that's completely unecessary.
By
Jacob Hookom, at 12:04 AM
I highly doubt sites like yahoo and amazon with all of the concerns/logic they must maintain would reduce their architecture to something as typical as you suggest. I would not put yourself in a position of comparing knowledge on web design and development based on some simple cases you've read about in a couple books. In practice, large web-applications (and remember, that's what I'm wrote about in the first place) is much different beast.
By
Jacob Hookom, at 11:44 PM
Jacob, I am a "designer" type: CSS, JS, XHTML, some JSP. CAn you elaborate on your statement: "It's just dumb to use 'jsfc' and 'jwcid'." How can we do Facelets w/o jsfc?
By
Anonymous, at 1:09 PM
just use the literal tags themselves, <h:inputText/> for example which literally represents what you are attempting to do within the context of the document.
By
Jacob Hookom, at 7:16 PM
Yes CSS is a better way to design webpages but you cannot make these assumptions when you design a framework.
"each group will have their own skillsets, but delegating knowledge between the Model and View is a pretty big leap and slows development a bit, when really, the webdesigner should concentrate on supporting the Java developer's use of components/models via external resources such as CSS and JS." This might be true for big companies that have an army of developers and skilled ,web designers. But I doubt very much that this is true in small/medium companies. Also you are designing a framework, the role of CSS shouldn't have anything to do with the design... Let the web designers decide it. And sorry but literal tags suck for web designers.
By
Anonymous, at 4:57 PM
What about rendering a Facelet and giving the output to a designer to work on the stylesheets? If he desperatly needs some more classes or IDs, he can start with adding them to his rendered doc and you can port them back to the Facelet, later.
By
Anonymous, at 7:54 AM
Post a Comment
<< Home