Sean
When I created my system originally in the early 1980s, I decided then that
I would separate UI and business logic. This decision much simplified the
task of building a totally new system and, when it went live in 1983, it was
a much simpler system than if I had not made this separation and I am sure
that it was up and running much sooner than otherwise would have been the
case.
I put all my DDS display formats into one file, which was opened by a
request processing program (RPP). This called the business logic program
(MAIN) which in turn called "exit" programs for the different types of
data. These opened the same display file as RPP on a shared basis. MAIN
did not do any screen output. I split the screen logically into header,
body and footer. The header (and footer) were normally written by RPP which
did the EXFMTs. This meant that the function keys etc were only defined a
few times and the related coding only once. It also meant that there was a
consistent screen layout and method of operation. Just in case, I put in an
option that the exit programs could write the headers if required, but I
have never needed to use it.
The body area was used for a "subfile" type display in enquiry mode and for
an update format in update/add mode. In fact, the subfile did not use DDS
subfile code. I wrote out a single field of 800 characters in the body
area, which looked and behaved like a subfile but, particularly in those
early System/38 days, performed much faster. I put my own 5250 attributes
into the "subfile".
I have never regretted the decision to split UI and business logic. It has
meant that over the years, as I added function, particularly on the
presentation side, it was a much simpler task because there was much less
code to modify. About 11 years ago, I started to generate HTML and use
AS/400 Workstation Gateway (WSG), which although not perfect, did allow the
use of the system over the Web. I replace my own 5250 attributes with HTML
and later added Javascript.
Since the Display file is only opened once (apart from shared openngs which
are much quicker) throughout the whole session and the RPP and MAIN programs
are only called once, reponse times are stunning in 5250 mode (there are
other contributing factors).
SInce WSG is not supported after V5R1, I am now switching to persistent
CGIDEV2. Although I am having minor problems, mainly because I have only
ever been a part time developer and don't know things that most people on
this list would take for granted, it does seem that with CGIDEV2 I will
achieve my aims relatively simply and response times will be pretty good.
Even today, the total size of RPP, MAIN and the most commonly used exit
proram is together under 6Mb - absolutely tiny by today's standards. These
are used for both my development and operational environments.
I have never read up anything on this model. Until your post, I had never
heard of MVC. Having had a quick look, it seems unnecessary complex, at
least in an OS/400 environment using CGIDEV2. I do not have handlers,
callback, dependency graphs, event dispatching threads, etc. - just good old
RPG. However, I do have my own business modeller which is held in my own
database and is updated by the 6Mb of code. This controls which exit
program is called and much more.
Based on my experience, I am sure that you should make the split.
What version of OS/400 are you on? Roughly how many programs to recode?
What is the number of source lines in the larget program?
If I can help more, please let me know.
Rob Dixon
2009/1/23 Porterfield, Sean <SPorterfield@xxxxxxxxxxxxxxxxxxxxxxx>
This might be more appropriate on another list, but my goal is to get web
access to existing green screen programs, so I'll start here.
What I have is a relatively simple application with a handful (maybe a
dozen) users other than the end users inputting into it. It's all standard
old school RPG IV converted (I think) from RPG III - at least that's the
style. All subfile programs with business and display logic together.
What I'm looking for is a nice, easy tutorial/book/etc. of the right way to
design the change to keep existing green screen access able to work the same
(with whatever enhancements I put in) and have a web front end as well. I'm
tempted to just go write new programs for the web side, but even so it makes
sense to incorporate the proper separation. I've seen high level design, I
think even on a Midrange list, about MVC. I'm pretty sure this is the right
way to go, but I'd like to see some simple to moderate examples of the
"right way" to do this.
The modernizing legacy apps information I browsed didn't seem helpful in
this regard.
--
Sean Porterfield
This email is confidential, intended only for the named recipient(s) above
and may contain information that is privileged. If you have received this
message in error or are not the named recipient(s), please notify the sender
immediately and delete this email message from your computer as any and all
unauthorized distribution or use of this message is strictly prohibited.
Thank you.
--
This is the Web Enabling the AS400 / iSeries (WEB400) mailing list
To post a message email: WEB400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/web400.
midrange.com
