[GLLUG] Best Web/Desktop Programming solution (...)

[Scott Henry Harrison]

Dear Jason: 


I edited the content of your request, and subsequently
chip in my two cents. 

> The IT Department (all 3 of us) slowly migrate 
> away from our Access 2000 platform to web-based and preferably 
> F/OSS.
>  All of our applications will be centered around databases.

have legacy front-end apps to access ... have existing structured 
database... 

> a few caveats [aka necessary features and capabilities]

desktop runtime, web-based platform, nice pretty GUI for designing
forms, making minor changes to add fields, federate programming
from web page design (since only 1 person in 3 person team can program),
connect to various databases (MySQL, MSSQL) and interfaces (ODBC),
LDAP/SSL, be fast 

> Once we choose a solution, we'll be slowly migrating each of our 
> applications from Access to the new system, which means a lot of code 
> rewriting.   Rapid Application Deployment (regardless of it's buzzword 
> status) is somewhat required, hence the GUI IDE requirement.  Some of our 
> current forms are quite complex with multiple tabs, linked child forms, 
> and a lot of Event-driven code.  I realize that we'll have to start coding 
> very differently when going web-based, because a large chunk of the code 
> should run at the server level. That's a big change for us, since all of 
> our code currently runs at the application (Access) level.  Any resources 
> or ideas to ease the migration pain are welcome.

You may need (for the general enterprise-level criteria of
             a reasonably lean, flexibile, and adaptative deployment): 


1) a content management system to
  separate the programming from the web page design 


2) middleware to connect to a wide range of system architecture
  issues 


I recommend three things: #1, Plone (content management system) and
#2 Python (good middleware language). 


Plone works on top of zope which are both driven by python. 


Plone, to me, is like this big robot that you can command.
The "command interface" (web) is not as quick as emacs and
the terminal, but it is reasonably efficient.  Configuration
can take a while, more so ratio-wise than if you built custom components
from the scratch.  The advantage there is that it
focuses the effort on configuring pre-existing parts and
capabilities to realize actual user goals, and bypassing
some of the short-term and long-term costs to a custom-OOP
architecture.  Plus, I think you have a huge upside to
future "rapid application deployments" with a plone-type solution. 


Recommended reading: 


http://www.tundraware.com/Technology/Python-Is-Middleware/Python-Is-Middlewa 
re.html
http://diveintopython.org/
http://docs.neuroinf.de/PloneBook 


That said, for both quality and speed of deployment,
#3 would be another programmer
(pair programming)
http://www.extremeprogramming.org/rules/pair.html
or maybe
look for some of the dynamo plone consultants out there...once you
are further along assessing strategy, you may find
a way to pay less and get more done quickly... unless
it is somehow profitable to be slow. 


My overall general thinking to your self-described vague request: 


The situation you describe sounds like a real
gamble...considered separately from the actual platform and
applications you commit to (like plone and python,
or any of the other 80+ webplatform/CMS/middleware
solutions out there).  With just 1 programmer with
some level of inexperience for this particular mission-critical
task, I think your organization is putting all its eggs in
a very slow basket on a potentially rough road.  While
going slow can alleviate some of the tumbles, I would think
it's disappointing to wake up and look at, however slowly developed,
a big steaming mass of perl code... did I say that?
I mean, any situation where a lot of architectural value may have been
lost. 


Admitting some of my own inexperience, if there is a more turn-key
(.NET/JavaUltraMegaBeanVersion8.2/AdobeDoIt...or something)
proprietary solution out there, or php, or other approaches,
others may know better than I (and I'd be darn interested to
hear about those solutions). 


Regards,
Scott