Re: rubyonrails and cgikit comparison

In my mind, indirection = encapsulation in this case, with a complexity 
vs. flexibility tradeoff. That can be beneficial to even a simple 
programmer doing both jobs (programmer, HTML designer). Indirection is a 
basic form of interface helping drive low coupling and high cohesion (or 
it's over-designed OO making the code extendable and maintainable if you 
ever manage to figure it out :) )

For instance (please excuse the trivial example),  if using a library 
that provides addresses, and you have

@invoice.date

and you now want European date formating. In a large date driven 
application, you would may have 30 @invoice.date's. With a binding 
between presentation and application logic, you only have 1.

Considering how much handler code must be written for a given page 
anyhow, it doesn't seem too awkward to me to have all insertions via 
indirect bindings. I suppose on the other hand, you may have designed a 
very good library/application with other "cut points" a layer up, making 
this very redundant, and thus needless indirection. Or, the programmer 
is a good instinctive programmer and naturally refactor volatile logic 
into appropriate helpers. 

Now that I've said, it occurs to me that my thinking may be too 
interface-centric from my C++ and Java experience, and Ruby's duck 
typing more naturally allows for other "cut points" by virtue of easy 
creation of proxy objects in other parts of the UI (actually, thinking 
about this now, this does seem very likely). So, maybe some of the 
"traditional" thinking about web frameworks maybe goes out the  window.

I do like the idea of the template language being ruby. It would be 
interesting if a setting could force template code to be a specific 
subset of ruby- e.g. more forcably conditional and application logic out 
of the html. A recent ruby-talk post referenced a Paul Grahm Lisp 
article where he hypothesized about the possibility of Lisp being good 
for solitary hackers, and Java for "pack" programming -aka larger teams, 
where cumbersome explicit types and interfaces are necessary for the 
team to maintain the "theory" of how the app should be structured, 
extended and integrated. This concept would weight heavily on templating 
approaches, I think. Maybe an arbitrary templating language that is 
seperate from the application logic language is an essential feature of 
web app platforms in the context of "pack" dynamics?

Regards,
Nick

Florian Weber wrote:
....

> but like i said, what do you gain by the indirection if the ruby and the
> html programmer are the same person?
>
>