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



Aaron Bartell skrev den 24-05-2008 21:33:

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 also really liked the way that you can refer through maps and beans with a concise syntax instead of dealing with tons and tons of getters after one another.

There are some rather nice things which is much better than both plain JSP as well as struts. I am looking forward to brushing up on this again, as the JSF-app I wrote most likely is due for revision.

One thing I really, really liked was an extension to MyFaces which allowed me to access both the variable context of the page I was coming from (inside loops and all) as well as the page I was going to. This allowed me to essentially provide the relevant info in the link instead of having to build transfer beans for each and every link type. That was very nice.

Unfortunately I cannot use JDBCto talk to the legacy system otherwise my life would have been much easier with rowsets and all.

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

Could you briefly summarize what the problem is? You can keep state between calls in the session object so it must be something else.

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
You know my opinion on the matter :) I have just one more - the more liberal license with jt400 as opposed to client access allows us to ship binaries to clients embedding jt400. We cannot do that (AFAIK) with client access due to its license, and installation procedure.

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".
More that you are guaranteed there is a light at the end of the tunnel regarding the strategic platform you need to write your stuff at. Why save time using some kit, if you just postpone the pain to later when it will kill the patient?

If IBM really, really, really wantet EGL to hit big time I also think they should throw it in the Eclipse bin and make it usable everywhere, but work the best on IBM's own machinery (simply because that is what is supported). These days we have a choice and to make a new choice that locks you into a platform and vendor choice is as bad on the i as on Windows.

I have seen enough "interesting cases" of Java on the i to say that it is not a troublesome path, but I am also certain that well-written Java code may live for ever as the platform will not go away. This is due to the specs and the GPL on the source - THAT is what will fullfill the original "write once, run everywhere" (instead of everywhere being Windows and Solaris (and Linux but it wasn't originally) plus OS X after a year or two) as all the various alternate operating systems will have a JVM.
Also, when a mechanism is created that allows Java stuff to start "immediately" we have a new situation for writing normal command line utilities (Flash has conquered the applets).

Until then, well EGL is most likely a great prototyping tool, but would you bet your company on it?

Oh, by the way, what would you recommend using for writing non-trivial applications of the kind we are discussing here?


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.