You've all heard the one about the farm worker who was once asked for
directions... he replied, "Well if I was you, I would'nt start from
here".

If you weren't by now committed to a particular path for web
development and deployment and could start with a clean slate... and
wanted to cater for *any* web-server and *any* browser... would you go
for xForms? or RAILS? or AJAX? or... what?

Mike.

michael (AT) preece (DOT) net wrote:

You hit me where I'm living right now. I did considerable research of
the reading variety and less of the hands-on variety, looking at xforms
and ruby on rails (you can do php "on rails" ish now too) as well as
Java with struts and Java Server Faces and plenty of others. I have not
settled on the server side as yet (coming down to PHP & Java, I've
eliminated Ruby and Python for now), but on the front end, I'm jumping
into AJAX (and Web 2.0) and not looking back. I did a talk on AJAX at
a conference a couple of weeks ago and had a bunch of people tell me
that it was a great talk and that I must be very smart. So, even if
the technology doesn't work for me, people will think I'm smart ;-)

As for AJAX - I have done written/cloned code to create the
XMLHTTPRequest object and it is clear to me that I want to use a
pre-packaged framework for that. I researched current options and
selected prototype.js (the same one that the Ruby on Rails folks built
into that) and might use the rico.js (openrico.org) library too (which
makes use of prototype.js). There are a ton of other options these
days, but prototype.js seems solid. I'm scheduled to attempt to use it
for the first time tomorrow by 5:00. Once I have an example, I'll post
it to my web site.

--dawn

So it all comes down to HTML & Javascript still?

Mike.

michael (AT) preece (DOT) net wrote:
God. Shoot me now, please! <g>

Luke

To answer your question, if I could do it all over again I'd probably
have spent more time focused on LAMP (Linux Apache MySQL and Perl
and/or PHP), with very little focus on anything else.

michael (AT) preece (DOT) net wrote:
You sort of stacked the deck when you asked people what they'd use
that was supported on *any* web server and *any* web browser. That
narrows down the options considerably. I hate to say it but most of
the technologies we're working with these days are just regurgitations
of the same ol' stuff - yes, HTML and JavaScript. If you want to
appeal to the least common denominator then you have to go back to the
oldest and most basic languages/technologies.

The question is sort of bent in the wrong direction, if I may say so.
I think it's better to approach these things from the view of business
needs rather than "let's find the most generic technology, get really
good at it, and see what needs we can apply it to". I think the
question needs to be more diversified, at least along the lines of
what technologies are most appropriate for Intranet, Extranet, and
then Internet. We might find the answers different for each. And
rather than saying [sic] "if you had to do it all over again, what
would you use that's completely platform independent", you might want
to ask IF that's what people would actually do : Is complete platform
independence really still a goal for some people, or have some people
decided that they prefer something that's less "one size fits all" and
more "this size may not fit me but it fits my target audience"?

Looking at the web development market at large, I've sort of thrown my
hands up within the last year or two. There are almost more people
writing new standards now than there are people using the old ones. I
haven't adopted .NET as a preferred technology necessarily because I
think it's superior to anything else - I'm just tired of chasing Perl
and PHP and now Ruby; Rails and AJAX; IIS, Apache and Tomcat; Mozilla,
Opera, and Firefox, and Jabber and whatever else seems to be hot this
week. I love sinking my teeth into technology but enough is enough
and it's time to get some work done. So I'm not chasing the open
source project/protocol of the week, but I _am_ settling down with
something that is well documented and well supported.

(The following doesn't apply to people like Dawn or Mike, but more to
others who are trying to follow these discussions and aren't quite
sure of which way the wind is blowing.)
It's funny that in this MV market of ours, almost by definition a
group that resists change, that we have so many people chasing so many
different technologies - and it seems people never seem to find one
that they like. This is where I say just pick one, right or wrong,
and run with it. You can do whatever you need with pretty much
anything that's out there - if you're really good at using it. Let's
stop chasing technology and actually use it for a change.

T

(Just ignore this man, he needs a long vacation...)

Hi Mike,

When you say "web development" do you mean front end development for an
existing pick database?

LAMP will not help you here - the M stands for MySQL. (I guess you
could call it LAPP.)

