<div class="gmail_quote">On Sat, Mar 29, 2008 at 9:26 PM, Colin Putney &lt;<a href="mailto:cputney@wiresong.ca" target="_blank">cputney@wiresong.ca</a>&gt; wrote:<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
That&#39;s what people mean when they say the writing web apps in Seaside<br>

is &quot;easy.&quot; They mean that it&#39;s a whole lot less work than is usual<br>
with web apps, not that they don&#39;t have to understand the web.</blockquote><div><br></div><div>Thank You! &nbsp;That would explain why over a week ago I wrote &quot;<span class="Apple-style-span" style="border-collapse: collapse; ">I felt like I HAD to understand web programming and HTML just to make it work...&quot;</span></div>
<div><span class="Apple-style-span" style="border-collapse: collapse;"><br class="webkit-block-placeholder"></span></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If anything, writing Seaside apps is conceptually harder than<br>
&quot;traditional&quot; web frameworks, because you have to understand not only<br>
the web, but the conventions that Seaside uses and how to get the most<br>
out of them. </blockquote><div><br class="webkit-block-placeholder"></div><div>Combine that with just trying to learn Smalltalk and no web experience...</div><div>&nbsp;</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The nice thing is that, once you&#39;ve got all that under<br>
your belt, you rarely have to think about it any more.</blockquote><div><br class="webkit-block-placeholder"></div><div>True with just about any set of tools!</div><div><br class="webkit-block-placeholder"></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Rob, what is it that you want to accomplish? Perhaps Seaside isn&#39;t the<br>
right tool for the job.</blockquote><div><br class="webkit-block-placeholder"></div><div>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. &nbsp;Hospitals have to report many &quot;measures&quot; to many agencies--government, insurance, watchdog, you name it. &nbsp;Many of these measures are &quot;almost the same,&quot; but &quot;just a little bit different&quot; (subclasses). &nbsp;All the lists are based on patient populations obtained be constantly changing sets of rules which are in turn based on medical records coding.</div>
<div><br class="webkit-block-placeholder"></div><div>Some of the data we need is actually stored (somewhere) in various databases. &nbsp;Some measures need data from 2 or more systems combined just to produce one piece of information. &nbsp;Almost all of them need additional information that, for now, is only obtainable by hand.</div>
<div><br class="webkit-block-placeholder"></div><div>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. &nbsp;These NEED to be living objects.</div>
<div><br class="webkit-block-placeholder"></div><div>We settled on a web app, while not ABSOLUTELY necessary, for many reasons, but the primary one is that we have very &quot;non-technical&quot; people that get confused by something &quot;different,&quot; and they are currently comfortably using many web-based tools.</div>
<div><br class="webkit-block-placeholder"></div><div>Anyway, I am in the beginning stages of connecting to various data sources, creating patient &quot;work lists,&quot; and obtaining the data that IS available. &nbsp;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 &quot;passed&quot; or &quot;failed&quot; the measure.</div>
<div><br class="webkit-block-placeholder"></div><div>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. &nbsp;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. &nbsp;They would like to turn the screen turn red or whatever to point out potential errors and so on.</div>
<div><br class="webkit-block-placeholder"></div><div>So, with Aida I can quickly get text boxes and lists and calanders and buttons and so on up on the screen. &nbsp;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. &nbsp;All of which needs to give them direct feedback, such as disabling, enabling, or even creating new fields and further changing the rules.</div>
<div><br class="webkit-block-placeholder"></div><div>And then there are those pesky constantly changing rules. &nbsp;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. &nbsp;Again, Magritte seemed a good candidate for that. &nbsp;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.</div>
<div><br class="webkit-block-placeholder"></div><div>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. &nbsp;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. &nbsp;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.</div>
<div><br class="webkit-block-placeholder"></div><div>Other than that, I don&#39;t need &quot;pretty.&quot; &nbsp;Pretty can come later! &nbsp;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. &nbsp;I can enforce the same browser and so one so I don&#39;t have to worry a lot about styles and so on.</div>
<div><br class="webkit-block-placeholder"></div><div>This all seems VERY do-able with the tools that are available today. &nbsp;The changes are just piling up and we will start getting paid less or not at all for things that we either don&#39;t report, or do poorly on, so I don&#39;t want to be floundering to keep up with them!</div>
<div><br class="webkit-block-placeholder"></div><div>Thanks again for your explanation. &nbsp;It was exactly what I was looking for!</div><div><br class="webkit-block-placeholder"></div><div>Rob</div></div>