I am trying to learn java web programming. I come from a perl scripting background and know very little Java, much less JSF/Seam/EJB3.0. I've made a LOT of progress in this very steep learning curve, but there are some large conceptual issues that I think are hampering me a bit.
Lately I've turned my attention to learning JSF. Usually discussions of JSF include a description of component-based web programming, but seem to assume one has experience with the other paradigms of web programming. I would be interested to see a fuller discussion of this component-based paradigm in the context of other paradigms.
Can someone explain?
Thanks in advance for your thoughts.
TDR
The basic idea is just an extension of Object Oriented Design: Separate the concerns of your program. The same way you may make several different PERL scripts and string them together to do work, we will make several different JSF components and string them together to do work.
Let's take a simple registration form as an example. I want to know your name, your birth date, your address and submit this all to the back end to do work.
First thing we need to do is break up your form into logical pieces. If we knew we were going to reuse this exact form in a lot of different places, maybe this form itself would be a logical piece. In which case we could create a component that would render this whole form and tie it to a bean like "Contact." That way, any time you needed to use the form, you could dump it in, tie it to a Contact bean (the how would depend on your framework) and go from there. But that would make this a pretty dull example. :)
From my estimation I see name, birth date and address as three seperate, logical units. Name would probably be simple. Just a standard text input. So we can use a h:inputText element, or your framework's prefered version, and tie that to your bean's name field.
Second, we have the birth date. At its simplest, we can create a h:inputText field and add a f:converter element so that when we tie it to the bean, it will come out a date. You can scale this up to be a fully interactive calendar widget, complete with Java Script and what not. Check out IceFaces and RichFaces for some good examples. But the same core concept remains: A single component which you will tie to a date object.
Third, we have the address. This makes a great choice for a component, because likely you will need to know addresses in a lot of different pages. It's also a lot more complex than a single input. You'll need to combine multiple inputs, validations and fun ajaxy stuff to make a single cohesive unit. However, the developer who uses it will hopefully only need to do use
<foo:address value="#{BarBean.address}"/>
with maybe a couple of other options.
This seperation of concerns is at the core of not only Component based web design but object oriented programming itself. There are plenty of tools to make this easier too! Facelets is a great example. You can seperate your basic layout into its own sheet, simply injecting the useful content via the ui:define elements. You can create composition components that allow you to quickly create more useful components without delving into the JSF component framework; the address example would be very simple to do with a Facelets composition component. IceFaces is another good example. It handles all sorts of AJAXy type inputs, redraws and updates without me having to worry about how it all works (for the most part. ;) letting me focus on what the form is to accomplish, not how to accomplish the form.
This only scratches the surface but the broadest strokes are similar to any large program: Identify the smallest, logical pieces and build them before using those to build bigger pieces.
I think that a good explanation would take a lot of effort. I'd suggest to get first your java skills straight, so you can understand the code examples that you'll encounter later when you try to follow tutorials from the web or even better buy a book.
In short:
JSF tries to give you the programming experience of a desktop application for a web based app.
Instead of having for example big JSPs you have lots of smaller components, that you can reuse.
The state of the page is preserved as much as possible even you do a real request (not just an ajax call) by transfering the state of the DOM components to and from the server.
JSF and Java EE in general is designed in such a way that large teams can split up the tasks into a more modular form.
Therefore, with components, instead of having multiple people working on the same .jsp or .xhtml page and the same Java backing bean class, components allow people to work on the same application without tripping over each other's feet.
Related
How easily will Watir interact with a ZK interface? If "not at all" do you have any recommendations for automated testing of the web interface for me?
Edit: Another way to put this would be can I test a Spring/ZK generated page (Ajax/JScript). I found another issue too: I need not to use a proxy to test (like Sahi does) if at all possible.
Edit: I have been testing ZK interfaces now for quite some time. With a higher knowledge of Watir (and now webdriver) I can say it's definitely possible. Timing isn't usually an issue, but finding the elements certainly can be as the ids are dynamically generated. I recommend a strong, maintainable, object oriented approach with a powerful and dynamic DSL, or you'll be listing every element on the page in a custom built object library of some sort. So... it works, but it needs extra effort.
If you're talking about this: http://zssdemo.zkoss.org/ you can take a look at the DOM output, it's atrocious, but possible to test it with Watir. I've dealt with some apps that generate awful output like that. It makes for a challenge. :) Search the Watir google group for testing Ajax, plenty of people do it.
HTH,
Charley
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
Are there any up to date articles comparing JSF 2 and Tap 5? Everything I seem to find is comparing JSF 1.2 and Tap4.
Does anyone have any experience with T5 or JSF2 and time to evangelize one or the other?
I'm looking for a framework for rapid development in Java, on top of Hibernate and mySql.
Other framework sales pitches accepted, but JSF2 and T5 are currently our top picks.
I've worked mostly with Tapestry 5 over the last few years; I won't evangelize though. Choosing a good web framework is certainly a good idea, but usually not your prime problem.
A list of good and bad things from the top of my head:
Tapestry 5 has a rather steep initial learning curve. There's magic and metaprogramming happening everywhere. You could argue it's overdoing convention over configuration.
Simple stuff is very simple to do, harder stuff requires you to understand in detail how Tapestry 5 works and can be hard if you don't (yet).
I love the live class reloading. You change something in a T5 component or template and you see it right away. Really useful when your app does a lot of stuff and takes 30s+ to start in Jetty.
Tapestry does not support dynamic page structures. This is usually not a problem, but if you're developing some kind of portal solution where people can individually arrange components, don't use Tapestry. Tapestry is for static structures, which it handles really well.
Tapestry has beautiful URLs. package/page/${param1}/${param2} ...
Tapestry uses the proper HTTP verbs to do stuff. A link is a GET, a form submission is a POST, the post-redirect-get pattern is the norm.
Tapestry's community is not very large. Apart from Howard Lewis Ship, there are a few other committers, but nothing like the support Wicket has. Thus, Tapestry evolves rather slowly.
Tapestry's approach to templating (instrumenting HTML with types and IDs) is one of the better ones I've seen, but it doesn't go as far as Wicket in keeping code out of the HTML. On the other hand, the class files are less verbose. Still, I think the Wicket way is preferable.
Tapestry is somewhat under-documented.
I like Tapestry very much, I think you can be very productive with it, and I would always happily participate in projects where it is used.
I would, however, advise to also check out Wicket. It seems to have gained more traction than Tapestry and solves some problems less magically, but with a common sense approach.
(I've only briefly used JSF 1, which I found was completely off in just about everything it did: wrapping every request in a POST (thus breaking basic web functionality), using JSPs, but requiring to use special tags for everything, even plain HTML... I read a lot has improved in the JSF camp, but I can't tell, I've never looked at it again.)
Taking up your offer and pitching another Framework :
If you want really rapid development then you should look at the Play Framework.
I've used JSF/Richfaces/Seam/Hibernate etc and I'd say that using Play more than doubles your productivity. There are no deploy cycles. So no developer downtime. It's got JPA/Hibernate baked in and lots of plugins that extend it's functionality in other directions.
I also like the fact that it makes your pages so lightweight. My biggest issue with JSF was always the weight of the pages (unecessary IDs, lots of tables, client state etc)
Take some time and view the webcast.
Check out my presentation JSF 2.0 vs. Tapestry 5: A head-to-head comparison at Jazoon 2010. This might help you to make your decision.
As Tapestry committer I would advise you to choose Tapestry, but I think the best way to make the decison is to give both a try. Need more demo applications?
https://github.com/drobiazko/tapestry5inaction/tree/master/tlog
Most important Tapestry 5 feature for me is the flexibility of the framework. You can override almost every piece of code inside Tapestry's core, thanks to Tapestry IoC.
Don't look to me for an unbiased opinion ... Tapestry has been my life for several years now, and I continue to love it.
That being said, the learning curve is getting less steep, the documentation is improving rapidly, and Igor's book is just around the corner.
Some of the things that confuse people are simply lack of documentation; for example, the naming conventions are optional, there's always more explicit configuration (in the form of method annotations) that some people are more comfortable with.
To address a couple of Henning points:
Tapestry component templates are, by design, static (and this is very important to Tapestry's scalability and clusterablity story). However, an add-on that's part of my TapX library supports dynamic external templates that fill the gap.
Also, if you want to keep your templates maximally spare, you can do that too, such as:
<form t:id="myForm">
... in the template, with the remainder in the Java class:
#Component(parameters={"zone=target", "clientValidation=blur",
"context=client", "secure=true")
private Form myForm;
.... in other words, all the Tapestry specific content out of the template and into the code. Not ideal for trivial components (more switching back and forth between template and Java source) but great for keeping the worlds nice and separate.
I've been pretty pleased with Tapestry. It is a different approach than what most people are use to. It uses a lot of the same paradigm as WebObjects (what the iTunes store is built on).
Tapestry does a very good job of minimizing the amount of code you have to write to accomplish a task. This is great once you know what you are doing, but it can be frustrating at first while you are learning the naming conventions because some stuff seems to magically work and other things won't because you named wrong.
One of my favorite things about Tapestry is how little XML is required. For example, if you create a Hibernate entity, you place it in the com.example.entities package and give it the #Entity annotation. There is no other configuration necessary--no XML, no adding the the class name to a file somewhere, etc.
I'd highly recommend taking a look at actual code to see what you think. Here are a couple suggestions:
wookicentral.com/
github.com/spreadthesource/wooki
tapestry.zones.apache.org:8180/tapestry5-hotel-booking/
github.com/ccordenier/tapestry5-hotel-booking
Also take a look at the jumpstart site. It contains a number of examples along with the code showing you exactly how to use most of the various components. It also contains a starting point app that gives you some user management features if you want to base an application on it.
jumpstart.doublenegative.com.au/jumpstart/
Also check out the revamped Tapestry documentation. It isn't posted on the main site yet, but it is already a very big step forward:
people.apache.org/~uli/tapestry-site/
Use JSF 2, particularly if you make use of Java EE 6 features. If you want to have fancy UI, try Primefaces.
As per your requirement, the important part to consider is that you're using MySQL, and that's it. Therefore, take if from different angle. You're using JPA2 (and your persistence provider happens to be Hibernate in this case). With this approach, down the track you can quickly very easily 'swap' your persistence provider or database you're using.
Looks like Java EE 6 solves it.
Here's a pretty good comparison of Tapestry 5 and JSF 2
http://blog.tapestry5.de/wp-content/uploads/2010/06/JSF-2.0-vs-Tapestry-5.pdf
Note this was put together by Igor Drobiazko, a Tapestry 5 comitter
I love this question about Tapestry. Maybe it will influence your decision.
My question will be hard to form, but to start:
I have an MFC SDI app that I have worked on for an embarrassingly long time, that never seemed to fit the Doc/View architecture. I.e. there isn't anything useful in the Doc. It is multi-threaded and I need to do more with threading, etc.
I dream about also porting it to Linux X Windows, but I know nothing about that programming environment as yet. Maybe Mac also.
My question is where to go from here?
I think I would like to convert from MFC Doc/View to straight Win API stuff with message loops and window procedures, etc. But the task seems to be huge.
Does the Linux X Windows environment use a similar kind of message loop, window procedure architecture?
Can I go part way? Like convert a little at a time without rendering my program unusable for long periods of work?
Added later:
My program is a file compare program (sounds simple enough.) So, stating my confusion in a simple way, normally a document can have multiple views, but in this app, I have one view with multiple (two) documents (files). I have a "compare engine" that I first wrote back in the DOS days, that is the heart of the program and the view is just looking at the output of that routine. Sometimes I think that some of my "view" code could make sense in a "document" class but I hardly know where to begin to separate it into more classes. I have recently started reading "Programming Windows" 5th Ed. by Charles Petzold, (I know that is quite out of date (C) 1998) hoping to get a better understanding of direct Windows programming.
I get overwhelmed with the proliferation of options like C#, NET, MFC, MVC, Qt, wxWidgets, etc.
I find I am often stuck trying to understand something going on in the MFC framework because something in my code doesn't work as it seems it should, but the problem is that I don't really understand how MFC is handling things in the background. That is why I am trying to learn "straight Windows programming" where my program has all the message passing code that I write. I hope this helps give enough insight into my question so someone can guide me on my way.
X works enough differently that a raw Windows program and a raw X program probably wouldn't be able to share much UI code at all.
If you want portability between the two, chances are pretty good that you want to use something like Qt or wxWidgets. Of the two, wxWidgets is more similar to MFC, so it would probably require less rewriting, but would maintain (more or less) the same "disconnect" you're seeing between what you want and what it provides.
Without knowing more about your application, and why it doesn't fit well with MFC, it's impossible to guess whether Qt would be a better fit or not. An immediate guess would be "probably not".
MFC uses a "document/view" architecture, where Qt uses the original Model-View-Controller architecture. For the most part, MFC's Document class is equivalent basically a Model and a Controller rolled into one -- so if your Document contains nothing useful, in Qt you'd apparently have both a Model and a Controller, neither of which did much that was useful.
That said, I have to raise a question about why your Document currently doesn't do much. The MVC pattern has proven applicable to a wide variety of problems, so while it's possible it can't work well for your problem, it's also possible that it could work well, and you're simply not using it. Without knowing more about what you're doing, it's impossible to even guess at that though.
Edit: Okay, the clarification helps quite a bit. The first thing to realize is that a Document does not necessarily equate to a file. Quite the contrary, a document can perfectly reasonably relate to an arbitrary number of files.
Just for example, consider a web browser. All the data needed to compose the page its currently displaying would reasonably be part of the same document. Depending on your viewpoint, that's either zero files, or a whole bunch of them (it will start as an arbitrary number of files coming from the server(s), but won't necessarily be stored as files locally at all). Storing any of it as a file locally will be a (more or less) accidental by-product of caching, and mostly unrelated to browsing per se.
In your case, you're presumably reading the two (or three?) files into memory and storing them along with some sort of data structure to hold the result of the comparison. After the comparison is complete, you might or might not discard the contents of the files themselves. I think it's safe to say that the "normal" separation of responsibilities would be for that data and the code that produces that data to be in the Document.
The View should contain only the code to take that result from that data structure, and display it on screen. Nearly the only data you normally want to store in the View would be things related to how the data is presented (e.g., things like a zoom level or current scroll position). Likewise, the code in the view should relate only to displaying the result and reacting to user input, NOT to "creating" the data in the first place.
As such, I think your program could be rewritten to use the Document/View pattern more effectively, or could be rewritten to use MVC. That, in turn, means a port to Qt could/would probably work just fine -- provided you're willing to put some time and effort into understanding how it's intended to work and then make what may be fairly substantial changes to your code to work the way it's designed to.
As I commented previously, wxWidgets is more like MFC in this respect -- it uses a Document and View, not a Model, View, and Controller. It's also going to work best if you do some rewriting to separate responsibilities the way it's designed for. The good point is that it's probably a bit easier to do that one step at a time: rewrite the code in MFC, which which you're already familiar, and then port it to wxWidgets -- but given the similarity between the two, that "Port" will probably be little more than minor editing -- often just changing some names from C* to wx* is just about enough. To my recollection, the only place I've run into much work was in creating menus -- with MFC they're normally handled via resources, but (at least a few years ago when I used it) wxWidgets normally directly exposed the code that created the menu entries.
Porting to Qt would probably be more work -- you pretty much have to learn a new framework, and substantially reorganize your code at the same time. The good point is that when you're done, the result will probably be somewhat cleaner, though given what you're doing, the difference may be pretty minor. In a Document/View, the View displays data, and reacts to user input. In a Model/View/Controller, the View only displays data, but user input (that modifies the underlying data) goes through the Controller. Since you (presumably) don't expect to modify the underlying data, the only user input involved probably belongs in the view in any case (e.g., things like scrolling). It's barely possible you might have a few things you could put in the Document/Model that would be open to change (e.g., things like the current font or colors the user has selected).
Is there a workaround for implementing cross cutting concerns without going into aspects and point cuts et al.?
We're in Spring MVC, and working on a business app where it's not feasible to go into AspectJ or Spring's aspect handling due to various reasons.
And some of our controllers have become heavily bloated (too heavily), with tons of out-of-focus code creeping in everywhere.
Everytime I sit down to refactor, I see the same things being done over and over again. Allow me to explain:
Everytime I have to prepare a view, I add a list of countries to it for the UI. (Object added to the ModelAndView). That list is pulled out of a DB into ehCache.
Now, initially it was terrible when I was trying to add the lists INLINE to the mav's everywhere. Instead, I prepared a function which would process every ModelAndView. How? well, with more garbage calls to the function!
And I bought out one trouble for another.
What's a design pattern/trick which can help me out a bit? I'm sick of calling functions to add things to my ModelAndView, and with over 3500 lines of only controller code, I'm going mad finding all the glue points where things have gone missing!
Suggestion are welcome. Cross cutting concerns flavor without AspectJ or Spring native.
Since you are using Java, you may consider moving your code to Scala, since it interacts well with Java, then you can use traits to get the functionality you want.
Unfortunately cross-cutting is a problem with OOP, so changing to functional programming may be a solution, but, I expect that in actuality they are using AOP to implement these mixins, so it would still be AOP, just abstracted out.
The other option is to look at redesigning your application, and make certain that you don't have duplicate code, but a major refactoring is very difficult and fraught with risk.
But, for example, you may end up with your ModelAndView calling several static utility classes to get the data it needs, or do ensure that the user has the correct role, for example.
You may want to look at a book, Refactoring to Patterns (http://www.industriallogic.com/xp/refactoring/) for some ideas.
I've been evaluating different Java Web Application UI Frameworks. I have about 8 months of intensive JSF experience that I'd like to continue using. JSF also provides me the spider-readable markup as well as the ability to create very simple forms without touching much Java code.
I also will have need for thick-client side interfaces that will perform well with few server round trips. GWT seemed like an ideal choice for this.
So, when I found G4jsf, I thought I had found the best of both worlds. However, I can't seem to find any active development on it. I hope it hasn't died, but it seems like that is the case.
Is there active development on this? Or am I two years too late?
Well, based on the conversation in the reference below, it seems that G4jsf is no longer being supported. If the poster is in fact Sergey Smirnov, I would imagine he'd be a pretty reliable source on the matter. :)
http://www.jboss.org/index.html?module=bb&op=viewtopic&t=150674