Nathan
It sounds like Walden is the only one defending the corner here, well not
so.
Yes, Walden knows what he is talking about, and so do the rest of we
renegades, who dare to use Microsoft ASP.NET! with the iSeries (AS/400, i5,
System i). It works for me, and in fact it is a fantastic development
environment. Plus it has a superb IDE, Visual Studio or Visual Web Developer
Express 2008, (and yes that is the one provided by Microsoft not MS$, MSFT
etc!).
Try it and get to learn it well before you knock it. As someone else said we
do not seem to spend so much of our time deriding other platforms and
programming languages, simply no need to. As for the nonsense about not
being able to run JavaScript and Ajax function calls when a client side
event occurs, well give us strength.... I suppose you have a monopoly on
this???
Why did I give up RPG programming? (well for business reasons and for
personal expansion)
Maurice O'Prey
-----Original Message-----
From: web400-bounces@xxxxxxxxxxxx [mailto:web400-bounces@xxxxxxxxxxxx] On
Behalf Of Walden H. Leverich
Sent: 30 May 2009 16:40
To: Web Enabling the AS400 / iSeries
Subject: Re: [WEB400] Why ASP.NET gets no Respect
The Web-Forms IDE brings up an editor to insert server-side code -
as though a Web application were the same as a stateful single-user
desktop application - except the nuances of state management may not be
clear, at all.
With the addition of viewstate it's almost stateful :-) Sure, are there
nuances that you should be aware of, yup. But it's programming you need
to know something at some point. It often is as simple as handle the
event and redirect. Here's some production code:
1 protected void cmdUpdate_Click(object sender, EventArgs e)
2 {
3 Option dictionary =
Option.GetOption(OptionList.CustomDictionary);
4 dictionary.OptionDefault = tbDictionary.Text.Replace("\r\n",
"\t");
5 dictionary.Save();
6
7 Response.Redirect("maintainTables.cfm");
8 }
Yes, I know the code, but this is simple enough. Line 3 gets an Option
from the database -- specifically the CustomDictionary option -- line 4
sets the OptionDefault value for that object and line 5 saves it back to
the DB. Line 7 sends the user back to the maintenance page. Simple.
A browser UI event may need to trigger client code - a JavaScript
function.
The event may then need to forward "something" to the server. The
event may
need to update a variable in, or submit something from a different
document in a separate in-line frame. Maybe the event should trigger a
complex set of client actions, followed by a series of AJAX
interactions.
So do those things. There's nothing that stops you have having
javascript handlers on the client. And you don't have to post back to
the server at all. As you say it may be a ajax call or a submission to
another page. The server event handlers are just one option you have.
I meant the Object Browser...
Ah. In the ASP.Net world I don't use that too much, but when building
the business layer it's a great resource. Of course w/intellisense it's
like having the object browser as you type.
-Walden
midrange.com
