When will JSF have a tool: I think the answer is 2004, but this is the wrong list for this.

Is there something in .NET that can do this like there are dozens of tools for Struts:
http://www.scioworks.com/scioworks_camino.html


I also just started using an open source bean generator that writes Struts bean getters and DAO.

I would say that Java has little advantage over C#.
Business managers would prefer .NET.
J2EE has mislead application developers in the past, Ex: EJB, which lead lots of bus. users to .NET.


I would hope that people do not use JSF as best J2EE has to offer. I think the best J2EE has to offer is Open Source tools like Struts.
Ex:
http://news.netcraft.com
This shows how much more MS is popular than Sun.
But it also shows how much more popular OS is than MS.


So my argument has been that MS > Sun, but Open SSource > MS.

I say that Struts + JSTL + IBatis + OO Programer can code circles around best .NET combo. I am willing to prove it any day or night, even via the web.

Then lets talk cost to operate:
MS tends to be cheaper than Sun. But... OS is cheaper to operate than MS.
Same for support. I go seach struts mail list: "validate date" and it shows like 1200 times people asked this question.
So I say... past is the future. OS > MS > Sun


Please do not put forth JSF as "best" of J2EE, it might be best Sun has (like they have iPlannet, NetBeans, SlowLaris, should I go on?).

I "sell" consulting; and clients feel better when of the bat I say, yes, .NET is better than Sun.
Then I sell Open Source. They say.... you can save us money?
YES! I say.
How popular is this?
http://news.netcraft.com I say.
Oh. they say.


Now I have offense.
I say: let me show you how quick I can write an 2 screen master detail app., with a nice UI.
Ren *.HTML to JSP.
Write actions to go to JSP!
Add tiles/menu.
Demo one. Est time. 5 minutes for 2 screens.
I say, can your graphic artis using Dream Weaver customize this? Yes, they say, they like their logo bigger, and they like colors!
(At this time, client thinks I am done - I did not do beans yet, they do not know what beans is or why we need it)
I say: How would you like not to have to get legal approval and no buget meetings! Maybe get a little raise instead.
Then I say, ok, lets make some reusable comonents (beans) that could get used by Soap, Flash, and elsewhere in the app and test in your app with data.
DAO, 5 minutes, they like stored procedures usualy. (Last time they saw a DAO, it was EJB and... they say, wow, Java got better.)
Beans (I have getter/setter macro) 5 minutes.
Show Unit test of beans talking DAO !
I explain Soap, Flash compoents, and their web app. and ask for a PO and sit there while they glance at each other!


Do they want to talk iReport.sf.net. Great, they have a wizzard. Stress test? Disel Test! Demo? no, they have seen enough.
What is your pain I ask? How many screens can your developers do per day? Do you want me to teach them a few OO tricks?


So I never argue #C vs Java. I absorb the punch and allways agree with client.... and agree that they should use popular tools that save money for the org.

Good luck selling! But.. if you ask more Sun JSF questions, there is JSF mail list on the Sun site.

.V


Davidson, Glenn wrote:
Chris, Thanks for your response, I find many of your arguments and others
compelling. Please note that I am working with Struts when I had the
opportunity to work with .NET. (Just what does that say about me? :-) )I
agree with the majority of what you wrote and probably didn't fully
understand the parts I might have issue with.


The issue here is the perception by the majority of the business world. I
will be using many of the issues raised here to try and to get more
acceptance for Struts/JSP.... If you need any proof of the business
acceptance of .NET just look at the job sites for web developers and see how
many listings are for .NET and how many are for Struts/JSP etc.

I have used the argument that

"Real productivity lies in the ability to provide rich, complex
functionality that supports real people in getting real things done."

the .NET heads ( is there a term used to describe them? ) come back and say
that it is easier and faster to build in C# then Java. They say that the
tools to work with C# are better ( I don't agree ). In fairness, we should
not assume that .NET developers are going to skip design or write GUIs with
no functionality. We should look at the total cost of development.

I must take issue with your point that
 "It's this complexity that goes begging when UI construction is the sole
(or even majority) measure of productivity."

The fact is that as of right now you can build and maintain a GUI using .NET
faster and easier (read productivity). You can build rich and complex
functionality using C#. The building the business functionality is basically
on par between Java and C#. Is it not fair to say that the productivity
gained in the GUI construction is a clear win for .NET?

If you take two groups one for Java/Struts/et. al. and one for .NET, where
they are equally proficient in their respective technologies, and give them
the same application to build, which will be done first? Bottom line who
gets the job done first? The business world has decided that the .NET team
will be done first. From what I have seen myself I have little reason to
doubt this.


I have made the argument about how much richer Java is as a language, and
what I hear back is that the difference between Java and C# is like the
difference between Coke and Pepsi. Again, perception is reality.

Good tools do have a direct impact on development schedules. When are we
going to have JSF and the tools to support it? Are the anti-Microsquish
league (IBM, SUN, Oracle, et. al.) going to come up with tools to match
..NET?


