Eric Hodel drbrain@segment7.net skrev den Wed, 10 Sep 2003 14:19:52 -0700:
Well, once you add Borges, you’ll not need amrita or fastcgi…
But then your code will not be separated from the skin/presentation, eh?
This seems to me to be one of the strengths of the amrita approach.
Not that I’m an expert in any of them (just checked them out) but from
a cursory look at borges the tight coupling between logic and presentation
stands out as annoying. Is this something that is being adressed or is
the tight coupling a “feature”?
Borges promotes heavy use of CSS, and tight coupling is a “feature”. In
Borges, you write web apps more like GUI apps. Instead of spitting out
HTML, you connect Components (or widgets). It is much different
than traditional web app development.
More q’s on borges:
Can it not be a performance issue that you regenerate the html
from scratch in each component? At least that was my impression
from the few borges examples? I guess you can avoid that by using
a different (template-based) renderer though. But this is probably
premature optimization on my part anyway… 
Yes, it may be a performance hit, but its hard to say whether or not it
will be dwarfed by all the behind-the-scenes magic with Continuations.
Seaside2 has no template system, and nobody there really complains
(well, there’s one guy who’s writing a template based system). A
majority of the Seaside2 developers do not use templating systems, but
there is a facility for sticking pre-generated chunks of HTML into the
code.
Do you have any larger examples showing the strength of the
borges approach? It is theoretically appealing and sort of
feels right but since its a different framework
than the predominant ones (sessions)
There’s Webplayer, but it isn’t as clean an app as it should be. It
does show the general idea and power of the approach. Webplayer is a
browser-controlled mp3 player with rudimentary playlist support.
I think you need to
really write it on our noses for us to get it :). Does
it give real advantages in real use? What are the downsides? Problematic
to disallow the back-button in situations where it shouldn’t be allowed?
The major advantage is that sessions are transparent. You only
need to identify which data needs its state held. The downside is that
it will be slower and larger (memory footprint) than a CGI-based
solution. Code may be smaller and simpler.
The back button never needs to be disabled, but backtracking can be
forbidden for things like shopping carts (not yet implemented).
Why don’t we take some more complex web app (phpbb2?) and rewrite
it in borges w. webrick? We can even “borrow” their themes and templates so
its really “only” the code/php that we need to redo in
ruby.
Wait until after RubyConf, I’ll have a much better framework written by
then.
···
Robert Feldt (feldt@ce.chalmers.se) wrote:
–
Eric Hodel - drbrain@segment7.net - http://segment7.net
All messages signed with fingerprint:
FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04
(I suppose we could call ours RuBrick).