nicely said! could be adde to our webpage/wiki! On 9/29/07, Ryan Holmes <[EMAIL PROTECTED]> wrote: > Arguments that should get some traction with managers: > > - Wicket is more productive than JSF. The simple creation of custom > components, lack of XML configuration and tight Ajax integration mean > there's less code to write. This gives you either a faster time to > market or more/better features within a given time frame. > > - Wicket code is easier to maintain than JSF. No XML config means a > smaller number of UI artifacts to keep in sync. Since all behavior is > expressed in Java code (except whatever JS you choose to add), you > can use most of the same techniques to maintain and refactor the UI > that you use with the rest of your code base. Wicket's Ajax > integration means that you'll rarely, if ever, have duplicate > presentation logic to maintain in both server and client side code. > > - It's easy to hire Wicket developers because all you need are good > Java programmers. As long as you have one or more "web experts" on > your team to set the UI coding standards, write reusable components, > etc., other programmers really don't need to know much about the web. > A couple of programmers on my team had never written a web app in > their lives and could never really "get" Tapestry 4 (much less JSF). > As soon as I wrote a base page, a few custom components and some > initial parts of our app in Wicket, these same programmers were > happily cranking out UI code, adding Ajax behavior, talking about how > cool it was, etc. > > - Allowing developers to use tools they enjoy directly affects > productivity. A programmer who feels forced to use something they > hate is generally not going to bust his/her ass to get stuff done. > This is a basic worker morale issue. Any manager should understand > that higher morale == higher productivity and less turnover. > Obviously, the tools need to meet overall business requirements, but > that's a separate issue. And I think most companies would be hard- > pressed to explain why Wicket doesn't meet their fundamental web > development needs. > > This might be obvious, but my general advice is to talk to managers > about the things they care about rather than what you care about. > Don't try to convince them of anything but instead explain why their > goals are better met by Wicket. The fact that your team wants to use > it definitely counts, but probably not for the same reasons. > > Good luck! > > -Ryan > > On Sep 28, 2007, at 6:34 PM, robert.mcguinness wrote: > > > > > Thanks you and everybody for all the responses. I will be > > referencing these > > emails when I argue my point. I'm pushing Wicket as the framework > > of choice > > and have already convinced the developers and two of the > > architects. I just > > got to get the managers on my side. I will keep everyone posted. > > Thanks > > again, much obliged. > > > > - rm3 > > > > > > gumnaam wrote: > >> > >> Well here's our story, if it helps you. > >> > >> Traditionally we had a JSP+Struts+EJB2 model for all our projects. > >> > >> For our current project we decided to jump on the JEE5 bandwagon, and > >> started out with JSF+EJB3 (SLSB)+ JPA, > >> > >> Now JSF and JSPs don't mix well, so we choose Facelets, and > >> instead of > >> struts we > >> decided to use Seam, as that was the only available glue between > >> the Web > >> and EJB tier. > >> > >> So we had to learn JSF, Seam, Facelets, EJB3 and JPA. Now seam is no > >> good without > >> Stateful Session Beans so we had to change our SLSBs to Stateful > >> Session > >> Beans, and > >> we had all sort of problems with Extended Persistence Context, not to > >> mention, most developers > >> hated Seam as it was very buggy in those days (late 2006, early > >> 2007). > >> We also had a remote EJB3 API layer, and JPA managed entities > >> (especially the ones with > >> lazy loading relationships) don't mix too well with remoting. > >> > >> And even after learning all these new technologies, our web pages, > >> were > >> still lacking all the > >> fancy AJAX stuff. Now we had to learn Icefaces or ajax4jsf . > >> > >> Every body hated every aspect of this development model. > >> > >> Now we have a much saner development environment. Wicket + EJB3 > >> (bcoz we > >> still need remoting) + > >> Spring + iBatis. If we didn't need that EJB remoting layer I would > >> drop > >> EJB3 like a hot potato. > >> > >> My advice, don't worry about the industry standard thing, if you have > >> good developers , > >> then go with Wicket. > >> > >> The first time I hooked up AjaxFallBackDefaultDataTable with my > >> Spring > >> DAO + iBatis, It nearly > >> brought tears to my eyes. Using iBaits I am able to do > >> sorting,filtering,paginating all in the Database, > >> (as it should be done, instead of storing huge datasets in memory and > >> doing it in code), and the > >> DataTable Component gives me all the hooks to plug this in so > >> smoothly. > >> Can't think how I would > >> have managed this with JSF and JPA. > >> > >> So use Wicket for Web and iBatis for ORM. :) > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> robert.mcguinness wrote: > >>> ...to tell you the truth, it impressed the developers but I > >>> didn't get > >>> that > >>> feeling from the top brass. I am pretty sure we will move towards > >>> Seam/JSF/Facelets (we have a presentation on that tech next week > >>> given by > >>> another developer) since it is "standard". > >>> > >>> Has anyone here worked with the Seam tech? All the examples I > >>> have seen > >>> (including Facelets) is nothing but tag soup with scriptlets in > >>> the page > >>> (albeit small). The configuration for a Seam project seems like > >>> a pain > >>> and > >>> was also told that the JSF/Seam/Faclets jsp pages can be > >>> previewed in a > >>> browser (something I thought was so clever about Wicket html > >>> pages...and > >>> I > >>> was under the impression that Wicket was the only tech that > >>> allowed true > >>> separation of concerns; allowing the web designer to work > >>> independenly of > >>> the programmer with no duplication of work between the two). > >>> Maybe I'm > >>> blind to Wicket and I'm overlooking Seam and the techs related to > >>> it? > >>> > >>> I've worked with Freemarker and Struts before and Wicket feels like > >>> "natural" web development. I thought I covered all the great > >>> concepts > >>> about > >>> Wicket: Ajax, Templating, Inheritance, Reusable Components, OO > >>> Concepts…etc… > >>> > >>> Bah…just venting. I'm going to have to win the votes of the > >>> developers. > >>> I'll keep everyone posted. Thanks amigos! > >>> > >>> - rm3 > >>> > >>> > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > >> > > > > -- > > View this message in context: http://www.nabble.com/Presented- > > Wicket-to-my-Company...-tf4532130.html#a12951135 > > Sent from the Wicket - User mailing list archive at Nabble.com. > > > > > > --------------------------------------------------------------------- > > 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] > >
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
