Re: JSF/EGL datatable positioning question

I have been following this thread (and the other EGL threads) with some interest and I think Nathan is getting to the core issue. The basic issue is that there are trade offs in any approach we take to development on the System i and the transactions in the trade off will be contingent on several things that have been covered:

Easy of use vs customization
Cost of the tool vs productivity
Programmer skills (and inclinations) vs skills required
Portability vs leveraging platform strengths

I think these are endlessly debatable. In Joe's defense it IS an issue of using the right tool for the right job, I am a big fan of that, but we also need to find a balance about finding (or training) the right hands to put that tool into (given background and budget).

Bob, I think you said that the majority of System i programmers are RPG III skilled. Yet, and I find this curious, the tools IBM is promoting and encouraging are WYSIWYG tools. And, although I am OK with that (love it, actually), tools like EGL generate code that is difficult to maintain outside of the WYSIWYG environment. That is to say, unlike WDSc, with EGL you are completely abstracted from the underlying code. Again, that can be a good thing when you are dealing with a tool that does it all, but there IS no tool (yet) that does it all and eventually you'll want to edit the code directly, to handle something the WYSIWYG environment can't handle (a "hack" if you will). So I am kind of surprised that something like EGL doesn't generate RPG code it the background since the "majority" of programmers are RPG programmers (and RPGIII at that).

I have experience in both the RPG and Java worlds. I am OK in both (well, perhaps underskilled in RPG). I have made my peace with friends and foes in programming land. I just continue to scratch my head a bit when it comes to new "tools" for the System i. I definitely understand leveraging existing RPG programs. I am little more mystified that RPG *skills* don't get the same benefit. When I look at EGL in the next week or so, I am sure I'll be fine with it. I'll need to learn it and exercise it so I can figure out how to get it stuffed into my toolbox with all the other "productivity enhancers" I have, but I move from ILE RPG IV, to Java, to C++, to C#, to Ruby every day. That is the world I have chosen to live in. But, not every geezer like me enjoys that journey. Continuing to code in RPG while still be able to generate 21st century applications would, I think, have been something IBM would have pursued. Maybe they have and I missed it (with the exception of VARPG).

Pete Helgren

Nathan Andelin wrote:

<snip from Bob Cancilla>
The whole point of EGL is to hide the underlying technology so
you don't have to deal with it.
</snip>

While I believe a lot of programmers will appreciate that EGL hides underlying technology (HTML, JavaScript, CSS, Java, J2EE, etc.), the problem expressed by Tim when he originated this thread, and other similar frustrations which could occur, may be an indication that EGL goes too far in hiding underlying technology.

I was looking at Rational's documentation for the dataGrid component and compared with with the JSF specification and other documentation from other tool vendors who are supporting JSF, and the abstractions seem so high-level in some contexts, and so similar to HTML in other contexts, that it makes me wonder what value JSF is trying to add.

Many JSF dataGrid attributes map directly to HTML table attributes (bgcolor, border, cellpadding, cellspacing, id, style, styleClass, title, width), while other HTML table attributes are excluded from the JSF specification. In one case a developer may be wondering why have an extra tool just to define a standard HTML element, and in another case they may wonder why many of the HTML attributes weren't included in the JSF specification?

If you use a standard HTML editor like Dreamweaver, you not only have complete access to the table element, with all it's attributes, but you also have full access to the header, footer, row, and cell elements that may be defined in the table. However, if you're restricted to the JSF dataGrid specification - it appears that you're constrained.

I guess it's really cool to be able to drag and drop a UI component
onto a design surface, and bind it with a data component, and magically
see a list of records appear on the screen, but it may not be worth the
frustration of trying to get things to work outside the box.



Nathan M. Andelin




____________________________________________________________________________________
Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