rf said:
Desktop stuff is real time. The database is always open and available. You
can query or update the database at will, at any time.
For example, when your user selects one of those projects on the left you
immediately query the database to fill in all the other boxes, without
changing screens. Indeed that single screen "is" the application. There is
no concept of "changing screens".
In most of my apps (that one included) I cache everything in C:\Temp. User
logs on, first thing I do is download all the combo box stuff into a faux
database in C:\Temp.
You would not, for example, update the database as soon as the user chose a
different priority from that dropdown box. You would wait until the user has
entered all the data and made all the choices, right across the form. Only
when the user presses the "submit" button do you action anything. Notice
your current application does not have a submit button. It does not need
one. A web page *does* need one.
That's essentially how that app works. As the user walks the list, we download
the current record's info into that faux database in C:\Temp. If they walk the
list really fast, the current record doesn't get downloaded until they stop
walking.
There's an "Edit" button visible in Browse mode. When that button is clicked,
the screen's fields become editable and the "Edit" button's caption changes to
"Save" - which seems TB the functional equivalent of "submit". In addition,
"Save" is disabled/greyed out until the user types into a field.
The "Close" button also morphs at that time - into "Cancel". Until the user
clicks "Save", they are editing local data. When "Save" is clicked, I
generally just do a total replacement of all values in the parent table's record
(i.e. whether a field is dirty or not...just replace what's there with what was
on the screen).
For child records, I typically maintain an "IsDirty" switche for each child
table that gets set as soon as the user makes a keystroke into a record for that
table. Most of the time for child records if even one field in one record is
changed, I just blow all the child records for that item/table up to the server
and feed them to a stored procedure that, within a transaction, blows away all
the existing records for that item/table and adds what came from the user. For
high-activity situations - where that strategy might grow the DB too much too
fast, I'll go the extra mile and match on a record-by-record basis on the server
side, updating only records that have changed, deleting records that don't exist
anymore, and adding new records.
If you grasp this concept you will see that merely duplicating what you
currently have would be a very difficult task.
In spite of my intuitive feelings to the contrary, I've had two experiences in
support of that statement.
One was a charitable endowment system that I put up for a total bottom-line cost
of less than $75,000. After a few years the company's IT division elected to
rewrite the app from the bottom up as web-centric.
The user liked the UI they had and didn't really want the rewrite - so they
insisted on an almost-identical UI.
When it was all over, IT had spent a little over 3 million dollars trying to
replicate that UI. Not only that, but after some months, the user elected to
abandon the rewritten system because of excessive bugginess....and hire yet
another contractor (this time a team of about 20 people) to do a second rewrite.
So: this would support your observation that desktop apps do not port well.
The better approach is to use a hierarchy, or a tree structure. Your opening
page selects a project and that is all. You drill down to parts of the
project, like "the description part" or the "status" part or the
"participants" part. Each of these parts is a different form or, in web
terms, page.
Sounds like a tabbed screen, just arranged vertically instead of
horizontally...? I've done trees for some situations, but what I like about
tabs is the availability of accelerator keys. Personally, I think there are
"mouse people" and "keyboard people" - and try to make each screen support both.
When you want to change projects you back up (yes, possibly
using the browsers back button) to the opening page. It's a different
paradigm to the normal desktop application you have now.
This seems TB the heart of my problem. I want to show the user as much stuff
as possible at any given time, but it seems like the environment mitigates
against that.
There is of course an exception to this. If you have a controlled
environment (read Microsoft, IIS and all that stuff) then you could explore
.NET. This is designed for this sort of stuff. With .NET (AFAIK I have never
done one, just read about it) the client becomes smart. The client *can*
query the server side database. In fact .NET sort of welds the server and
the client together. This is of course not "web" but "web application".
There are usually no browsers involved. It works sort of like Outlook
operating in server mode. The client (outlook) presents the email to the
user. The email is actually stored on the remote Outlook server
Big can or worms though. Not a trivial exercise.
Remember I said *two* experiences (above)? The second was a bond trading
system that I developed over a period of about five years (a
KISS-with-a-vengence Release 1 delivered in a matter of months, incremental
add-ons thereafter). My total billed hours over the entire five-year period
totalled less than $225,000.
Again, the company's IT decided to rewrite the app over the user's objections.
Some of this was due to the Enron scandals - my system only served one trading
desk and each of the other desks had their own system - or lack thereof.
Management wanted a single system to span all desks so they could better keep an
eye on things.
..NET was the chosen development tool.
That was several years ago. I just finished a 1-year gig with that company as
the subject matter expert on the old system. To date, IT has spent *over* 22
million dollars on the rewrite. Release 1.0 should be delivered in the near
future. The CEO of the whole company now reviews the project's progress on a
regular basis and a few people's careers at the company have gone down the
toilet over this thing.
The world seems to be moving (has moved, actually...) beyond desktop to
web-centric...to the point now where I think a lot of prospective clients just
*assume* that their app will be runable over the web.
On my agenda (somewhere below finding my next gig) is a few months of climbing
the .NET learning curve to a point where I can try to create a RAD template that
will let me put up a simple app (say a parent table, three child tables, dozen
AVT/lookup tables, and a dozen reports) in something less that three times the
manhours it takes me using my current chosen development tool.
Everything I've heard so far, however, seems to make that goal sound less and
less realistic.
With that in mind, I'm thinking maybe PHP and SqlAnywhere are something I should
learn at least enough about to put up a simple application in a RAD timeframe.
