To start this blog, I'll simply make some propaganda for Smalltalk and Seaside by referencing an older but still very good article from the On Smalltalk blog. Are you still writing HTML? Oh, you are using embedded ruby code inside your HTML. So you are still doing it the old way then ...
The abstraction and consistency of your code that you get with Seaside and Smalltalk are still the very best I've seen so far. Simply turn your HTML code into Smalltalk, keeping it in the same environment as the remaining parts of your application and profit from all the other strengths Smalltalk offers you.
To be fair, nobody is perfect. Ever looked at how Seaside handles CSS?
style
^ '
#navigation {
padding: 5px;
}
#body {
margin: 5px;
padding: 5px;
}'
Well, surely that's some kind of abstraction, transforming CSS code into a Smalltalk string literal. At least you can now use string composition and maybe regex replacing ... ;-)
Generally, CSS belongs in external files. The ability to include CSS inside a Smalltalk method is just a quick-and-dirty stopgap, not for production.
ReplyDeleteI think it's true that Seaside is intentionally trying to not model CSS, so it can't be blamed for how it handles it. But I'm not so sure that doing so wouldn't have its benefits. After all, CSS is always somehow connected to the generated HTML. The IDs you use in the application code must match the ones in CSS. And what if you want to generate CSS dynamically from within the application? I find it an interesting thought to write my CSS in Smalltalk. But maybe that's too little cause for a CSS implementation in Seaside.
ReplyDelete