Re: Ruby on Rails?

Mont Rothstein <[email protected]> Fri, 28 Oct 2005 12:57:52 -0700
Newsgroups gmane.comp.web.webobjects.general
Message-ID <[email protected]>
Andreas,

Thank you for the response. That helps me to understand things better.

Just to be clear, I wasn't looking for EOF in Rails, it was just a point of
reference.

Based on your response I'd like to make a statement and see if others agree
or if I am missing something.

It sound like Rails is *primarily* targeted at stateless applications. Those
that do not maintain application state in memory between separate
request/response transactions. I am not saying that it can't be used for
state-full applications, just that stateless is the most common type of
application, and therefore the direction that the various support tools and
frameworks help most with.

Do those who are familiar with Rails agree with this statement?

Thanks
-Mont


On 10/28/05, Andreas Korth <[email protected]> wrote:
>
> Hi Mont,
>
> > My main concern with regards to RoR pertains to the EOF side of things.
> >
> > Some of the EOF features I depend on are:
> >
> > - Peer editing contexts. I use an EC for each page so that if the user
> > abandons changes they are not accidentally saved when they do
> > something on
> > another page. This also is necessary for fully integarating unsaved
> > objects
> > into the object graph.
>
> Rails does not have anything that comes close to EOF's editing context.
> As a consequence, you'll miss many features and conveniences of EOF,
> like peer editing contexts, in Rails. ActiveRecord is rather
> lightweight, but has other nice features and a small memory footprint,
> on the other hand.
>
> After all, EOEditingContext is a (rather sophisticated) implementation
> of the Unit Of Work pattern.
> (http://www.martinfowler.com/eaaCatalog/unitOfWork.html) If you need a
> transaction to span multiple pages/requests, you can use a
> implementation of this pattern, that suits your needs.
>
> > - Automatic many-to-many join table management
>
> You can even put additional attributes (e.g. for sort ordering) in a
> join table.
>
> > - Snapshoting, I am not a fan of state-less applications
>
> Not sure what you mean by snapshoting in conjunction with application
> state. ActiveRecord does not keep row-level snapshots in memory like
> EOF. If you need to retain objects in memory across requests, you would
> store them in the session.
>
> > - EOQualifier, I use this heavily for our report builder
>
> You can't compare EOF and ActiveRecord one-to-one. There are many ways
> to qualify queries in AR, but nothing that resembles EOQualifier.
>
> > - Temporary global IDs for for fully integrating unsaved objects into
> > the
> > object graph. You need something in place of the PK.
>
> You don't need PKs to build an object graph in memory. An ActiveRecord
> has an ID if it was saved to the database, otherwise not. Your object
> graph doesn't care.
>
> > - Faults, for efficiency in both the application and development.
>
> Check.
>
> > Can anyone that has used RoR/Active Record tell me if any/all of these
> > specific pieces of EOF exist in RoR?
>
> Don't go looking for EOF in ActiveRecord feature-wise. It's a different
> approach to the same problem. If you build an application with Rails
> and ActiveRecord, you'll do it differently from the beginning. Don't
> think EOF, think ActiveRecord. I know this is hard if you're accustomed
> to EOF, but Rails gives you other joys that compensate for this lack of
> features.
>
> HTH
> Andreas
>
>