The problem is that programmers (RPG, PHP, .NET) is used to think and
program monolithic so they are just carrying bad habits around.

When AJAX came around in web developments people started to do "call
back" to the same CGI/PHP or .NET page that served the initial page
instead of seperating the code that served the page and the code (normally
DB I/O) that handle the AJAX call into reuseable REST/CRUD services.

The biggest problem is that lot of this old style code ended up as examples
on the net and then spread out like a forrest fire.

The same goes for forums, if one have a problem, 9 out of 10 answers are
done in "old coding style".

It is extremely hard to learn old dogs new tricks simply bacause you have to
pull them out of their "comfort zone" - RPGOA is a good example where IBM
tries to leave programmers in a old coding technique they recognizes and
feel
comfortable with.







On Wed, May 8, 2013 at 11:24 PM, Matt Lavinder <
mlavinder@xxxxxxxxxxxxxxxxxxx> wrote:

CGIDEV had an HTML template interface back in 1998. PHP seems to be
struggling with separation of concerns in 2013.

Nathan- that really is not a fair comparison AT ALL.

CGIDEV2 is a framework that wraps around the IBM HTTP Server API. Without
it, web development in RPG would face the same struggle and be very
complicated. CGIDEV2 makes developing web applications from RPG much
easier. It was loosely modeled after green screen, DDS development, so it
actually made web development far more accessible to RPG programmers.
That's why it is all but the standard for writing HTTP applications from
RPG. CGIDEV2 solves MANY problems.

PHP was a web development language from the get-go. The concern
of separating HTML from the sever logic was not a major concern when it was
invented in 1995. Now that the paradigm has shifted, MANY frameworks
and methodologies have popped up for PHP to make separating logic and HTML
fairly simple, but developers have to choose to use them and follow them.
They have to stop doing what they are used to.

This is very much like the challenge RPG faces with its own developers
being slow to embrace things like free-form, procedures, and embedded SQL.
Things have changed, and many developers struggle to move forward.

Plenty of RPG programmers are writing their code like it is still 1989.
Plenty of PHP programmers are writing their code like it is 1999.

The problem is almost NEVER the language. It is usually the developers
that refuse to move forward and take advantage of the advancements that
have been made.


--
*Matt Lavinder
Programmer Analyst
Data Management Inc.
Phone: (336) 573-5045
Fax: (336) 573-5001*



On Thu, Mar 21, 2013 at 7:05 PM, Nathan Andelin <nandelin@xxxxxxxxx>
wrote:

I can see a lot of programmers reading that article and scratching their
heads and wondering if "separation of concerns" or MVC is really worth
it.
The first sample shows DB I/O, control logic, and HTML in just one file.
Strait forward and easy to read.

As the code evolves to finally using the "twig" template engine, the code
is split into several files, and grows substantially in size. Some must
wonder if maintainability is actually improved.

You're still left with a mixture of DB I/O, control logic, and Browser
I/O
in multiple files. The "separation of concerns" is not pure, so to speak.

CGIDEV had an HTML template interface back in 1998. PHP seems to be
struggling with separation of concerns in 2013.

-Nathan



________________________________
From: Eric Lehti <elehti@xxxxxxxxxxxxxxxxxx>
To: Web Enabling the IBM i (AS/400 and iSeries) <web400@xxxxxxxxxxxx>
Sent: Thursday, March 21, 2013 3:47 PM
Subject: [WEB400] PHP coding styles; Procedural versus
Model-view-controller (MVC)

I received an email from iprodeveloper.com saying this link to paid
content is temporarily unlocked for all to read. I find it interesting
and want to share with you. Enjoy.

http://www.iprodeveloper.com/article/application-development-tools/jumps
tart-php-productivity-websmart-699592

Discusses PHP coding styles:
- Procedural Pros and Cons, with Comparison to procedural RPG. UI is
often intertwined with the coding logic-a poor design strategy.

- Advantage of separating UI from business logic. separates the UI
from the business logic.
<snip> SoC stands for separation of concerns, which is just a fancy way
of saying "keep your programming logic separate from your user
interface." The SoC philosophy is exemplified by Model-View-Controller
(MVC) development. One can make a case that RPG green-screen programs
were using MVC design long before it became popular in web application
development. The RPG code is the model (and parts of it are the
controller, too) and the Display file is the view
--
This is the Web Enabling the IBM i (AS/400 and 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.
--
This is the Web Enabling the IBM i (AS/400 and 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.


--
This is the Web Enabling the IBM i (AS/400 and 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.





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.