Am Freitag, 10. Oktober 2003 21:09 schrieb Chen, Gin: If I also may share my thoughts about this all here: Well, I'm doing not only Java or J2EE, but was alo forced upon the role of chief developer for our 'main' product (which is a traditional C/S application written in Delphi) some time ago. Now Object Pascal definitely has its lackings from a designer's view (unlike Java, it has no interface datatype rsp. interface means: COM interface, at least something with GUIDs associated), but one thing has really converted me from being a C++ addict; formerly convinced that the power lies in language constructs; and that's the inherent power of Components itself. When coding for Delphi, Compo- nents are just everywhere, and Object Pascal, as most Apple innovations, is a truly powerful OO language. You can do great things in Delphi. The downside, still, is that Components don't make you a better developer, so there's a lot of room for those quick- and-dirty hackers usually located more in the VB direction. That's the drawback of ease-of-use: you also leave room for the otherwise-illicits. But that's just the trade-off of abstraction in general.
Still: Components are the future, if you like it or not, things are generally tending the more to the abstract the more complicated the under- lying problems and technologies get. It is basically inevitable, as the restrictions of the human mind necessarily require abstraction (as it can handle just up to seven different topics at a time; this is rather well-researched by other disciplines) demand for this. Now look at UML and the MDA approach that is currently the flagship of OMG. Look at both J2EE and .NET. Both technologies were clearly influenced by a book named 'Business Component Factory' released in 1997 (as I lend it to a friend, I fail to cite the authors here), but it's important nonetheless. Note that Components don't mean Delphi Components (which are basically just normal Object Pascal classes) J2EE beans, COM objects or something like this, but may deal with entire, pre-fabricated encapsu- lations of common business processes in a standard way. Components, though there's no common definition for this term, are the next step in evolution to the OO paradigm (and be honest and ask yourself - ten years ago, what did you really think about Objects and C++?) I personally remember times when I thought C was a commodity language for lusers who didn't know Assembler, held C++ for being inferior to C for the resulting .exes being bigger and everything seemed to be much more complicated and the like. I've personally seen all this before. The last time when I had just the same feeling was when JSTL was released and Java scriptlets became more or less 'banned' in terms of proper coding. This was in 2002, actually. Though I didn't like it at first (I'm a Java developer in the first place, and developers write code, wasn't it so?), I more and more acknowledged the value of the JSTL approach, ending up in recently issuing an internal rule that all scriptlet code should be banned from all View pages in favor of JSTL tags unless there's a well-justified reason for it. Now, finally ending all this endless line of aphorisms, how does it fit into the Struts and JSF picture I originally wanted to write my thoughts about? Well, to sum it up in short: today, I know, like and favor Struts above all other frameworks, and it's always hard to leave the things behind that have you have become familiar with over time for something better or more advanced. I also admit I don't know very much about JSF yet apart from the basic ideas, but I spot similarities to ASP.NET and it somewhat fits into the general picture explained above, and I somehow suspect it can't be just coincidence that the web tier seems to generally go this way. Then, Craig is the specification lead, after all, and from what I get, he says that it will be good. I have no reason to distrust him or other people in this direction or think I know better. All I can say at this stage is that Struts works fine, it solves my everyday problems in a tightly-bound- to-HTML-and-JSP way, supports a proper MVC architecture if applied right, and so I currently don't feel lacking anything. But then, I was also content with TASM 15 years ago. So, finally, JSF deserve a real chance. From a design standpoint, the overall approach of JSF seems to be superior to a tightly protocol-related imple- mentation like Struts. And whether it's a good thing or not and if it fits our needs, we may decide in about two years. Just my 2 cents, -- Chris. > See.. Anyone reason that this should be kept public is to correct our > understanding of what JSF is really about. ;) > With the talks of JSF and it's UI/Action like capabilities it is no > wonder that we think of it as a possible alternative to Struts. To > use it with Struts seems to me as saying that you are using only part > of the functionality of JSF. Just like your using part of the > functionality of Struts if you use JSTL instead of Bean/Logic tags > currently. While it is probably a better solution than the Bean/Logic > tags, JSTL is still just and alternative to the integrated Struts > Bean/Logic functionality. > > -Tim > > -----Original Message----- > From: Craig R. McClanahan [mailto:[EMAIL PROTECTED] > Sent: Friday, October 10, 2003 2:41 PM > To: Struts Users Mailing List > Subject: Re: JavaServer Faces > > Chen, Gin wrote: --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
