We are an FSX (Flex/Spring/XFire) shop. With the convergence of Adobe and Macromedia, I am counting on them to continue to improve Flex to where nice looking front-ends are a "given". Already, my client side interfaces look 100 times better under this technology. Recently, we've seen Adobe include within CS3 the ability to build Flex skins that developers can import into their project. Another big plus! What we could really use is a library of templates, as well as a library of icons. I waste more time trying to find the right graphics because our company won't hire a graphic design person. So, the templates and graphics library would help greatly. Beyond all this, a developer can help himself by having an eye for symmetry, proper and consistent spacing, and an eye for color harmony and contrast. He doesn't have to be a graphics design expert to produce some terrific web apps.

It's impractical to expect a designer to become an obect-oriented developer. It's much more practical to teach a developer some basic things that I mentioned above, while enhancing the assets libraries.

R. Grimes

Yes....as an artist first and a developer second (after years of arduous assimilation), we need to create a less fragmented approach to these skill sets that, increasingly, cannot afford to be mutually exclusive. The integration of code and develop-think into the more subjective, more ego-pleasing, but more often than not, less functional world of design has to be part of the new system of instruction in an era where fewer and fewer projects are taking place in traditional settings. We need devigners (great name) and centers of learning which are not biased toward one discipline over the other. Possible? The odds are yes. But where and how to emphasize it? This article was an awesome start.

Well in that case, you just weren't doing it right. It's not hard to create custom tags for your Web designers to use, and if you refuse to use custom tags to access business logic coded in a domain model in Java, then that's not the fault of CF. The worst you could say is that many of the built-in CF tags are oriented towards business logic, and so they might tempt a novice programmer to use them, with tier leakage as the result.

But CF is perfectly fine as a presentation layer for smaller web apps in place of jsps. I think Web designers feel more comfortable with CF's tag-based syntax than they are dealing with scriptlet code. And your team is in control of the design of the custom tags, so they should also be easier for Web designers to use than ones in Struts or JSF.

But for Web apps of more than maybe a couple dozen screens ("pages", that is), I would just go full bore with Spring/MVC, because it offers a lot of support that you don't get writing POJO's and accessing them through custom tags.

rofl, rofl, lol, lol, lol... All CF apps I've worked on have turned into a complete mess that has NOTHING to do with "layered" architecture.
I would say you 1st need to tech CF developers... how to code.

No, we do not need to attempt to teach designers how to code. That would only be necessary if the architecture of the app were done wrong. Layered architectures for web apps have been available to Cold Fusion developers since 1997 through the custom tag interface. Such approaches make it possible for developers to write the business logic while designers focus on creating the UI.