From: Aaron Bartell
I think you are being foolish, that's what I think Joe.
Well, there we have it.
You want Nathan and
I to believe something that you yourself haven't even proven outside of
some basic testing.
I don't want you to believe anything, Aaron. I'm telling you my experience
with EGL to this point. You, on the other hand, are saying it won't work
because you had a bad experience with JSF. My point is that maybe, just
maybe, the EGL team knows more about implementing JSF than you do, and from
what I can see, they're doing a great job.
To say that EGL will be good simply because its based on JSP
Model 2 is silly.
True. What I'm saying is that in my expert opinion, the JSF frameworks will
do everything I consider necessary for a production application.
We could draw the same conclusion for every other J2EE
framework out there, but that would be just as incorrect as the lines you
are drawing.
Well, I couldn't, because I haven't worked with them. I have worked with
EGL for many months now, and have come to an opinion.
To say that EGL is good based on your testing with the IBM
team is silly, we all know things done during testing are often different
when they hit the production floor.
Well, things are different, sure, but not so different as to make the
fundamental design process faulty. That's the difference between upfront
design and seat-of-the-pants coding. If the conditions in production are so
different that your basic architecture fails, then your design was faulty.
And that's never the tool's fault, it's the designer's fault.
I've hardly been alive for 20 years, much less been coding for 20 years :-
) Nor do I wish to see who can pee the farthest. Like I said in my last
email, I DO have a fair amount of experience with the same underlying
technologies you are attempting to use.
Experience, perhaps. Enough to make you so expert that you can claim a tool
is bad without having used it? Ah, no, Aaron.
I also disclosed what I did with
the technologies WASN'T mission critical (read, I cut corners here and
there). But then again you haven't written anything mission critical with
EGL/JSF either, so I guess we are kinda in the same boat, eh?
No, we're not in the same boat at all. Because I understand how JSP
actually works and I also understand how tag libraries work (especially the
collector mechanism of JSF, which is a technique similar to what I do in my
generation process), I fundamentally understand the JSF architecture as
implemented by EGL and I can say with a high degree of certainty that my
code will work.
JSF and JSP
Model2 are not the same when you enter a project to build an application.
To put it simply, JSF slaps on a lot of additional coding that both helps
and hinders.
JSF is a custom tag library, simple as that. At the end of the day it
renders HTML tags. Again, simple as that. If you understand the code that
is executed when each tag is encountered, you understand the architecture.
Yes, I'm sure there are combinations of JSF tags that won't work quite the
way I expect, but I understand the basics so I'll be okay.
Heck, for that matter, it is recommended that you DON'T have
JSF and JSP tags on the same page because the results will be
unpredictable during the rendering process.
Do you know why this is, Aaron? Because the results are actually quite
predictable, they're just ugly.
See, the problem is that JSF tags collect information and then, at the end,
the JSF framework "emits" all the collected code. This allows complex
processing and interaction between different parts of the page. JSP, on the
other hand, is a single pass processor. It processes each tag sequentially
and, unless they are special, immediately emits the code to the browser
(they are in fact converted to out.print() statements in the generated
servlet). So what ends up happening is that all the naked JSP tags tend to
go out before the JSF tags they're embedded inside.
If you understand this, and how it works, you can probably work around all
but the most complex issues. Add to that the fact that EGL has a h:JspPanel
tag that essentially collects all the non-JSF tags so that they're all
emitted at the end (similar to f:verbatim, but easier to use), and most of
your problems go away.
I know your answer will be "In EGL you
wouldn't ever do that." - well, I disagree, you will need to "hack" at
some
point, but you will only be convinced of that once you actually come
across the need.
And I think you don't know enough to make that claim. Here's the situation:
you had a bad experience with JSF, and since you don't really understand how
it works you got caught in some junk. Happens all the time. You should see
me when I'm trying to punch through a Python mess. And so while I can tell
you that I don't like Python syntax, I can't tell you a good Python
framework from a bad one.
You, though, seem to be saying that, even though you haven't worked with
EGL, just because it uses a framework that you don't particularly like and
had some problems with, then by definition EGL will be hard to use.
It doesn't enter into your mind that someone could actually know how to make
the JSF framework work in a way that you were unable to. And so even though
you haven't worked with the tool, you insist that it's not going to work,
because you couldn't get JSF to work to your satisfaction.
That's a pretty bold statement.
So go ahead, diss me again, baby. Make my day <grin>.
It is never my intent to "diss" anybody on this list. Was my last comment
meant to be humerous, yes - all business right? I have seen your JSP
Model 2 code (you came onsite to my previous employer, remember?).
Oh yes, Aaron, I remember. I remember that very, very well.
Very nice, and
fast, framework - btw, I have some suggestions for it if you have the time
someday. I have no doubt that you will be able to accomplish the same
with EGL, but I am guessing it will take some custom component/framework
writing to accomplish that base on my experience.
And I'm telling you that, based on my experience, IBM has done a great job
of integrating the JSF architecture. Now that we've settled the
conversation down, let's do something a bit more concrete.
Why don't you give me a list of things that you think I will not be able to
do in an EGL environment. You'll probably be able to come up with some
things that won't work nicely in an EGL page, and my counter to that will be
that it might require a hand-crafted servlet or JSP. My guess though is
that the majority of those things will not be standard form-based browser
interaction with the user, but instead will be more utility functions such
as uploading a file or transmitting a PDF.
But let's see if you can come up with something that EGL can't do. Until
then, quitcherbitchin.
Happy Turkey Day!
Joe
midrange.com
