Re: Adobe's RIA Technologies

Aaron wrote: I am probably not your typical IceBreak user as I grew up

with calling all the stdin and stdout API's directly and I have become picky
with how much I like a framework to help me because *sometimes* they get in
the way. I can see how IceBreak would be an excellent solution in making
the transition from ASP/JSP/PHP to RPG+IceBreak.
<<

I agree that frameworks can be a pain in the neck if you want to break the
frames of ideology. However, I think it depends on where in the layer the
framework exists.

e.x. Tomcat is implementing a servlet engine. This is also a framework.
However what you build on top of that is an other story. Today you se
frameworks build on top of other frameworks, which hide the layer beneath.
Anything from spring, hibernate - any ORM and web technology will likely
live up to that assumption.

In IceBreak we work hard so you can have it with both vanilla and chocolate
taste at the same time, so you can make simple HTLM / ASP programs together
with advance webservices orchestrated by an ESB - Enterprise Service Bus
application, Rich web 2.0 clients using AJAX / JSON etc. We don?t want to be
in the driver's seat when you select the technology on top.

In the end of the day - the success of the companies using these
technologies relies not on the technology itself but rater on the solution
they provide.

So when you select ASP/JSP/PHP/IceBreak/RPG/JAVA/RUBY/ etc. the key question
is no what they can achieve - because all deliver what they promises.. No -
the question is "what is our exit plan and how easy can we replace this or
that technology?"

It does not matter how funky they are now or how long they last, eventually
sooner or later they will all be outdated.



Best regards


Niels Liisberg
IceBreak Chief SW Architect

System & Metode Technologies
Håndværkersvinget 8, DK-2970 Hørsholm
Phone: +45 70 20 36 10
Fax: +45 70 20 30 11
Direct: +45 45 177 055
Mobile: +45 31 158 861
E-mail: nli@xxxxxxxxxxxxxxxxx
Web: www.system-method.com and www.Icebreak.org




-----Original Message-----
From: web400-bounces@xxxxxxxxxxxx [mailto:web400-bounces@xxxxxxxxxxxx] On
Behalf Of Aaron Bartell
Sent: 31. oktober 2008 14:37
To: Web Enabling the AS400 / iSeries
Subject: Re: [WEB400] Adobe's RIA Technologies

however the CRTICEPGM command is used from within RDi /eclipse if you want

to control the compile phase.

I am assuming CRTICEPGM is using CRTBNDRPG behind the scenes? I couldn't
find it on my system. Does it allow me to choose all the different compile
options I might want? I guess part of the issue I have is that I already
have a "compiling helper" by using comments at the top of my program:

H DEBUG(*YES) dftactgrp(*no)
*T: 1003: Cancel/Complete Orders
*I: QCMPSRC,CRTBNDRPG
*O: BNDDIR(OMIBND RXSBND)
*O: TGTRLS(V5R3M0)

I am probably not your typical IceBreak user as I grew up with calling all
the stdin and stdout API's directly and I have become picky with how much I
like a framework to help me because *sometimes* they get in the way. I can
see how IceBreak would be an excellent solution in making the transition
from ASP/JSP/PHP to RPG+IceBreak.

Thanks for your response,
Aaron Bartell
http://mowyourlawn.com

On Fri, Oct 31, 2008 at 8:21 AM, Niels Liisberg
<liisberg@xxxxxxxxxxxxx>wrote:

Hi Aaron , gents ..

Arron wrote: The bummer (in IceBreak) I have so far with it is that

there
is no MVC built into the product<<

The "one-size-fits-all" has never been the idea of IceBreak, rather give
the
user some choices. Many RPG programmers don't feel comfortable with any
kind
of web technologies or frameworks simply because there are far too many
disciplines to learn. So - yes - you can build programs with a JSP / ASP
approach - which are good for quick and dirty stuff and/or educational
purposes. The build in JIT compiler delivers the result, just by

refreshing

the browser page, however the CRTICEPGM command is used from within RDi /
eclipse if you want to control the compile phase.

In "real world web applications" you would also rely on a framework of

some

kind and some tooling to support it. Adobes flash powered Flex is an
excellent choice, however, in IceBreak we did chose to follow the ExtJS
path.

Arron wrote: Maybe you have some application code you can share that

shows how IceBreak can do the things that you are talking about? (i.e.
solid
MVC with extJS)<<

I think I can demonstrate it with a program containing only one line of
code:

The hole idea in MVC is to decouple any of these M, V, C components from
each other. Our solution is to support "data stores" for the ExtJS
framework
- look at the following IceBreak program

SQL_Execute(
I_EXTJSMETA: // A JSON object including metadata
'Select * from product':
numberOfRows:
startingFromRow
);

This returns a partial result set for a paging grid.

IceBreak simply produces a JSON object in the responseObject and returns

it

to the Ext client, which happily renders the grid and allows the user so
use
page up and down using a AJAX request for setting the "startingFromRow"
attribute. This is only possible because IceBreak provides session
stability
for dataset too.

So our MVC model let you do the decoupling 1where IceBreak is gluing the
"V"
and "C" together behind the scenes with JSON ... and you don't even have

to

look at it.

The IceBreak ExtJS component wizards even produce grids, dropdowns and
complete programs.

I suggest this kind of modeling instead of the SOAP webservice approaches,
which in my opinion is to over engineered for this particular job. ? You
need to parse the SOAP, XML ? and you need to provide some session
stability
for the dataset etc?.

Niels Liisberg
IceBreak Chief SW Architect