Oh yeah. It's only a superificial similarity. From the Seaside perspective, I think it's most interesting as an irony.
I think I'd like to look at the internals, though. I'm wondering purely for the sake of it if it could be made more Seaside-y. Rails basically does the controller stuff first, bundles up instance vars, and passes them to the view. I can think of some kludgey ways to integrate callbacks, but I don't yet see an elegant one.
If I get REALLY lucky, I'm going to be able to deploy something in Seaside internally, at my current contract. I haven't figured out the best thing to create to make use of this opportunity, though. I'd like to build something in Seaside that couldn't be built in anything else. Definitely still at the "hmmmmmm" stage with that.
Au contraire! I built a time machine and a free energy generator in Seaside today while waiting for "Fear Factor" to come on. Documentation coming soon.
HA good one. But Giles from this post and your comment posts it seems like your subconcious is pushing you towards using seaside more and more. Two questions: 1. is that true? 2. How do you deploy seaside for a 'production' environment? cause I have no idea.
For example my prod rails environmment consists of mongrel clusters and nginx, what special things do you do for seaside?
Also another thing that is surprisingly not coming up in your blog is the growing rebellion to Flex + RubyAMF + rails they achieve this same kind of view utopia that we so desperately are seeking, yet for the most part are still getting shunned. Peter Armstrong who seems to be the lead proponent of this movement has actually got some pretty good ideas and is even got a book! What are your thoughts on that movement?
I definitely want to do more with Seaside. It's just a matter of the right context. I can't just build an app and maybe people will come. I need to have a more specific goal. We were talking about doing some work with Seaside at my last company, and where I am now, if I build something useful with Seaside, people will use it. So it's really just a matter of building something cool at this point. I think I'll probably make something hella Ajaxy with an insane number of callbacks and stuff. (Seaside's support for Ajax works a lot like Rails', but seems a good deal more concise.)
I dunno. I think in terms of functionality and features, anything that can be done in Seaside can be done in a different framework in a different way. I think the key is doing something in Seaside that would be godawfull in another framework, but doing it easily.
@nima:
Check out On Smalltalk. Ramon Leon did some posts a while back on how to deploy and scale Seaside, using Apache. You use pretty much the same techniques and technologies as you would use for RoR to scale it. Both use a similar scheme for serving pages. RoR has its own internal http server. So does Seaside, called Comanche.
@mark - actually RoR ships with a toy server called WEBrick, but doesn't have any internal HTTP. Also WEBrick is kind of semi-deprecated in favor of Mongrel, a better server written in Ruby and C. (Semi-deprecated because I think Rails still ships with WEBrick but defaults to using Mongrel instead, even though Mongrel is a separate package.)
In terms of the whole "could be done in anything, but only fun in Seaside," that's really what I meant.
On Smalltalk is a very good blog. Much more detail on Seaside than you'll find here.
Are you a hacker who likes to make music? You know how you feel precise control when you write code you understand, but you have to filter your understanding of your music through oversimplified GUIs which sometimes have terrible UX? I made a series of videos which teaches you how to write music sequencing software in Node.js and CoffeeScript. When I do it, I experience a clarity which makes it easy for me to make more exciting sounds. You may have the same experience. Upcoming episodes will also teach you how to use simple probabilistic artificial intelligence to write code which writes its own music (which I've already done in Ruby).
I see it handles creating HTML dynamically, but I don't see it handling events. I assume that's still in a controller module?
ReplyDeleteOh yeah. It's only a superificial similarity. From the Seaside perspective, I think it's most interesting as an irony.
ReplyDeleteI think I'd like to look at the internals, though. I'm wondering purely for the sake of it if it could be made more Seaside-y. Rails basically does the controller stuff first, bundles up instance vars, and passes them to the view. I can think of some kludgey ways to integrate callbacks, but I don't yet see an elegant one.
If I get REALLY lucky, I'm going to be able to deploy something in Seaside internally, at my current contract. I haven't figured out the best thing to create to make use of this opportunity, though. I'd like to build something in Seaside that couldn't be built in anything else. Definitely still at the "hmmmmmm" stage with that.
"I'd like to build something in Seaside that couldn't be built in anything else."
ReplyDeleteGood luck with that, since it's pretty much impossible.
Au contraire! I built a time machine and a free energy generator in Seaside today while waiting for "Fear Factor" to come on. Documentation coming soon.
ReplyDeleteHA good one. But Giles from this post and your comment posts it seems like your subconcious is pushing you towards using seaside more and more. Two questions: 1. is that true? 2. How do you deploy seaside for a 'production' environment? cause I have no idea.
ReplyDeleteFor example my prod rails environmment consists of mongrel clusters and nginx, what special things do you do for seaside?
Also another thing that is surprisingly not coming up in your blog is the growing rebellion to Flex + RubyAMF + rails they achieve this same kind of view utopia that we so desperately are seeking, yet for the most part are still getting shunned. Peter Armstrong who seems to be the lead proponent of this movement has actually got some pretty good ideas and is even got a book! What are your thoughts on that movement?
ReplyDeleteThere's two resources for Seaside deployment I know of: Seaside Hosting and GLASS.
ReplyDeleteRubyAMF looks very cool.
I definitely want to do more with Seaside. It's just a matter of the right context. I can't just build an app and maybe people will come. I need to have a more specific goal. We were talking about doing some work with Seaside at my last company, and where I am now, if I build something useful with Seaside, people will use it. So it's really just a matter of building something cool at this point. I think I'll probably make something hella Ajaxy with an insane number of callbacks and stuff. (Seaside's support for Ajax works a lot like Rails', but seems a good deal more concise.)
@nima & giles:
ReplyDeleteI dunno. I think in terms of functionality and features, anything that can be done in Seaside can be done in a different framework in a different way. I think the key is doing something in Seaside that would be godawfull in another framework, but doing it easily.
@nima:
Check out On Smalltalk. Ramon Leon did some posts a while back on how to deploy and scale Seaside, using Apache. You use pretty much the same techniques and technologies as you would use for RoR to scale it. Both use a similar scheme for serving pages. RoR has its own internal http server. So does Seaside, called Comanche.
@mark - actually RoR ships with a toy server called WEBrick, but doesn't have any internal HTTP. Also WEBrick is kind of semi-deprecated in favor of Mongrel, a better server written in Ruby and C. (Semi-deprecated because I think Rails still ships with WEBrick but defaults to using Mongrel instead, even though Mongrel is a separate package.)
ReplyDeleteIn terms of the whole "could be done in anything, but only fun in Seaside," that's really what I meant.
On Smalltalk is a very good blog. Much more detail on Seaside than you'll find here.