Lastly, one of our teams here is writing a .NET front-end talking to Web
Services supplied by a Java J2EE middle tier. The say they are having their
cake and are able to eat it too. The interesting thing is they are
succeeding and are getting their applications to the users faster and
management has noticed.

Glenn


-----Original Message----- From: Chris Gerrard [mailto:[EMAIL PROTECTED] Sent: Friday, June 13, 2003 1:48 PM To: Struts Developers List Subject: RE: Struts can't "get its act together" - JavaPro


Glenn,


I'm continuously unimpressed by the implicit assumption that "Developer Productivity" == "GUI construction". The blind acceptance of this hoary old chestnut has been a huge impediment to real progress in developing better systems.

Given that the rapid construction of a UI is a good thing, what's my beef?

Simply put, there's a whole world of complexity behind the UI that needs to be conceived of, designed, and implemented before the application is useful. It's this complexity that goes begging when UI construction is the sole (or even majority) measure of productivity.

There are levels of productivity. GUI building is on the surface, easy to see. But it's thin, and not nourishing. Real productivity lies in the ability to provide rich, complex functionality that supports real people in getting real things done.

GUI tools tend to concentrate on the thin layer on top, providing some hardwired mechanism(s) underneath to support the UI. This is an extreme limitation in real productivity in that it limits the access the developers have to the underlying bits. Struts provides the framework that lets us deal with the UI and get past it into the Java world where we're really limited only by our own skills and knowledge.

Like Vic said in his post, I provide training in Struts (and other stuff) to corporate clients. I recently mentored a bunch of mainframe programmers starting up with Java/Struts in order to reimplement their existing FoxPro application. It's a simple customer info collection application - get some info into a form, save it, find it, update it, save the changes. The UI side of things is straightforward with Struts, as it would be with other technologies. BUT, real complexity lies unspoken in the "find it" functionality.

The naive approach is to provide a single-field input form accepting a client ID# which is used to look up the info. Next up is the "search form" approach: "Let's give them a form that looks like the input form, let them fill in some value(s) and then search for their info". OK, now we're talking. What fields are on the form? How do the values entered interact with one another - implicit ANDs or ORs, or do we try to give them a real query builder? And so it goes. Even better, as the user population gains experience with the application, having a flexible powerful language and platform underneath employed via strong, supple frameworks and architectures makes it much, much easier to continually improve things than is the case for systems built from GUI-oriented tools lacking Java's access to the machinery.

Up until now the Java world has concentrated on core technology, and thereby enabled core productivity. Struts has brought us up to the surface, and things have always improved. I'm really hoping that JavaServer Faces will provide the rapid UI-building experience other tools and technologies enjoy. Once that happens the world will change. It'll be Java all the way
down.


Chris

At 03:14 PM 6/11/2003, you wrote:

Chris,
I tend to agree with your assessment of JavaPro but I'd like to open this

up


a little. Right now we are faced with two choices for web development .Net
or not .Net. I can over-simplify the arguments for and against .Net as the
following:

.NET
Pluses
Developer Productivity
Negatives
Vendor lock in.

Others (including Struts)
Pluses
No vendor lock in
Negatives
Less developer Productivity

It seems like many if not most companies are more interested in developer
productivity.

Does anyone know of, or foresee any means by which we (developers) will be
able to be as productive using Struts/JSP/DHTML/JavaScript etc. as people
are using .Net? I'd love to be able to make a case against .Net .

Thanks

Glenn


-----Original Message----- From: Chris Gerrard [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 11, 2003 12:07 PM To: [EMAIL PROTECTED] Subject: Stuts can't "get its act together" - JavaPro


I found this announcement today on JavaPro's August Issue online "In Brief" site: http://www.ftponline.com/javapro/2003_08/magazine/departments/inbrief/defau

l


t.asp

The blurb:
Developer Tools
TurboM2
Tired of waiting for The Apache Group to get its act together with the
Struts initiative, Virtuas has launched a framework of its own. Virtuas
released TurboM2 previously under the name Web Application Model (WAM).
Since then, the company decided to alter the product to perform many of the
features Struts offers, and like Struts will be released under the open
source model.

There's more, but on casual inspection it appears that JavaPro has simply
regurgitated some marketing poo from Virtuas intended to convey the
impression that Struts is in a funk and not moving forward. (so one should
naturally move to Virtuas' TurboM2 product)

Upon casual inspection it appears that TurboM2 is a fairly direct clone of
Struts. On of Virtuas' value-added claims is that TurboM2 has available
support and training that Struts does not.

Links:
Virtuas TurboM2: http://www.turbom2.org/index.html
Struts/TurboM2 comparison: http://www.turbom2.org/docs/Comparison.pdf

The part that disturbs me is JavaPro's presenting this whole pile as if it
were truth. Someone reading this article could well be persuaded that yes,
indeed, Struts is in trouble and they should look elsewhere. I've been less
than impressed with JavaPro's content for some time, and this erodes my
confidence in their editorial control and knowledge of the Java world even
further.




---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to