For more general purpose use (such as in the business tier), doesn't RowSet already do everything you need? I've heard it argued that this can be the standarized DAO interface you are talking about.
What if the Data Feed is MQ, or Soap? RowSet has all this other mechanisam that gets in the way. Also disconected rowset for Oracle works a bit dieferent than RowSet for pgSQL, etc. So porting from SQL to SQL will depened on RowSet driver, ouch. DAO interface can be tabular like disconected rowset, but based on Collections.
JSF (as you know :-( ) I personaly consider propriatory. Once I see the real production license in 1.0 release by Sun or others, I will re-consider.
It's under exactly the same terms as the Servlet API, or JSP -- for example, you cannot ship a Servlet 2.4 container today, because Servlet 2.4 is not yet final. Yet, we all know that it *will* become final, so we can plan ahead on how to leerage it when it's released.
TC5.02 has been release as has Resin 3.1.
bP today downloads with TC5 and Resin 3.0 integrated, both have a great license.
2nd, JSF makes some architectral mistakes that remind me of EJB. I could write another long letter to the JCP, but too late, the comitte is locked. Short story is that Java Everywhere plan will *not* work for GUI, UI must be browswer, not Java, and not by a Java Developer but by graphic artist. (As proof, I could show you some sites I designed the GUI for :-) ). Also, I sincerley, but maybe naivley, think that JSF push by Sun will push Java Developers into .Net. Nothing in version 1.0 will fly, look how Struts was allowd to grow in 0.6 in a shade. If my clients balk at JSF, I have no choice. Diverting Apache Struts users to Sun JSF is not a great idea.
Your argument is pretty ironic, given that even Microsoft provides mechanisms to programmatically create and modify UI components (using VB or C# or whatever), so obviously there are at least a few people in the world who differ on "UI must be browser". :-)
Rich UI should not be Java, even if miniroity think it. We can agree to disagree, but I think that is where JSF misses. Masses are fickle.
I think JSTL is a great direction, and JSP 2.0 is great (KISS). If a data grid was based on JSTL more, would that suffice?
No.
JSP and JSTL exist only at rendering time (what JavaServer Faces calls the "render response" phase of the request processing lifecycle). That does not provide any opportunity to perform event processing and/or server side validation, which any robust UI framework needs to support.
Further, page authors need to be able to think of a DataGrid as a single "thing" they can manipulate, and concentrate on look-and-feel issues, without worrying about things like the iteration and result set scrolling that would have to be explicitly dealt with if you're doing it the JSTL way. Sure, you can create something like the Pager tag library that makes this kind of thing possible today, but still exposes lots of the plumbing.
If in JSF the Java Developer in a JSP creates a bean, populates it and then uses DataGrid for UI.... then they are worying about pluming more so than Model 2; but I do not want to be confused for someone who wants JSF to get better :-). HTML was not meant for the complex forms we do now, and it can't be fixed at the server, but up close.
This is what "we" Model 2 people used to do in Struts in the days of Java, before JSF came and paved the way for .NET: :-)
In action we create a bean a populate it and put it in request, then the display tag in JSP access the collection and displays it using CSS styles. Any pageing is done at the Data Layer (DAO) where page down, page up data can be cached (data cached at data layer, not view layer).
If JSF is not at some DAO level, but at a RowSet level... one would have to cache data in the view or controller for pageinator.
JSF needs to be more open, scaleable, rich UI (right now not even Javascript support).
I thought you said that Struts should *not* have a UI at all, and concentrate on the controller tier? Make up your mind :-).
I think Struts should stay View agnostic. (Why not add EJB to Struts? same argument, it is contraversial, ex: Bitter EJB) JSF could become an anti-patern.
No matter how much people like you like to diss EJB, it's been the basis for more than a few successful application deployments in large scale, high availabililty, production environments. Whether you like it or not doesn't matter much to me ... there's enough people that do to have built an entire app server software industry around it.
It wouldn't bother me at all for JavaServer Faces to have the same kind of effect, and it still won't matter much to me whether *you* like it or not :-). It's clear already that more than a few vendors are taking it seriously enough to build product around. It's clear already that lots of users like the direction. There's already a SourceForge project (MyFaces) pretty far along at an open source implementation. There's already more than a few books underway that will help developers understand how to use JavaServer Faces. And we're not even to Proposed Final Draft yet.
I will take "anti-patterns" that are that successful any day of the week :-).
Yes, in my eyes, EJB was bad for J2EE, and made Java develoers look bad (relatively slow, relatively complex). JBoss 4.x ships with JDO now, and "Bitter EJB" book and aproaches are more openly talked about, people use people use Hibrenate and iBatis, there no EJB components I can think of. So people paid run time fees, say $5K per CPU, and ... then they would not use major features.
That is the analogy I see with JSF. The thing is back in EJB 1.0, there was no .NET, and now there is (http://www.datagridgirl.com/customcolumns.aspx) .
If JSF is sucessfull like EJB is, there is a choice now, and I do now want to be embarased as a Java Server side developer, I would rather switch.
(http://www.borland.com/csharpbuilder/demo/CsharpBuilderDemoShort.htm)
I do feel sad. In my own mind Craig is not able to persuade the JCP comitte to simplify JSF and make it client side. I can imagine a design by comitte, and someone try to reason with them.
(I know Craig, JSF could be use browser side rendering, like we do not need to use Enity Beans, only Session Beans, and maybe a graphic artist learns JSF, and we figure how to "optimize" calendar, and tree controls .... )
Books by profesional authors that do not have production track record and only document API are opinionated and not much use.
So lets say this is what JSF is, simplified as a faces tag: http://jakarta.apache.org/ecs/index.html That is all JSF is, Java GUI.
Why not do Tapestry or 10 others as a view. ( I am using Flash more and more, since it can also talk to C# via XML)
With most web applicaton frameworks (and, to my limited understanding of Tapestry it follows this model), whatever UI component support they have is generally NOT available stand alone; instead, it is integrated into, and assumes the use of, the rest of the framework as well. Being view agnostic works great when you're talking about not dictating whether to use JSP or Velocity or FreeMarker -- it doesn't work so great at the component level in a page where the components assume infrastructure on the server side as well.
Jstl 1.1 is Apache license.
One particular implementation of JSTL is Apache licensed. It's not the only one in the world. That's the nice thing about specs that can be implemented by multiple folks who compete on quality but have to ensure compatibility.
What if JSF RI has run time fees, or can you state now for a fact that Sun RI will not have any run time fees?
The RI for JavaServer Faces will be redistributable and usable in commercial environments once the spec goes final. Further, JavaServer Faces is on the list of JSRs for which Sun has guaranteed support, and even scholarships, for non-profit organizations that want to implement JavaServer Faces and then test their implementation for compatibility with the TCK (again, just like Servlet, JSP, JSTL, and others).
So can we stop with the FUD about licensing now ?
I .. am not smart enough to figure above out, so let me restate in my words what I understood from above: Sun JSF RI might have run time fees, but non Sun JSF might be free run time and would not have to pay for TCK only? (I can't see the SF.net guy paying Sun to get the TCK, so Sun might give him a grant? ) That is why I say, I want to wait till 1.0 is out, so I can read the license.
I have to pass architectures by legal and budget approval. And then I have to explain why not DataGrid from www.asp.net.
Yes, 2.0 rules.
But you can't use it yet -- it's still an EA license, and nobody can ship a final product that claims to implement it.
TC5.02 has been release as has Resin 3.1.
bP today downloads with TC5 and Resin 3 integrated, both have a great license.
> Guess we should wait until JSP 2.0 goes final to decide whether we want to
> use it in Struts :-).
Programmers don't have *small* egos. If JSF support, then JSP 2.0 or at least JSP 1.2.
Did I say that it be good for ASF, J2EE, Java, and world peace if Struts treats JSF like EJB. You can do it, here's the docs, but good luck.
JSF is GUI in Java, for those who think this is great and should be allowed like EJB is, but not encouraged.
The reason I like Struts is that it is simple, fast, open.
Thanks Craig!!
.V
Craig
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
