On Wed, Sep 1, 2010 at 12:33 AM, Laurent PETIT <laurent.pe...@gmail.com> wrote: > Can you expand your thoughts ?
Sure :) But I just read the link Greg posted about Gulliver and that's pretty much what I was thinking about. Some approaches to generating web apps in some languages / framework lean toward doing it in code - which means designers cannot work on the HTML. Some approaches take the opposite approach and strip everything dynamic out and expect you to apply some external magic to re-integrate the dynamic portions - again the HTML is incomplete and often HTML fragments are generated by code and designers cannot reasonably work with it. The ideal setup, in my opinion, after using all sorts of different web frameworks and languages over the last 14 years, is to have all the HTML in the template - code never generates HTML - and to have *some* markup in the HTML template to allow: * dynamic variable substitution * conditional selection * looping * including other templates (or some sort of 'wrapping' to make layouts with common elements easy to work with) Designers find this easy to work with (as long as you keep the dynamic markup to a minimum). Developers find this easy to work with because they can keep HTML separate from code (and therefore focus on logic in their code). As for the comparison between Enlive and jQuery, the difference is that a) the JS code is 'visible' from the HTML (either inline or directly included) and b) many designers are familiar with JS and consider it part of the whole HTML / CSS / JS ecosphere. Note that wholesale rewriting of HTML on the fly with JS detracts from the ability of designers to work on templates. I guess a question I could ask is: how many people here build large HTML websites with embedded dynamic applications? I was the lead architect for macromedia.com - my team rebuilt it from HTML / BroadVision / Perl to HTML / ColdFusion. When we relaunched it in 2003, it had about a dozen web applications woven into the tens of thousands of HTML pages and during my time on that team it grew to about 50 web applications, some with Flash / Flex front ends. One benefit of CFML is the ability to use a single language within the HTML templates and for all of the backend logic. JSP tag libraries have become pretty sophisticated over the years and are getting closer to what you can do with CFML - but of course using Java on the backend means you lose the benefit of a dynamic scripting language that is compiled on the fly (so when developing you can just edit code then reload the page in your browser). The various dynamic scripting languages that have appeared recently - or at least experienced a surge in popularity - bring that benefit to the table and some of them have added the "minimal logic in HTML template" features to deal with large scale web application development. (and, yes, I'm very aware that there is a lot of terrible CFML code out there - that's the downside of having a web development language that is so easy to learn that non-programmers build large codebases... Visual Basic suffered from the same issue...) -- Sean A Corfield -- (904) 302-SEAN Railo Technologies, Inc. -- http://getrailo.com/ An Architect's View -- http://corfield.org/ "If you're not annoying somebody, you're not really alive." -- Margaret Atwood -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
