× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



<Okay...  I was just BLIND AS A FRICKIN' BAT...  ie found the original post
from Walden>



I'm trying to stir up both trouble and business (maybe...? somehow...?).
They even have a term for it now...  It's called Gonzo Marketing...

Anyhoo... this is also in reply to Nathan's (Nat's...?!? ;-D) recent reply.


I've been studying the web-publishing aspects for a while...  Now my
understanding of what the industry calls the "holy grail" of all this is the
following:

Seen MANY comments that what's called for is a division of labor, as
mentioned here.  But they describe it as a division between the ***Marketing
Dept.*** and the ***IT Dept.***  IOW, they see coders developing G-AWFUL
user interfaces, and site designers developing G-AWFUL code.  They say:
SOMETHING HAS TO BE DONE...  So the tools vendors are trying to separate
these functions.  (I haven't followed this in past few months, but
Macromedia, Microscrew and other's seemed to be heading in this direction,
AFAIK.)

So I disagree strongly that ANY coders should *necessarily* be involved in
the front-end.


NOT saying that one person can't do the WHOLE ball of wax, anymore than I'd
say one person can't do ALL the functions needed to run an IT shop, using a
400...  Just saying that in larger shops, the marketing guys are doing the
front-end...  Makes sense to me.

jt

| -----Original Message-----
| From: midrange-l-admin@midrange.com
| [mailto:midrange-l-admin@midrange.com]On Behalf Of Ari Samson
| Sent: Friday, December 28, 2001 5:38 PM
| To: 'midrange-l@midrange.com'
| Subject: RE: Web enablement options (previously private)
|
|
| You're just trying to stir up trouble.. or maybe business? <GRIN>
|
| -----Original Message-----
| From: Walden H. Leverich [mailto:WaldenL@TechSoftInc.com]
| Sent: Friday, December 28, 2001 5:34 PM
| To: 'midrange-advisory-request@midrange.com'
| Subject: Web enablement options (previously private)
|
|
| All,
|
| Nathan and I have traded a couple off-list e-mails concerning web
| enablement
| options based on the shoot-out on his site mentioned in a prior midrange-l
| post. With his prior permission I'm bringing this thread back to
| midrange-l
| since we think it may be of interest to other midrange-l'ers.
|
| Nathan,
|
| I'm not very familiar with Net.Data so I can't comment on the comparison,
| but AFAIK there is no "cache" per-se in IIS so ASP pages would always be
| read into memory. Of course, there is the underlying disk cache so it's
| actually unlikely that you'd have a physical read if it was a frequently
| accessed page.
|
| As far as what I use ASP for, that depends on your point of view. I could
| either say "quite a bit" or "as little as possible." Let me explain... I
| have no problem reading data from tables on the AS/400 in ASP via ADO and
| SQL statements (select xxx from yyy where zzz) However, I draw the line at
| any serious business logic or any updates (add/change/delete) of any kind.
| In all those cases we call stored procedures on the AS/400 that
| are actually
| just RPG programs. These stored procedures are called from the ASP.
|
| My ASP programmers are responsible for simple select queries and more
| importantly, making the site look pretty. They needn't concern themselves
| with the details of the business logic or the cross-file updates necessary
| to allocate a rubber-widget from inventory in warehouse 1 for order 2. On
| the flip side, my AS/400 programmers must concern themselves with these
| business-critical operations, but they could care less if the
| customer name
| was in red or green, bold or underlined, in Arial or Times New Roman. All
| those decisions are important, but not to the AS/400 programmer.
| There is a
| severe line between programmers and web designers and it's rare
| that someone
| can cross over that line.
|
| -Walden
|
| ------------
| Walden H Leverich III
| President
| Tech Software
| (516)627-3800 x11
| WaldenL@TechSoftInc.com
| http://www.TechSoftInc.com
|
|
|
| -----Original Message-----
| From: Nathan M. Andelin [mailto:nandelin@relational-data.com]
| Sent: Friday, December 28, 2001 15:59
| To: Walden H. Leverich
| Subject: Re: OS/400 *SAVF - Boats For Sale Table
|
|
| From: "Walden H. Leverich" <WaldenL@TechSoftInc.com>
| > As far as your questions go I've attached the only code involved (it's
| > all ASP, nothing on the AS/400).
|
| Walden,
|
| There's a striking similarity between your ASP file, and the 1st
| version of
| my Net.Data macro.  It used SQL to populate a result set.  I later changed
| it to call an RPG program for performance reasons.  It was an attempt to
| make the Net.Data version look as good as possible.
|
| For simple requests like a report, a scripting solution (like Net.Data and
| ASP) is ideal.  In contrast, my Relational-Web product is designed for
| robust, highly-interactive applications.  Applications with significant
| scope.
|
| I've never worked with ASP, but the performance of Net.Data degrades
| terribly when macros are not in cache.  Net.Data's internal cache is
| limited.  In complex applications macros get swapped in and out memory
| regularly.  CPU utilization goes up dramatically.  Response time suffers.
|
| What do you use ASP for?
|
| Thanks,
|
| Nathan M. Andelin
| www.relational-data.com _______________________________________________



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.