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.
Related
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 11 years ago.
I am a java software developer/architect and I like UML.
Saying that I also hate the java generated code.
I don't see any value trying to generate the skeleton of my application:
creating empty classes is really easy and I don't need a tool to do that
also I cannot reuse the generated code because the way it is generated makes it impossible to reuse
The dilemma for me is that my requirements changed so quickly that I need to be able to implement the new demand immediately into an existing code.
My problem is that if I generate my code from my model and then manually develop inside the generated codebase, I cannot generate code again using a model because my modification would be erased.
Except I copy/paste the changes back and forth. That is an enormous effort for too few results. Therefore I do not use MDD but still use a lot UML.
Could UML be successful in a project without MDD code generation ?
I am asking this question because I have a new boss who wants to introduce full MDD process with IBM RSA and today I prefer to have live code and model synchronization or merge with Omondo.
Why change a running and proven system?
Why systematically generate code from a model while I can do it directly in the code and just merge it later with the model?
Why get crap database code generation which cannot even be deployed while I can add stereotype in order to get java annotation and use them with hibernate to generate my database?
One of the reason for boss's change is to get a better project documentation in HTML format. I highly doubt this and think he is looking for more control on delivery and does not know what else to invent!
Other argumentative reasons:
Use a product from a large and stable company.
Have a full model available which could be deployed in any other language.
(This is why for me MDD is stupid because it is impossible to deploy on any platform any server, any database just from a model. So why to waste my time?)
Please give me some arguments in order to come back at next meeting and crash this stupid new MDD fan who wants to reorganize the way we work today!
I think your post has the answer in it.
MDD has been plagued with 2 fundamental problems:
An input (modelling language) that is insufficiently expressive to capture the entire problem. Result: you need to complete the specification with another language (code).
The generators - i.e. the rules that convert models to code - are generally incomplete and/or not open for modification by the development team and/or generate poor quality code.
Put those two things together and you get the horrible mess you mention. Consequence: trying to splice together hand-written code with poor-quality generated code. Result: not pretty.
However. Please don't surmise from above that I'm anti-MDD. I'm not - in fact the opposite is true. BUT: the tooling and process need to address the two fundamental issues above.
I've come across /very/ few that do. I used RSA several years ago and it definitely wasn't one of them. (However it's had the intervening time to improve, so it may be there now).
A simple "temperature check" question is to ask whether the tool provides a full Action Language. If it doesn't, it'll fall foul of problem (1). If it fails that, chances are you're in for pain.
If all your boss really wants is good HTML documentation, then simply integrate UMLGraph or apiviz into your build.
So to answer your specific question:
Can UML be used successfully without MDD? Yes. Generally in two ways:
As an informal or semi-formal notation for whiteboard sketching while figuring out the problem and/or solution (what Martin Fowler calls UML as Sketch)
As auto-generated documentation from the code as part of the build process.
Where you'll end up burning unproductive time is creating formal UML diagrams (often with an expensive tool) that have no direct link to the code.
hth.
If you cannot control the generation, you are probably using the wrong tools.
What you generate - skeletons or framework specific code - is also depending on the tool. Use tools which allow you to create your own templates.
It is wrong to assume roundtrip engineering will ever work. You cannot transform less detailed model to more detailed code and then back without losing information. One way to solve this would be having same level of details in models as in code, which is not a great thing.
Better approach is to use one way generation from models combined with some good practices for combinening generated and manually written code.
You can use protected regions for manually written code:
you specify in template places - e.g. method bodies, which should be not overwritten when regenerating
Or the generation gap pattern:
you generate abstract classes and code using skeletons of concrete classes, which you complete manually).
There is still one other way to approach this - full code generation.
It might look similar to the bad practice of coding using models, but the point is to specialize for generating certain kind of applications - web apps, embedded apps. What you generate is then basically a framework specific code, which can be often expressed and maintained using models.
Don't forget, that modeling is not just about diagrams, you can use textual DSLs as well.
To your question - UML was not originally ment for MDD (many MDD practicioners don't use UML at all...), so you can use it for OO analysis and design as you like.
When it comes to your boss and RSA, try to find out what your boss really needs and wants, then try to provide him some better tools or practices.
As mentioned in the other answer, there are many tools for documentation.
With MDD, making changes to the design hopefully becomes cheaper: if the requirements change, in your approach you have to update the UML-based documentation, and the code. Now, if the code could be automatically generated, the changes to the code should follow automatically from the changes to the model, and you wouldn't have to do it manually (at least in those places where you don't add new stuff or need to change the business logic).
Assuming that MDD works (yeah, right ;), could you justify the double cost of maintaining the model (for documentation and design), and the code?
One argument in your favour could be that if the project isn't too big (whatever that means), that it's not worth having all the overhead.
I have been using jQuery/Prototype/ExtJs and other frameworks for last two years. These frameworks have been very useful.
I switched to YUI recently and finding the learning curve a bit too steep. Also the framework is not making my life as easy as with Extjs or Jquery.
When I consulted several other developers no one seems to be very enthusiastic about YUI. Very few of them have actually used it. Of course this depends on where I stay and what kind of people I interact with but can I say safely that YUI is not beign received as enthusiastically as jQuery? Why is it so ?
NB: I'm an engineer on the YUI team! I think you ask a great question, something I have wondered myself.
IMO, jQuery is more widespread than YUI because it is easy to sprinkle it on web pages that need simple DOM manipulations and basic AJAX or animations. That said, YUI is an extremely popular library that has historically been a favorite of more advanced developers and application builders. We do have a huge and thriving online community on yuilibrary.com -- perhaps folks are too busy writing great code to make a lot of noise? ;-)
That said, we are hearing a lot of buzz these days from jQuery folks hitting the limits of that library as they transition from throwing together simple effects to needing more maintainable, performant, and well-architected code. YUI 3 takes you from the basics to the most complex applications without missing a beat. It is a world-class platform for novices, hackers, and application developers alike: a concise, convenient, and intuitive API that is lightweight and lightning fast, PLUS a well-thought-out infrastructure and comprehensive suite of tools to help you code like a professional.
I agree that the learning curve for YUI has been high -- we are in the midst of a website redesign and writing an O'Reilly cookbook to address exactly that issue. We're also hosting our second annual YUIConf this November to unveil our latest and greatest. We've coming a long way since the days of YUI 2 and we're excited to make it as easy as possible for folks like you to ramp up on YUI 3.
Akshar -- my response is YUI-centric, for sure, but the YUI developer community is huge, enthusiastic, and growing. Check out http://yuiblog.com/blog/category/in-the-wild for some of the implementations we've seen recently. In addition to what's out there in open source, the Yahoo! home page, Yahoo! Search, Flickr, and the upcoming redesign of Yahoo! Mail are all based on YUI 3, the next generation of the library -- which has been welcomed by developers as having industrial strength power along with the concision and selector-driven syntax that makes libraries like Prototype and jQuery so fun to use. My advice: Try it out. YUI 3 is a unique, incredibly powerful library, and its 200 community contributed gallery modules (a number that grows by the week) make it one of the most comprehensive libraries out there.
As a user of both jQuery and YUI, I have to admit that I look at them in almost completely different lights. I use jQuery for custom effects, animation, interactivity on our externally-facing website. The visual extensibility of jQuery means that we can customize the look and feel of these elements to match the rest of our website. I've used YUI as a quick and easy way to develop a snazzy front interface for some of our internal applications. These internal applications are simple Apache/MySQL/PHP apps, and YUI allows for simplified data visualization, form handling, tabs, etc. without having to worry about the look and feel as much. The standardized, slightly bland interface elements are a perfect, no-nonsense approach to quickly developing and rolling out these apps.
I found the learning curve to be a bit steep myself, but the examples help out a lot.
I've been using ExtJS and JQuery for some time, but now i'm experimenting with YUI 3. I like the general idea behind YUI (modules, async loader, plugins) but some things annoy me:
lots of documentation, but some things aren't documented at all or very scarcely
some features are very basic (data grids) compared to their ExtJS counterparts.
you never know which features are there in the core, in gallery or aren't implemented at all. You need to do the research yourself.
the framework feels less coherent than ExtJS
I'm trying to find a replacement for ExtJS for building business applications, but didn't find any framework that would be as rich and complete as ExtJS. I don't like how ExtJS looks and how it forces some strange implementation/architecture decisions on you (MVC!), but have to admit it's really hard to replace.
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.
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
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 11 years ago.
So I assume I'm not the only one. I'm wondering if there are others out there who have compiled a personal code library. Something that you take from job to job that has examples of best practices, things you are proud of, or just common methods you see yourself using over and over.
I just recently started my C# library. It already has quite a few small items. Common Regex validations, interfaces for exception handling, some type conversion overloads, enum wrappers, sql injection detection methods, and some common user controls with AJAX toolkit examples.
I'm wondering what kind of things do you have in yours?
I use my own wiki where I post code snippets and commentaries.
I find that more useful than having my own library. And since they are essentially notes and not full programs there isn't a problem with who owns the code (you or your employer ).
PS: I don't hide the fact that I have that from my employer. In fact most of them were positive and even asked for a copy.
Because I primarily do web development, I've abstracted out some common features that I end up doing frequently on sites for clients.
Ajax Emailer. Nearly every site I work on has some type of contact form. I wrote a utility that allows me to drop some HTML on a page, having JavaScript field validation, and a PHP library that requires me to change a few parameters to work with each client's mail server. The only thing I have to write is CSS each time I include it on to a page.
Stylesheet skeleton generator. I wrote a small JavaScript utility that walks the DOM for whatever page it has been included on and then stubs out a valid CSS skeleton so that I can immediately start writing styles without having to do the repetitive task for every site I work on.
JavaScript Query String Parser. Occasionally I need to parse the query string but it doesn't warrant any major modifications to the server (such as installing PHP), so I wrote a generic JavaScript utility that I can easily configure for each site.
I've got other odds and end utilities, as well, but they are kind of hacked together for personal use. I'd be embarrassed to let anyone see the source.
Update
Several people have asked for my stylesheet skeleton generator in the comments so I'm providing a link to the project here. It's more or less based on the way that I structure my XHTML and format my CSS, but hopefully you'll find it useful.
I have found that using Snipplr makes this incredibly convenient. You can tag items, save favorites, search by keyword, etc. I mostly use it for Vim-related snippets (common commands, vimrc file, etc.), but it can be used for anything. Check it out.
I have my personal C++ cross platform library here: http://code.google.com/p/kgui/
It's open source LGPL, I use it in my hobby / volunteer projects. I started it about 3 years ago and have been slowly adding functionality to it.
Back in the days of C programming on MacOS 7, i did write a fairly extensive OO library (yes, OOP in very old C) mostly to handle dialog windows. I abandoned it for PowerPlant (a nice C++ from Metrowerks) during the switch from 68k to PPC processors.
A little after that, i began writing web apps, first in PHP, recently in Django. On this aspect, my reusable code is limited to some tricks and code style.
But for all non-web (or with only small web componets), i've been using Lua. It's so fast to write and rewrite code, that there's very little incentive in reusing code. I mean, what's the point of copying a 10 line function and then adapt it? it's faster to rewrite it just for this project.
That's not so wasteful as it sounds. Lua code is so succint that my apps can be very complex, but seldom have more than a couple thousands lines.
At the same time, several Lua projects imply interfacing to C libraries. It's very easy to write bindings to existing libraries, so i just do that as a subproject. And these modules are what i do reuse! once and again... with very little (if any) changes from one project to the other.
In short: non-web projects are usually one-off Lua code, and some heavily reused binding modules.
I use Source Code Library from http://www.highdots.com/products/source-code-library/ since I can manage different textfiles, notes, screenshots and different programming languages.
I have several utility MATLAB functions that I have taken with me as I move from job to job, particularly ones that enforce W3C standards on the plots I make to ensure that text and background colors have a good luminosity ratio. I also have a function that uses ActiveX to insert a MATLAB figure into PowerPoint.
I keep my personal code libraries on CPAN. I'm not even sure how I'd do this in other languages anymore. It's just too integrated in the way that I think about programming now.
For my PHP work I started with a small file of simple things: a mail function that checks inputs for header attacks, and email validator, an input srubber, that type of thing. Over time it has grown into a application framework for quickly developing one off applications that can be templated by our graphic designer.
I have a library that i use quite extensively. I started fresh with c# and kinda threw all of the legacy stuff out the window. I find them very handy and i rewrite/refactor them often (some of them). Some of the stuff i have is:
Auxiliary (things like IsRunningLocal, InternetDetection)
Standard Classes or Structs for: Address, CreditCard, Person
I have .dll's for both win and web stuff, some very logical like a .dll for shopping cart stuff
I wrote a quick and simple library in Java which I can add code snippets to. I plan to extend it to a full framework for development at some point but only when time allows. I have all sorts in there from simple functions to full blown pages and features. Its so helpful to have when developing because as a web designer, all I need to do is change the CSS of the page.