Unconfigured Ad Widget

Collapse

Announcement

Collapse
No announcement yet.

Java…Huh…Yeah...What Is It Good For?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Java…Huh…Yeah...What Is It Good For?

    Chuck wrote: I expect that the AIX folk are much less dependent upon IBM. They rely more on third party and/or make their own tools. That is the exact opposite of reality, Chuck. That is the sad state of the AS/400. Unix has a choice of XWindows and Gnome as their standard GUI interface. Surely you knew this? rd

  • #2
    Java…Huh…Yeah...What Is It Good For?

    What I advocate is not that far off from this, just more flexible. A 5250 buffer output as XML with layout information can be rendered to HTML or the more advanced description layout standards suitable for desktop clients. In any event, the translator is below EXFMT and should be connection based. If they would just put out a data stream that is extensible from within our programming then the same program could go to multiple types of displays. One could argue that HTML be that description, thus the solution approach you and Nathan mention would suffice, but it is too limited. The rich interface laid out with such things as XUL is an interface worthy of the AS/400, not a web page. rd

    Comment


    • #3
      Java…Huh…Yeah...What Is It Good For?

      David, The following link is a bit of an R&D project I've been playing with today, providing a basic proof of concept of the browser device file idea. Rather than generating HTML from DDS (like Webfacing), how about the reverse - generating DDS from HTML? I used Dreamweaver to layout an HTML page, then generated a DDS "special" file, and used it in an RPG program to talk to a browser. http://www.relational-data.com/ascent/xur121.html I'm not sure where to take this idea from here, but the model is pretty close to the traditional 5250 workstation model. Nathan.

      Comment


      • #4
        Java…Huh…Yeah...What Is It Good For?

        Ralph, I'm keeping an eye on Mozilla's XML User Interface Language (XUL). All the WYSIWYG editors I tried were quite primitive, but XUL seems to hold quite a bit of promise for deploying a UI for Windows, Linux, and Macintosh clients, using GUI components native to each platform. Nathan.

        Comment


        • #5
          Java…Huh…Yeah...What Is It Good For?

          It doesn't have to be basic HTML. Depending on the SDA, it could be DHTML, XML with HTML, HTML with script extentions, actually anything. The priciple concern is to be able to insert, retrieve and manipulate data from the HLL program, while displaying the page. The data displayed on the page should be available in some external format, and the reading and writing of the page should be no more complex than the current EXFMT. The loading of Combo, and data boxes should be on the lines of subfile processing. IMO, The HLL programmer should not be concerned with HTTP POSTS and GETS. CGI APIs would become a thing of the past, as they and other methods would be replaced by native language opcodes. IBM would argue that we already have this with Webfacing, but that kind of misses the point. The goals and objectives would not be to migrate existing 5250 screens to a web interface, but to be able to create the web interface (from scratch), and use your HLL program to do the rest. Dave

          Comment


          • #6
            Java…Huh…Yeah...What Is It Good For?

            Yes, it does hold a lot of promise, Nathan. I wouldn't mind a bit if Firefox source modified if necessary to be the native interface for the AS/400. IBM has to open up the output of the 5250 buffer as an XML stream for the standard programming environment of the AS/400 to continue to make it successful, however. It has to come from within OS/400 EXFMT to be standard and allow the AS/400 to continue to succeed as it did in the past. Every Tom, Dick, and Harry's web page interface isn't going to cut it. It doesn't exist anywhere else, and it only exists on the AS/400 because of the vacuum that IBM has left with the Websphere void. rd

            Comment


            • #7
              Java…Huh…Yeah...What Is It Good For?

              You seems to be concerned about me promoting my Web interfaces to a general audience, Nathan, I'm sorry it sounds that way, but what I'm trying to do is make sure that people compare the various approaches on an even playing field. You said the following: It might be helpful for some to understand that some of the things that Java is good for CAN be done in RPG, even UI related. Following is an example of generating an HTML combo box. You then went on to show the code that called your APIs. This is good; it hows the code that has to be written for new UI. However, you didn't show the code BEHIND those calls; you didn't show the amount of code that would have to be written in order to support those APIs. So, in the end, you didn't really show the code required to generate an HTML combo box. so we can't really compare it with the amount of code for a JSP solution (which I contend will be quite a bit less). Nonetheless, you DID show that, with a proper API, the amount of code required for creating new UI pages is comparable to the amount of code to create a new JSP, and that's worthwhile in and of itself. Joe

              Comment


              • #8
                Java…Huh…Yeah...What Is It Good For?

                ** This thread discusses the article: Java...Huh...Yeah...What Is It Good For? **
                ** This thread discusses the Content article: Java...Huh...Yeah...What Is It Good For? **
                0

                Comment


                • #9
                  Java…Huh…Yeah...What Is It Good For?

                  ** This thread discusses the article: Java...Huh...Yeah...What Is It Good For? **
                  This reply is in specific response to one of the weaknesses of Java, where Joe states, <> Out of all the weaknesses mentioned for Java, the developer has more control over this particular one. There are a lot of books on OO programming that solve this. The early days of OO were heavy on inheritance, which turned out to be a weakness in maintenance programming. "Find what varies and encapsulate it." "Program to an interface, not an inheritance." For my current Java projects, I step back from the specs and ask from where are the changes likely to come? Then I approach the development accordingly. Here is where iSeries developers have an advantage because most of us iSeries folk have one foot in the business domain and understand it better than your average Java developer who usually has both feet in the technical domain. Good article.

                  Comment


                  • #10
                    Java…Huh…Yeah...What Is It Good For?

                    ** This thread discusses the article: Java...Huh...Yeah...What Is It Good For? **
                    Thanks, Charles. You're right that the prevalent thinking on OO is moving away from inheritance and towards aggregation. This helps, but at the same time, reducing the amount of inheritance reduces one of the benefits of Java and tips the scale more towards a procedural language like RPG. Without inheritance, most of the capabilities of OO language (such as encapsulation and polymorphism) can be mimicked relatively easily in RPG. And it's STILL easier to handle major logic changes in RPG than in Java. By major, I mean situations where your pricing model completely changes, or you merge with another company and the meaning of "calendar" is different, or adding one-off capabilities such as "Bill sold Customer XYZ 1000 units of ABC at $50, even though the price is $55". Most of these are easier in a pure procedural language, and RPG is especially good at this because of its inherent support for decimal arithmetic. Joe

                    Comment


                    • #11
                      Java…Huh…Yeah...What Is It Good For?

                      ** This thread discusses the article: Java...Huh...Yeah...What Is It Good For? **
                      It is a good article. I don't think I've seen anywhere where the range of business programming architecture decisions is covered like Joe covers it. One note to add. While the Buddhist calendar API sounds obscure at first glance, it is a very important Japanese calendar addition in the upcoming release, and as Joe points out, that kind of internationalization is done best by low level object implementations to the same interface, in this case the extensive Calendar interface. On the other hand, and Joe has already emphasized this in a response, code reuse was supposed to be magnitudes greater than our procedural programming based on inheritance, but I don't see the testimonials to that power realized. Actually I think our program API's especially as prototyped parm calls with library list heirarchy to intercept selected API calls is more powerful. This is heresy to all but AS/400 programmers to say but the power of OS/400 (I guess IBM is calling it i5/OS now) is something that if Linus had been able to structure Linux on would be the coolest thing on the planet. I doubt that anyone outside of Rochester even knows about it though. Adding to this, I will have to say that although I've been programming in Java for the past year on my own projects I see it's greatest value as rich cross platform client software running against server software of choice which may be Java. However, I do not see enough value add on the AS/400 as the outermost layer over RPG business logic to justify the Java programming infrastructure, including Java programmers. Again, this is heresy to say, especially when a good programmer should be able to switch into a Java environment and add appropriate logic as needed which I have posted I believe is no big deal for us. I just don't think the mix is better based on descriptions of the architectures I've read about here. If one argues that the server code can be moved to another platform, then one isn't using RPG and native I/O to its advantage anyway. If not, then you're really developing lowest common denominator code and you might as well then code all Java. Either way, the server code is homogeneous then, as well as the server programming. rd

                      Comment


                      • #12
                        Java…Huh…Yeah...What Is It Good For?

                        ** This thread discusses the article: Java...Huh...Yeah...What Is It Good For? **
                        The Java interface is for the UI, which is best written in a languaeg other than RPG. The best problem set domain for an OO language is one in which the problem doesn't change over time. A standard problem set for which OO works especially well is generation of a language with a strict syntax... such as HTML. OO languages such as Java are perfectly designed to start with the most generic of HTML generation classes and work them into more problem-specific versions. Because of this, I can create powerful HTML-generation classes in Java more easily than in RPG. That's why (as I state in the article), I believe in leaving the business logic (which should be entirely UI independent) in RPG and writing the UI in Java (specifically JSP Model II). Joe

                        Comment


                        • #13
                          Java…Huh…Yeah...What Is It Good For?

                          ** This thread discusses the article: Java...Huh...Yeah...What Is It Good For? **
                          Joe wrote: That's why (as I state in the article), I believe in leaving the business logic (which should be entirely UI independent) in RPG and writing the UI in Java (specifically JSP Model II). I haven't seen a good counterargument to that but I hope CGIDEV knowledgeable people talk more about it. It's a strong point you make, Joe. My personal experience, which I have posted on in the past, was that of tagged HTML stored in IFS and accessed by the web server to populate the dynamic portions of the web page. I personally don't understand why it's good to program generation of HTML web pages in either JSP or CGIDEV. But I appear to be in a very small minority here on that. rd

                          Comment


                          • #14
                            Java…Huh…Yeah...What Is It Good For?

                            ** This thread discusses the article: Java...Huh...Yeah...What Is It Good For? **
                            RPG-CGI is a great concept if you don't want to learn Java and you'll never need to move your UI off the server. However, if you want to embrace the greater world of J2EE, including things like web services, you're gonig to need Java eventually, and JSP Model II is perhaps the easiest way of getting Java literate. HTML is certainly a lot simpler than Swing or SWT. You need a little bit of plumbing (to create a generic servlet) and a little bit of knowledge of IBM's Java Toolkit (to create a generic bean) and you're pretty much done. You can also go the Perl/PHP/whatever route, but that's getting farther away from both your native RPG and the J2EE platform, so I'm not sure of the strategic term benefits there. Joe

                            Comment


                            • #15
                              Java…Huh…Yeah...What Is It Good For?

                              ** This thread discusses the article: Java...Huh...Yeah...What Is It Good For? **
                              Great article. It might be helpful for some to understand that some of the things that Java is good for CAN be done in RPG, even UI related. Following is an example of generating an HTML combo box. The RPG program might generate the combo box in an initialization step, then output it with just one or two lines of code whenever a particular page is requested: Nathan.
                              Code

                              Comment

                              Working...
                              X