× 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.



Inline:

Aaron Bartell wrote:
Similar metaphor (drag and drop, point an click, fill in the blanks, just
like the Dreamweaver you are familiar with) but the implementation of that
metaphor is so much cleaner and logically laid out. And, you get that
backend plumbing to boot. So far, EGL is running no where close to empty on
that front.

And that is exactly what can make or break a framework. Whether they tried
to do too much for you or did they stop the "helping hand" at a right place.
Or maybe a better way to put it is: Did they do a lot for you, but provide
an easy way for you to go outside of the box when your need doesn't fit
within their tooling.

Right now I feel I have the right amount of handholding and the right amount of freedom. However, I am very early in the learning curve. You can't predict when the honeymoon will end (sometime it never does).

The thing that caught my eye with JSF four years ago is the fact that it
delivered mapping of screen variables (i.e. HTML <input /> fields) right
into getters and setters in my .java controller/POJO (I had to do no
plumbing for that). The other thing I REALLY liked (that I hope to
duplicate in RPG) is the ability to map a user interaction to a specific
method in a class. It just made it so easy to create a page without having
to do much plumbing. These are the things that STILL save me time.

I have never used JSF. I gave it s cursory look but that is about all. How I would implement it in my existing applications, I wouldn't know.
The issue came when I had to go outside of the JSF spec author's ideas of
web page processing. This is where Joe and I had our disagreements earlier
this year (and around Thanksgiving last year). You can search the archives
for them if you wish to know the points I ran into (which inherrently
*might* have the same issues in EGL being JSF is EGL's plumbing).

After running into my dislikes of JSF and narrowing down what I DID like, I
kinda kept shopping for a framework that wouldn't try to "help" me so much.
Tapestry was my next stop and it was great because it allowed the creative
developers to make the page pretty without them having to learn JSF tags.
Tapestry just inserts additional attributes into HTML tags which worked
great for the UI designer. I had to drop Tapestry because I ran into
problems with the way it and Hibernate worked with lazy loading of complex
(i.e. SQL LEFT JOIN's, so not really that complex) data sets into UI
components - it just didn't work well.

It would be interesting if IBM ever made the EGL spec open source and added
their value through tooling. That would give it much more acceptance much
faster. As it stands there are less EGL developers/books/documentation/etc
out there than RPG right now, and if it doesn't take off like IBM hopes,
then there is *a* chance IBM could pull the rug out. Yes this sounds like
FUD, but it is FUD with history to prove its potential. I think Thorbjorn
(spelling) said it best with the statement (paraphrasing) "it is safer for
me to go with open source because then I can choose how I put my framework
together and not have to worry about IBM/Microsoft/etc changing directions -
I 'own' the framework".
Yep. I love open source for the same reason. It is the reason I left the Microsoft camp 10 years ago. I got tired of trying to build my business on a vendor that had fairly capricious pricing and licensing practices. The good news with EGL is that there isn't a "runtime" so if IBM decides to pull the plug, I still have all the code. Yeah, it could be tough going forward without the tool to manage the code, but it is code I can tweak outside the framework if I absolutely had to.

The sample app I am *still* looking for from EGL is a solid business
application that has a lot more complicated processing being done -
something along the lines of a scaled down order entry application would be
great to see. I already know the difficulties (and niceties) of doing it
with RPG-CGI. Actually, I have told the guys from CNXCorp (their Valence
RPG Web framework) they need to do the same thing (they said they have
something in the works), because until I see a more complex application with
ANY framework, it is hard to tell how beneficial it will be to me long
term. If anybody has the opportunity to develop something they can "open
source" to the community that would be great! What Pluta and Laffra have
developed is a good start towards that, but it is still an "entry level" app
if you will.

I think Thorbjørn and I would both like to see a functional outline of what a "solid business application" would look like. Order entry would be good, and there is an EGL tutorial already available that does this in a rudimentary way. Beyond producing such an app, I'd like to see a tutorial, as close as possible, as how to create it. The reason is, unlike Joe's throwing down of the gauntlet that says "replicate this", a step by step of how you arrived at the solution would help explain the simplicity or complexity of the approach. The "black box" approach that says "make me one of these" and then one them appears, isn't that helpful to me. Sure it says it could be done but if you arrived at the solution writing assembler code to get there, I'll need to have the step by step to do it with assembler. Because, in my case, I want to compare the effort it takes to arrive at the solution, not see if you can replicate it.

Like I said in my first post: I can do this stuff, most of us web guys can. Given enough time we could all build a complex application and they could look identical if we took enough time. The issue is the level of effort and expertise to get there. I am not lazy, I just have too much to do. If I can get a quality solution quicker, I use the tool to get there.
Aaron Bartell
http://mowyourlawn.com


On Sat, May 24, 2008 at 12:43 PM, Pete Helgren <Pete@xxxxxxxxxx> wrote:

"That's the type of development I did in the 90's, but moved away from
it after it got too confining."

I hear you. Actually, I have experienced that quite a bit as I have
taken a look at several frameworks, even lately. They look great after
a few carefully targeted tutorials but then as I scale to something more
complex, the efficiencies diminish and I find that it is quicker just to
code the stuff myself rather than work around the limitations. I worked
with an RPG 5250 template set just like that back in the 90's. You
could crank out a CRUD application in an hour, but if you needed a
fairly complex application with multiple sub files across multiple
screens it got rather messy.

I am glad to hear that you have experience with something like VS and MS
.Net because then you will appreciate (as you will find when you take a
test drive) that EGL (so far) is NOTHING like that. Similar metaphor
(drag and drop, point an click, fill in the blanks, just like the
Dreamweaver you are familiar with) but the implementation of that
metaphor is so much cleaner and logically laid out. And, you get that
backend plumbing to boot. So far, EGL is running no where close to
empty on that front.

I haven't had *that* much difficultly in hooking up HTML pages to
backend processes (but EGL is easier and faster, IMHO - so far). Where
I run into "framework" issues most commonly is that I'll see a web app
design I really like, and which I can achieve by hand coding (with some
work) but I haven't seen any frameworks (so far) that can keep up with
the very diverse HTML page formatting I have seen out there in the web
world. So, I am looking forward to the JSP/JSF stuff the week of June
2nd. Those are two technologies that I have very little experience with
so it will be interesting to see what capabilities they bring to EGL.

I feel like that kid on the Life cereal commercial: "You try it.... No,
YOU try it.....I'm not going to try it.....He likes it....Hey Mikey!"
So far, and it may be too early to tell for certain, EGL looks more
productive than what I have been doing to date. I don't really care if
it's drag and drop, roll your own, assemble bits on a screen or draw on
a piece of paper. My interest is producing stable, maintainable code,
that meets customer needs and can be done profitably. I don't care if
the framework is something I developed or even from Rational (gasp!).
That is why I have looked at so many different frameworks. Not to find
"the holy grail" of frameworks, but to find something I can use
efficiently. Something that makes me more efficient than my competitors
and thereby gives me a competitive edge.

I still recommend that you take an unbiased look (as unbiased as anyone
can). There is more than meets eye (or the hype). You have to see for
yourself.

Pete


Nathan Andelin wrote:
Pete Helgren wrote:
Nathan, I am a complete noob with EGL so you can
take what I say with a grain of salt.

Thanks for the lucid explanation. It's clear that EGL will appeal to
developers that use Visual Studio and MS .Net. Drag & Drop. Point &
Click. Fill in the blanks.

That's the type of development I did in the 90's, but moved away from it
after it got too confining.

Nathan.

--
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.



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
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.