Has anyone done any MV integration with rails? I've not used it but
from what I understand it uses SQL to build the persistence layer.
(Shoot me down if I'm wrong.)

Dave P.

davpat00 (AT) hotmail (DOT) com wrote:
That was not specified. FWIW, I for one would prefer to do web
development with a SQL database than with MV.

You're almost certainly right.

Luke

michael (AT) preece (DOT) net wrote:

'fraid so. Once I understood why that was, I decided to stop
resisting. Here's my take on it.


The JSP, ASP, PHP, etc Approach
I looked at LAMP (linux-apache-mysql-php), ruby on rails,
java/jsp/struts, and java server faces in my first round. I did
hands-on with all but ruby, doing the basics in each to feel like I
"got it" without actually learning more php than required, for example.

Each of these used the same philosophy of not only hosting any
source/byte/object code on the server, but the run-time environment for
each of them too. The user visits a site and a request goes to the
server which then interprets the php (or whatever) and pushes html to
the client. The client then gets/posts data based on a client-side
event (e.g. user clicks submit button) and all logic to validate and
process this event is handled again, running on the server, with the
php code, pushing back another html document. These must always be
complete documents. This seems like a great environment for the
developer -- everything is coded and run on the web server, pushing
stuff to the browser and making requests of the database.

PHP etc with AJAX
Since each of these is now adding AJAX support, they are adding what is
required to run something on the server (e.g. php) that then pushes
javascript, along with xhtml to the client, which then executes the
javascript on the client doing the asynch call to the server (e.g. php)
to then pull the response back in. This is almost the worst of all
worlds from my perspective and I would only entertain it if I had a
huge asset of such code already. The casserole of php, javascript,
xhtml, and css often jumbled together in a single page doesn't taste
right to me at all. (Not to mention that they often also include SQL
calls).

Browser *User Exits*
I don't know how widely people know the term "user exits" but everyone
knows the concept -- an application (web browser in this case) is going
to run and developers have various points, such as before loading a
page, where they can put their own code that will blend with the
application. That is where JavaScript comes in. You can write user
exits for various user events, such as mouseover or clicking anywhere.
Once you see that javascript is the language of the web browser and we
are not getting anything else anytime soon (nothing on the horizon even
when I put on my high power binoculars) you can see that resistance to
javascript is futile.

Why No Other Language?
It might be easy enough for a single vendor to supply another language
in the future for user exits, but I don't see much chance of another
standard soon that the browser vendors sort-of attempt to follow. The
JavaScript standard is handled by ECMA and officially called
ECMAScript. Microsoft, Mozilla, Safari, Opera all care what is in that
standard. Some IDEs will generate JavaScript from other specifications
so that not every developer will feel a need to learn the language, but
then you have to debug it anyway, so I'm biting the bullet and am
going to learn it instead.

What you can do with JavaScript that you cannot do otherwise -- lots!
See http://www.brainjar.com/dhtml/windows/demo.html
I have a ton of other URLS, but this one helps explain why AJAX would
gain in popularity due to its use of JavaScript along with the asynch
server calls.

AJAX approach
With AJAX, the user requests a page which then goes to the server just
like the old days before asp/php/jsp. The html includes scripts and
stylesheet information or, better yet, links to script files and
stylesheet files. The html indicates where there is additional
javascript code to go with any event. At those points in the user
interaction, the javascript executes and ships asynch requests to the
server as needed. The server returns xml, such as fragments of html,
that the javascript listens for without holding up the user and
incorporates the responses back into the page.

An example of how the asynchronous server communication works for the
user, try not to get addicted like I am to
http://weboggle.shackworks.com

Instead of calling these BUIs, I often see them called RIAs -- Rich
Internet Applications where a single web page is turned into a full
software application.

Sorry for the length, but hope this helps. --dawn

In some markets this is a requirement if we are to do our jobs
properly.

Or CSS and javaScript - and javaScript only if you need fancy browser
tricks. I must say that javaScript support has come along pretty nicely
in the last few years.

<snip>

May I suggest less focus on the buzz words and more on the technology?
I have been happily using (chasing???) PHP since it was PHP/FI (ca.
1997). It has grown rapidly but in very predictable ways that have
always supported backward compatibility.

A slightly OT observation on this: Everyone thinks that AJAX is some
magickal, complex system most likely because most demo's and
discussions relate to complex tasks. Take a look here:

http://rajshekhar.net/blog/archives/...-Tutorial.html

Oops, there I go again, the original article was written by the author
of PHP. But any server side processing can be used instead of PHP - try
MVWWW if you don't like PHP.

This will be opening me up to accusations that I think that PHP is the
answer to every question but take a look at the PHP web site
(http://www.php.net/) for an example of what IMHO is one of the best
web presentations going. Part of this presentation is PHP's excellent
documentation - with user supplied notes. Clean design, accessable and
useful.

OK, I may need a vacation as well but: I have been thinking for some
time about trying to make the time to write up a little introduction to
PHP for PICK programmers (the language is conceptually very similar to
PICK/BASIC). I will try to do this to illustrate intutively accessable
tools and techniques with which people can approach these tasks.
-Tom

Hi Dawn,

Sorry in advance for top posting this but I have only one question and
didn't want it to be buried:

Can you explain exactly the difference between 'PHP etc with AJAX' and
'AJAX approach'? Seems you prefer the latter. Why?

TIA,
-Tom

dawn wrote: