some answers - and more questions
Brian Ellsmore
Thank you for your responses, much appreciated. You must have gathered
from my questions just how glued I am to the traditional desktop app
format and my ignorance of webappery. Being aware of the existence of
Java, JS, AJAX, PHP etc isn't going to be good enough for the future, is
it? I need to research and play.
A cursory glance at Java scared me a little! Too much new stuff to cope
with quickly even though it's oop. Google's Web Toolkit obviously helps
but I'd need too much help.
JavaScript, however, looks more like C++ for the web. Much nicer and I
get the feeling that there are a number of IDEs out there which will
help me get a handle on it all.
Q1 - if JS is the way to go what IDE is good to use?
JS also appears to have lots of libraries available; Dojo, Yahoo,
Scriptaculous are ones I've ambled through.
Q2 - any thoughts on these or others?
AJAX is amazing, isn't it? But you knew that! The one thing I use
heavily in my progs is drag-and-drop. I try to avoid picking from lists
whenever possible and I thought (erroneously, it now appears) that
webapps were short on d'n'd.
Q3 - is AJAX so tied to JS that you always get AJAX libs in with JS libs
or do they come separately?
OK, so serverside: ASP is MS, right? Pesumably, therefore, this is no
good for cross-platform implementation.
Q4 - so what else is used that is not native MS but will work on W**dogs?
And finally, the underlying database itself. My own stuff is minimally
relational - it's just a lot of (very big) flat files with sufficient
key fields to allow for looking things up. I simply don't need the
inherent complexity of a RelDB. I therefore do not use SQL anywhere.
Nor, come to that, do I use Oracle, ODBC, ADO, etc.
Q5 - What should I be looking at?
Q6 - where does PHP fit in to all this - if at all?
If you got this far then just let me say how much your words are
appreciated here. Amongst my colleagues I am known to know a lot but *I*
know I don't know as much as I should. I just hope you don't mind
helping me get over these first few hurdles.
Brian
Tom Hoffman
You really want to use one of the new generation of web frameworks
based on a scripting language. These include object-relational
mappers and Javascript libraries, and their design incorporates a lot
of best practices, including testing frameworks.
The key is trying to hit the sweet spot where you're maximizing
development productivity and neither over or under engineering your
code. This is one of the very, very difficult parts of a project like
this.
Look at Rails and Django. If either one of them suit your fancy and
your requirements, use it.
--Tom
SJK
ask in Q3 and Q4.
Java was created using many of the same paradigms as C++, but with
system specific stuff removed. Many C++ programmers still have a
problem moving to Java as I find they write C++ as if it was C. If
you are used to using STL and proper external Object Orientated C++
class libraries, then it makes it easier. If you are used to using
STL, then you obviously haven't been using Visual C++ before version 7
or Visualage for C++ before version 5).
Javascript has nothing to do with Java really, and you can treat it
more like C than C++. It is client side scripting and really helps if
you understand it in the context of manipulating the Document Object
Model of HTML and XML.
AJAX is not a new technology, it simply brings together a number of
older tricks and tools in new ways. It depends on the server
providing XML, loaded by a Javascript call at the client. So when you
do something (including automatic timers in Javascript), you can get
Javascript to download XML data to the client. You've seen news
tickers, and that clever thing Firefox does in the Google search bar
(where it predicts what you are typing), well there are a couple of
other examples. The alternative to doing this is to download all the
possible content at once, which as you can see for the Google search
bar is practically impossible if you want acceptable page load times.
PHP is similar to ASP in that both are ways of noting areas in a html
document that the server must process before sending it back to the
client. The code to alter the page content is written "in-line"
inside the HTML document and replaced by the server. The server
recognises it should parse an HTML doc first by the extension .php
(though you can change that). This can be done in other ways..
generating from an HTML document scratch using a program written in C
was the common way back in the day (cgi-bin).
Packages like Ruby on Rails provide other ways to achieve what you
want, without having to write all the AJAX bits yourself.
Whichever package or technology you use should be defined on:
*) The level of support for the project (number of contributors,
frequency of updates and bug fixes)
*) The maturity of the project (never use beta software for "mission
critical" live projects)
*) How widely deployed it is (an indication of how much demand there
will be for support in future, underused projects die)
*) The quality of the license (is it open enough? Some are less open
than others... see OOXML)
*) The familiarity of the developers with the methodology and the
software development life-cycle of that programming paradigm (with a
proper OO language with well defined interfaces for modules, different
modules can be written simultaneously in isolation).
I haven't given a benchmark for each of those points, as people have
different opinions on them, or what is considered "good". The last
one can be changed with training, there is already enough poorly
designed, undocumented, untested, badly written, and un-maintainable
code out there, we don't need to add more.
Note, I put those in order... test cases should be part of the
functional design, not built from the code design or documentation.
Manuals can be drafted beforehand, and finalised based on the actual
product.
My personal opinion is that the analysis and functional design are
done before you even consider the tools for a job (would you give a
builder some bricks and mortar, and then tell him to replace the roof
of a thatched house). Knowing what is available is good and should
influence your design, but not tie you down (at this point).
Regards,
Simon
(I will now return to lurking the mailing list, but would love to see
an Open, web-based MIS on a GPL3 license).
If you care, I have worked in various jobs covering development,
design, testing, usability analysis, writing documentation, build
management, web hosting, 3rd line application support, 3rd line system
support, on projects as small as 3 people and as large as 400 (for a
single application).
I have seen some of the worst code on the planet (think written in the
1980's, in C, with no documentation, no comments in the code, with
strange nesting, use of GOTO!, embedded system calls in assembler, and
multiple function calls inside conditional statements (like for or
when). I have had the pleasure of working with some excellent
programmers as well.
You may be surprised at the number of large projects in the early
naughties where the only development tools were "C++ in a Nutshell",
vi and a compiler (cheapskates).
Steve Lee
Try to keep in mind the distinction between client (in web browser)
and server ( web server). Both can be scripted for dynamic behaviour
and both work together in various ways. You can even generate the
client code on the server and push it across to be run.
Libraries like Dojo are client side and make the web page dynamic
without necessarily getting more data from the server. Dojo is good
because in has support for ARIA which is the new standard for making
web apps accessible, and that's vital IMHO. JQuery are working on ARIA
support as well. For client side IDEs, Firefox has the venkman
debugger and FireBug is fantastic, letting you edit DOM and code and
CSS in place.
JS is the only common web client scripting language (though there was
some experimental work in Firefox to DOM script with Python). For AJAX
you need to script XMLHTTPRequest object to request data from the
server so is tied to JS as that is the language available (IE supports
VBS too, but I didn't say that ;-)). You can just use JS and
XMLHTTPRequest is available for most browsers, however libraries
simplify the work involved, espec cross browser differences.
Ajax is good for some things but adds alot of complexity and means you
end up duplicating some things the browser does, it also introduces
issues that don't quite fit into the web way. For example if you are
not careful to ensure a unique URL for each important state then
history and shortcuts don't work (which may be what you want).
Serverside: yes ASP is MS only though ASP.NET could potentially run on
the Mono platform, but adding more complexity. PHP is an open equiv to
ASP and runs on most platforms. Both are fairly low level environments
and as Tom say platforms like Rails make life much easier. Drupal is
another but perhaps more a CMS. Django is really a framework for
creating web platforms (confusing I know).
DBs is a big one, ADO and ODBC are ways you access a RDB. Using a RDB
is good for several reasons like enabling new or adhoc querys. SQL is
a powerful language in it self and lets you split data from
presentation without using object layers which are much more a
programming way of doing things. good RDB design requires experience.
Stick to an open data base: SQLite is lean and mean and basically aims
to be a structured replacment to file operations in smaller sites with
lighter concurrency needs, postgreSQL is a full featured RDBMS for
large systems, mySQL fits in the middle and is deservedly popular.
As for what to look at well I'm planning to seriously look at RAILS as
I hear so many good things with respect to productivity. Combined with
Dojo or JQuery it could be ideal. Drupal is the other one on my list
to explore. Look for something mature with an active community. Any of
the above really.
Steve
--
Steve Lee
--
Open Source Assistive Technology Software
web: fullmeasure.co.uk
blog: eduspaces.net/stevelee/weblog