[ruby-talk:14979] Re: Ruby and Web Applications

Todd <[e-mail]> writes:

> > Important point for discussion: there seems to be significant interest
> > in using ruby for the web.  Is there a more appropriate place (eg a
> > ruby-web mailing list) for these discussions, or should someone create
> > one?
> I don't know of a better one.  In the meantime, we should move this back
> into the group.  Start a different thread, perhaps, but there's nothing
> we're talking about that wouldn't be beneficial to other users.
> Also, if you trawl around an existing group you'll eventually form a
> different group.
> (and if you do so in response to this msg, plz throw the previous emails
> up there too).

OK, I'll include most of the message.  At least, the bits which are
likely to be of general interest.

> On 10 May 2001, MJ Ray wrote:
> > OK, we're getting to the "how many angels on a pin" level, but I see
> > templating as a mere function of a good app server, rather than an
> > alternative solution.
> I quote from the dictionary:
> tem-plate also tem-plet (tmplt) n.
> "A document or file having a preset format, used as a starting point for a
> particular application so that the format does not have to be recreated
> each time it is used."

It's still not a verb, that one.

> > > : separate data, logic and layout objects.  What's the ruby way here?
> > > data -> RDBMS
> > Up to a point.  We still need to make ruby objects which abstract us
> > away from the horrors of incompatible access methods.
> 'Horrors of incompatible access methods'?
> Are you talking about db porting?
> If you stop thinking of the database as a place to dump serialized 
> garbage, and start thinking of it as the central place where valid data is
> defined, then you'll stop trying to abstract it away.

The problem is that most databases are SQL and we model things as
objects.  It's very useful to abstract it away and have the program do
the translations between a good database model (not just serialised
objects) and our objects.

> > > logic -> stored procs and ruby
> > Stored procs are an internal database integrity measure, not really
> > part of the application logic.  I know they can be, but having app
> > logic split between two places can be a bit harder to follow, IMO.
> Stored procs have nothing to do with integrity.  Triggers and constraints
> handle integrity.  Functions and stored procs exist for the sole purpose
> of application logic.  A mature RDBMS can run the entire application
> inside the DB server.

...but it doesn't make it a desirable thing to do.  My Opinion Only.

> > > layout -> name-your-own-template
> > Yes, but now define the interfaces between them?  The aim is to have
> > collections of data management or layout objects which we can reuse,
> > only creating the app logic each time.
> I am having trouble parsing your last sentence.  Plz try again.

Looking back to my hypothetical model in an earlier message, the parts
of the system which do data management and layout should be reusable,
while we tailor the logic part for each app.

> > What do you see as the problems with the WebObjects model?
> The blind assumption that the DB can be abstracted away and ignored; the
> MFC-style model; multiple layers to lose exceptions in; the obscene size
> and performance costs; slow development loop.
> 
> Each and every one of my complaints is in response to being burned.

Same here.  Most of my opinions have been formed as the results of
"disasters" in web site development projects, even though we usually
found workarounds for them and managed to deploy without major
difficulties.  It's still nicer to have things work Right First Time.

> But my favorite is when I shared a cab home with some strangers, 2
> of which were from WebOjects.  We began arguing about DB
> performance; he contended that you don't want to be exposed to the
> relational model, I contended that the foolish queries that result
> from this approach are horribly slow.  One of the high points was
> when he took the 'more hardware' approach to fix the speed problems:
> "Well, if you run it on an E10k, you should be more than fast enough."
> 
> Great.  With $6,000,000, I can solve all my problems.
> 
> For a while.

-- 
MJR