[Seaside] Seaside vs. Traditional

[Rob Rothwell]

On Sat, Mar 29, 2008 at 9:26 PM, Colin Putney <cputney at wiresong.ca> wrote:

> That's what people mean when they say the writing web apps in Seaside
> is "easy." They mean that it's a whole lot less work than is usual
> with web apps, not that they don't have to understand the web.


Thank You!  That would explain why over a week ago I wrote "I felt like I
HAD to understand web programming and HTML just to make it work..."

If anything, writing Seaside apps is conceptually harder than
> "traditional" web frameworks, because you have to understand not only
> the web, but the conventions that Seaside uses and how to get the most
> out of them.


Combine that with just trying to learn Smalltalk and no web experience...


> The nice thing is that, once you've got all that under
> your belt, you rarely have to think about it any more.


True with just about any set of tools!

Rob, what is it that you want to accomplish? Perhaps Seaside isn't the
> right tool for the job.


Well, work in a small (200 bed) community hospital that is just sinking
under the weight of manual data abstraction from real, live, paper medical
records.  Hospitals have to report many "measures" to many
agencies--government, insurance, watchdog, you name it.  Many of these
measures are "almost the same," but "just a little bit different"
(subclasses).  All the lists are based on patient populations obtained be
constantly changing sets of rules which are in turn based on medical records
coding.

Some of the data we need is actually stored (somewhere) in various
databases.  Some measures need data from 2 or more systems combined just to
produce one piece of information.  Almost all of them need additional
information that, for now, is only obtainable by hand.

I settled on Smalltalk because I tried it with traditional Microsoft tools
that were available to me, but I needed to be able to make changes easier
because change is constant and not definable by rules in a configuration
table somewhere.  These NEED to be living objects.

We settled on a web app, while not ABSOLUTELY necessary, for many reasons,
but the primary one is that we have very "non-technical" people that get
confused by something "different," and they are currently comfortably using
many web-based tools.

Anyway, I am in the beginning stages of connecting to various data sources,
creating patient "work lists," and obtaining the data that IS available.
 Then, I need to be able provide these lists to multiple users to review,
make manual changes if necessary (they often override the electronic data
with manual data based on their abstraction rules), and then run the data
through the various business logic rules to determine if the patient
"passed" or "failed" the measure.

It was Magritte that initially attracted me to Seaside since they already
worked together, because I thought you could probably do some very nice
multi-field validation thing to apply the business logic and give feedback
to the user.  For example, if they enter a certain type of antibiotic AND
the time it took to discontinue it was more than 2 hours AND the moon is
full...you get the idea.  They would like to turn the screen turn red or
whatever to point out potential errors and so on.

So, with Aida I can quickly get text boxes and lists and calanders and
buttons and so on up on the screen.  But there IS a need for some heavy
interaction between what they are entering and the various rules that apply
to various types of patients under various circumstances.  All of which
needs to give them direct feedback, such as disabling, enabling, or even
creating new fields and further changing the rules.

And then there are those pesky constantly changing rules.  In a perfect
world, I would like to let the users add and remove data points and change
the logic as the rules change, because we only have myself and one other
person [right now] who will possibly ever understand what the users know
deeply from doing it all the time.  Again, Magritte seemed a good candidate
for that.  We even pictured being able to read in the various documents from
different vendors describing the rule changes and automatically make at
least some of the changes, but that is definitely a future dream.

So you see, I was trying to keep the logic of interacting with the input
fields and updating the display from turning all spaghetti-ish on me like it
would if I worked like I always have, and the descriptions of Seaside and
Magritte seemed to fit the bill.  Aida has been a snap to get a patient list
on the screen and pull up an individual patient with nicely tabbed views of
various portions of the data, but I am concerned about my ability to keep
the Model-View interaction clean enought to be bug-free as the rules change.
 I know that much of that work is actually in the Model, but, again, the
Meta-Description capability of Magritte seemed like it could handle this
very nicely.

Other than that, I don't need "pretty."  Pretty can come later!  I need
basic field input, dropdowns, radio and check boxes, a few graphics to show
them that their lists have changed since the last time they were there
because the underlying data changed, that sort of thing.  I can enforce the
same browser and so one so I don't have to worry a lot about styles and so
on.

This all seems VERY do-able with the tools that are available today.  The
changes are just piling up and we will start getting paid less or not at all
for things that we either don't report, or do poorly on, so I don't want to
be floundering to keep up with them!

Thanks again for your explanation.  It was exactly what I was looking for!

Rob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/seaside/attachments/20080329/03890613/attachment-0001.htm