Joe,
I don't know if you've been looking at my questions on here but what's your
opinion:
Well, I'm at a cross-roads, and, generally, I like to move forward. So what
language do you suggest for building web apps as rapidly as possible but in a
language with a good solid extensible architecture, decent tools for
development, accesses DB2/400 in a high-performance way, using stored
procedures or straight calls and doesn't use ODBC? Or is there such a thing
for the i5?
Since I have WebSphere on our i5, it seems as though I might be somewhat set up
to do Java which is what I perceive a your favorite Web language. If I'm
correct in my assumption about Java, how's the fastest, bestest way to get
started and do some RAD in a testing environment first.
Thanks,
Dave
"Joe Pluta" <joepluta@xxxxxxxxxxxxxxxxx> 6/6/2007 06:08 >>>
From: albartell
I told myself I wouldn't respond, but you draw me out :-)
I could say the same thing <smile>. And I've tried to pull back a little to
keep the conversation on a more civil note (and not to flood the list; I
know people get tired of it <grin>).
Just so I can fully understand the statement you are making. You think
that
implementing a thin Java servlet that is different for each screen holds
the
same level of difficulty as Javascript? (rhetorical)
See, this is the problem. I've never been able to fully convey to you the
concept of a thin JSP. In my PSC product, for example, a client can have
hundreds, even thousands of JSPs, and they use exactly ONE servlet.
The idea is that the only job of the JSP layer is to convert between EBCDIC
data structures and Java beans. Now, PSC is actually a rather complex
environment because it needs to emulate things like subfiles and the INFDS,
but still and all, it uses a single servlet. A complex, powerful servlet,
but just one servlet, nonetheless. Technically, there are two: one for
simple green screen in a browser emulation, and one that supports the
enhanced GUI features of the advanced version, but even those share most of
their code.
You need to have a definition for each message (typically an XML file), and
you need to gracefully report conversion errors when they occur. That's the
part you always seemed to have trouble with: being able to manage a lot of
message definitions, but that's really no more difficult than managing a
database. And once you have the error reporting mechanism in place,
definition errors are no longer Java exceptions, they're just programming
errors like any other.
Hee hee! And you accuse me of stretching. Java trouble tickets? I have
never had a Java trouble ticket because of a thin JSP architecture. Of
course, you do need to train them to handle CSS trouble tickets...
You were stretching things I said so I felt the need to correct. To say
that a company implementing Java servlets that run on the front of every
web
app wouldn't have a trouble ticket related to something wrong on the Java
end is just foolish-ness on your part. If you arguing over semantics of
calling it a "Java trouble ticket" I don't know what to say other than you
are looking to argue for the fun of it.
No, I'm trying to separate setting up an initial architecture and the
ongoing maintenance of an application that uses that architecture. In the
thin JSP architecture, you have a single servlet that converts messages
between EBCDIC and Java objects. That servlet is roughly equivalent to the
CGIDEV2 service program (or whatever framework you use).
If you don't use a pre-existing framework, I contend that it would actually
take more work to write such an infrastructure in RPG than it would in Java,
because in Java the JSP technology is already available, and in RPG you have
to write your own template-substitution technology.
But once the framework is working and debugged, you are as likely to have to
report Java trouble tickets as you are to have to log CGIDEV2 trouble
tickets.
It's not foolishness to assume that a good, solid framework won't generate
bugs; that's just the end result of a good design. I have thousands of
users running my single servlet and they don't have to report Java trouble
tickets.
re-work your CMS to facilitate Java objects,
Yet even with an RPG-CGI approach, you have to make your CMS work with
HTML
fragments. And Apache configuration files. And CSS files.
Just so I can fully understand the statement you are making, would you say
that deploying Javascript, which is no more than a text in a file, is
similar in complexity to deploying Java? (rhetorical)
First, I would say deploying JavaScript CORRECTLY (having proper naming
conventions, having reusable code that is shared between pages,
incorporating and modifying third-party JavaScript, doing something more
sophisticated than, say, popping up another browser) is a bit more difficult
than simply hacking a file with Notepad.
Second, I would say that the amount of Java syntax required to MAINTAIN a
thin JSP architecture (that is, either manually adding message bean
definitions or adding entries to XML files, and then writing JSPs to use
those beans) is no more difficult and in fact is less difficult to
understand than the syntax required to properly leverage JavaScript.
A basic feature of JavaScript, for example, is the ability to dynamically
add an event handler to a field. While the syntax is relatively simple,
it's a bit of a leap:
document.getElementById('MYFIELD_ID').onclick = OnClickProcess;
This simple line of code, which adds an onclick capability to the element
whose ID is "MYFIELD_ID", requires quite a bit of knowledge. First, you
have to know how to get a field by ID, then you have to write a function
called OnClickProcess, then you have to know that you can dynamically set
the onClick for that field and finally you have to know the name of the
property that allows you to modify the onClick attribute (the last is
usually pretty easy, since the property is the name of the attribute, but
all lower case).
You can do this via HTML:
<SPAN onClick="OnClickProcess();"> ... </SPAN>
But that's hardcoded. To do this sort of thing dynamically, which is one of
benefits of JavaScript, requires significantly more knowledge. My point is
that it's just as hard to learn JavaScript as it is to learn Java.
If your argument is that multiple languages is harder than one, of course
you're right.
There we go! Bingo! That's what I was looking for!
Yeah, but it's still the right way to do things. I think we've established
a long time ago that using the right tool for the job is a good thing. RPG
is not necessarily the right tool for formatting HTML. And I haven't even
addressed the myriad benefits of having the web interface portion of your
architecture be platform independent.
Like I said in an earlier thread, each added technology should have an ROI
put on it. Do I think RPG programmers can learn your model - you bet. Do
I
think they can write great applications with it - you bet. Do I think it
will take them longer to do it with the thin JSP vs. RPG - I can guarantee
it (and you also agreed). I don't even know what you are fighting with me
on anymore.
No, I think an RPG programmer can maintain a thin JSP application just as
quickly as they can maintain an RPG-CGI application, maybe quicker. I also
think that when you compare the approaches from a purely technological
standpoint, that you find JSP has significant benefits over RPG-CGI, not the
least of which is the ability to easily move your user interface processing
off of your primary business logic box. This provides both increased
performance and better security.
Do I think thin JSP is the right solution in all cases? No. There are
valid reasons to go with RPG-CGI. But "it's too hard" is not one of them.
Joe
midrange.com
