61–70 of 74 posts
I completely agree, may I suggest http://hotwax.infogami.com/HeRF as well? It's maybe not too fancy, but it's very short and simple to deal with. It also ensures correct tag closing without any special effort on your part.
["head", ["title", "HeRF Demo"]],
["body",
["div", {"id": "content"},
["h1", "HeRF - The HTML Rendering Framework"],
["hr"],
If you have to communicate with designers, you have to use templates. And templates are only a mess when people insist in inserting $random_programming_language code in them. If you have a language designed for templates from the ground up, like, for instance, Zope Page Templates, you can have designers editing valid HTML that's also a valid template, comfortably in their editors of choice.
Earlier quoted context omitted.
Certainly there could be a better way, but HTML and CSS are what we have (and frankly they work pretty well considering that the web comprises mostly documents). Emitting HTML from a programming language can be useful, but it doesn't solve the fundamental inelegance of nested markup. Solutions like this are just indirecting the problem, adding another layer of complexity without a meaningful abstraction.
...considering that the web comprises mostly documents... I found this interesting. I've been doing web stuff since 1996, and I would have agreed with you back then. But these days my perception is that the majority of stuff on the web should be considered to be applications rather than documents.
If you have to communicate with designers, you have to use templates. And templates are only a mess when people insist in inserting $random_programming_language code in them. If you have a language designed for templates from the ground up, like, for instance, Zope Page Templates, you can have designers editing valid HTML that's also a valid template, comfortably in their editors of choice.
And what if I'm the developer, designer, all at the same time? Why should I do something more painful?
Earlier quoted context omitted.
Reading over the comments on this thread, it appears that you don't get to generate HTML from code unless you're Avi Bryant. "I am Avi Bryant, your argument is invalid."
Seaside is for building web apps. The continuations make it possible to do the type of apps that would be impossibly difficult in most (maybe all) other web frameworks. On the other hand, it's not really optimized for your typical document-based website. In this case, the generated HTML is integral to the way the whole stack is put together. Even if you disagree with this decision (which indisputably raises the bar f…
Seaside is for building web applications, not web sites. I wrote about this difference sometime back at http://motionobj.com/blog/smalltalk-needs-a-framework-like-r....
But the approach of using code to generate HTML should be applicable for web applications, it just so happens that Seaside is not suitable, state-heavy for one.
The most common argument against code-generated HTML is this makes it hard to work with designers who work with HTML. But as a developer, how often do you change/tweak the HTML after a designer pass you a comp, either in HTML or a PSD? I always do, and I suspect it is the same for almost everyone else. Be it using templates or code-generation, the designer is not going to care, nor is he going to know how to structure the page so that elements can be shared or values substituted effectively. And if he tweaks the CSS, he can't change the HTML without working with the developer anyway, since that will break your code. So it's not like using templates makes the problem go away.
Earlier quoted context omitted.
Seaside is for building web apps. The continuations make it possible to do the type of apps that would be impossibly difficult in most (maybe all) other web frameworks. On the other hand, it's not really optimized for your typical document-based website. In this case, the generated HTML is integral to the way the whole stack is put together. Even if you disagree with this decision (which indisputably raises the bar f…
I thought it helps to expand on this a little. (Feeling relived after 2 days of intense coding...) Seaside is for building web applications, not web sites. I wrote about this difference sometime back at http://motionobj.com/blog/smalltalk-needs-a-framework-like-r... . But the approach of using code to generate HTML should be applicable for web applications, it just so happens that Seaside is not suitable, state-heavy…
As an expert in both web design and programming, I can say that combining the needs of HTML structure for CSS and for template structure is a very subtle balancing act (nevermind the standardista bloggers with one-page sites who have 10-page manifestos on what constitutes a semantic class name). If you have a designer who knows HTML/CSS well, and a developer who knows the back-end well, they will need to have very good communication to arrive at anything approximating an optimal solution.
Now as developers we may intuitively feel more capable of understanding the nuances of CSS than a designer is capable of understanding code, but I think that does a disservice to the web design profession (eg. Eric Meyer knows more nuance of CSS in a very technical sense than almost any web developer ever will). The answer is, as always, "it depends on the individual." I have seen developers quickly get in over their head with CSS because you have to know so many arbitrary implementation and browser details to make it work right.
At the end of the day requiring a back-end to generate your HTML is a heavyweight process that excludes many talented people from the design/mockup process. Even as a developer, I often find it easier to test things out with a static document that run a big software stack and tweak database values to test output. Also, I find HTML wireframes to be much more agile than either paper or Illustrator wireframes. Even in the scenario you describe where the developer has to integrate changes from a designer into a template, I still find it cognitively easier and much less error-prone to see those changes with an HTML template vs markup generated by some other language. And what about when the designer needs to utilize generated markup as a basis for some design tweaks. In that case they need to probably do a lot of whitespace formatting and possible attribute reordering in order to get it to somewhat resemble the markup they originally created.
Of course there is a place for generated HTML, and I think Seaside really magnifies the gains to be found with the right approach, but again, it requires a very different approach from the typical designer/developer team.
Earlier quoted context omitted.
And what if I'm the developer, designer, all at the same time? Why should I do something more painful?
For the day when you will not be able to be the developer _and_ the designer of the application?
I have a day job. I want to build things better/faster/etc with my own time.
I completely agree, may I suggest http://hotwax.infogami.com/HeRF as well? It's maybe not too fancy, but it's very short and simple to deal with. It also ensures correct tag closing without any special effort on your part.
["head", ["title", "HeRF Demo"]], ["body", ["div", {"id": "content"}, ["h1", "HeRF - The HTML Rendering Framework"], ["hr"], This seems almost as painful as writing out html.
(html, (body, (h1, "header one text") ) )
To me it's certainly not as painful as writing out html. I'm still working on it - hope to have a demo soon but its not a high priority, more something to sketch in the notebook when bored.
I have wondered if anyone would be interested in a templating syntax like this and got some response from the python mailing list -enough response to determine it's worth pursuing.
Its for personal projects so the designer seperation isn't a concern - I perfer to be able to generate it by code.
from nagare.namespaces import xhtml
l = ['the', 'mandatory', 'hello', 'world']
h = xhtml.Renderer()
with h.div(id='content'):
with h.ul:
h In both cases, one of the main goal is not to reinvent a new syntax / templating language but to use normal Python with all its power. Also the generated (X)HTML is always well-formed.