Discussions

News: Groovy on the web the right way?

  1. Groovy on the web the right way? (27 messages)

    The Groovy world has been quite busy lately thanks in no small part to projects like Grails. Groovy's dynamic nature, easy scriptability, and rough similarity to the Java language make it an ideal addition to many Java shops. Grails brings the ease of Ruby on Rails to the Java world but has some deficiencies in many minds. The entire system is, as you probably know, basically RoR but with Groovy complete with scaffolding. The issues with scaffolding are well documented: most of the scaffolding gets thrown away once you start doing anything "real" and Grails can certainly suffer from that. You can, of course, write your own templates and these templates are basically JSPs implemented with a Groovy flavor. This is where many people I know balk at such options. JSPs, at least in my circles, are all but deprecated. Even JSF2 is moving away from a JSP-centric view and moving on to JSFTemplating. So why did the Grails guys decide to reimplement JSP? But there are options for those who prefer more "sophisticated" approaches. There are two different projects that give me hope for using Groovy on the web tier: Gracelets and the Wicket Grails Plug-in. Both of these projects have two things going for them:
    1. They leverage existing frameworks and their component sets so we're not left reimplementing everything else as well.
    2. They use more component oriented approaches than JSP development tends to lead to. This means (to adherents to this approach) better maintainability, refactoring, etc.
    An example of a gracelet from the Gracelet page, showing Groovy's syntax while building text input from a bean's values:u.component (rendered: "#{el}") { h.form { (0..10).each { idx -> h.inputText (value: "#{bean.map[idx]}") } } }These projects bring the dynamic nature of Groovy to established Java platforms and reduce or eliminate the need to restart jetty every time a class changes. Maybe these options will make Groovy more palatable on the web. What do you think?

    Threaded Messages (27)

  2. Why didnt you mention the Grails plugins for GWT or Flex as alternatives for the view layer? Might as well use Dojo, Ext components in concise and well encapsulated GSP-Taglibs for that matter. With Grails you can use a lot more than just GSP.
  3. view technology[ Go to top ]

    Funny, I've been doing JSF (Seam, actually) development for a few months now, all the while thinking "damn, all I really want is decent MVC framework. I'd use JSP if it wasn't so broken." Let's be clear -- the OP is really commenting on Grails' view default view implementation (GSP), not Grails in its entirety. Of course, with any non-trivial application you are going to have to write your own view templates. It's pretty much understood that scaffolding will be thrown out. JSF is, in my mind, over-complicated and broken by design. Conversely, GSP is JSP done right. GSP has a real language behind it, not some crippled expression language. SiteMesh, partial templates and GSP taglibs (hey! Simple tag definition! what a novel idea!) provide the right amount of composition without going overboard like JSF does. Sure, JSF gets the job done, but you are going to have bloated and ugly markup. JSF munges component IDs and URLs just enough so that you can pretty much forget about doing any custom JavaScript. Sorry, you're stuck with what some JSF library gives you. No, I'm happy with a simple (albeit not broken) templating framework where I can pull in YUI, Dojo or any number of rich UI components that will work well because I actually have control over my markup and clean URLs. As the OP mentioned, if someone really wants a component-based framework, there are Grails plugins for Flex, Wicket, OpenLaszlo, GWT, etc.
  4. Funny, I've been doing JSF (Seam, actually) development for a few months now, all the while thinking "damn, all I really want is decent MVC framework. I'd use JSP if it wasn't so broken."
    Me too so... +1 I am more concerned about standards compliance in the view than I am with rich interfaces, so JSF is not my favourite because of the HTML + CSS that it generates. GSP is JSP made "simple" and we shouldn´t forget about the enormous power of simplicity, specially when working in a team with developers of different skills. Productivity and mantainability are a must. I don´t also like too much Wicket approach and JSP doesn´t pay or serve enough (IMHO) Scaffolding could save time in fast prototyping and administration stuff but for more complex interaction... but... wait a minute! What about Spring Web Flow? It is also a "de facto" controller technology in Grails and it is pretty simple with the Groovy DSL. In conjuction with GSP views it allows you to build complex interactions in a very easy and concise way. And, the best, you can mix SWF and Scaffolding in the same controller. So, let´s be honest... + We have Scaffolding for CRUD and fast prototyping + GSP, with its pretty "expression language", good templating, easy custom tags and a bit of AJAX helps having a very easy and robust MVC (nice to have!) + SWF adds a really flexible navigation flow controller with conversations and intermidiate scopes that really eases complex use case development + Grails is yet young... ;O) For me Grails is like the "duck", doesn´t swim like a fish, doesn´t run like a fox and doesn´t fly like a hawk, but does it all and good enough :O)
  5. "all the while thinking "damn, all I really want is decent MVC framework. I'd use JSP if it wasn't so broken." I love programming in XML. I actually use XML at home as well. Here's the blackboard in my kitchen I love learning new XML doc types. I'm surprised the Rails guys don't use more XML. It's so great.
  6. "all the while thinking "damn, all I really want is decent MVC framework. I'd use JSP if it wasn't so broken."


    I love programming in XML. I actually use XML at home as well.
    Here's the blackboard in my kitchen









    I love learning new XML doc types. I'm surprised the Rails guys don't use more XML. It's so great.
    Are you sure you shouldn't make garlic its own element. What if you need to specify which type of garlic you are using (crushed, fresh, etc)?
  7. Here's the blackboard in my kitchen









    I love learning new XML doc types. I'm surprised the Rails guys don't use more XML. It's so great.


    Are you sure you shouldn't make garlic its own element. What if you need to specify which type of garlic you are using (crushed, fresh, etc)?
    Nice blackboard... and sure he should... But what I haven´t ever seen is a "choco cake" in the middle of "Sahara" ;O) Bon appetit!
  8. I am more concerned about standards compliance in the view than I am with rich interfaces, so JSF is not my favourite because of the HTML + CSS that it generates.
    This isn't really a function of JSF, it's an issue with default JSF RenderKit. If your component library generates something prettier, you're good to go. ICEfaces 1.7 offers XHTML output, for example. ~~~ Kito D. Mann - Author, JavaServer Faces in Action http://www.virtua.com - JSF/Java EE consulting, training, and mentoring http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info
  9. This isn't really a function of JSF, it's an issue with default JSF RenderKit.
    That is same as saying some car is not really slow, it's just an issue with it's engine. Secondly, the original poster was concerned that JSF does not render 'standard enough' HTML+CSS. From what i'v seen the currently available 3rd party component libraries are even far worse (ajax hammered into framework that was not designed for ajax). /Henri Karapuu

  10. I am more concerned about standards compliance in the view than I am with rich interfaces, so JSF is not my favourite because of the HTML + CSS that it generates.


    This isn't really a function of JSF, it's an issue with default JSF RenderKit. If your component library generates something prettier, you're good to go. ICEfaces 1.7 offers XHTML output, for example.
    Yes, of course you can change the code generated overriding the renderers. But it is a lot of effort. (Please note also that I meant "HTML + JS" instead of "HTML + CSS") But with Standards compliance ("a la W3C") I also mean Accessibility and "semantic HTML". Generating valid XHTML is far from being enough. Some typical mistakes are: using tables for layout, DIV collections instead of lists, presentational tags or inline styles... etc. But the worst problem is the lack of a fallback mechanism when JS is not available. Most JSF implementations don´t work without JS = "intrusive JS" and it is a bad practice. If you can live with that, then it is OK, if not, you have to re-implement the renderers and maybe there are better ways out of JSF. Apropos, do you know any standars-compliant JSF implementation? Thanks, Alberto Mijares.
  11. taglibs[ Go to top ]

    Case in point: This is how taglibs should be done.
  12. no need to restart[ Go to top ]

    There are lots of things going for Grails besides GSP (which is fantastic - especially the taglibs. 10 years after ATG Droplets we finally have sane way to write view-side components). Plus, as mentioned, you are free to use whatever view-side technology you want. I must take issue to your comment about restarting Jetty if a class changes. You can edit a controller or service class, save it and reload the page. The only changes that require a restart are domain class changes (required by Hibernate since the underlying mapping may have changed). So 90% of the time you don't need to restart your app. It's one of the best things about Grails.
  13. Re: no need to restart[ Go to top ]

    I must take issue to your comment about restarting Jetty if a class changes. You can edit a controller or service class, save it and reload the page. The only changes that require a restart are domain class changes (required by Hibernate since the underlying mapping may have changed). So 90% of the time you don't need to restart your app. It's one of the best things about Grails.
    I was referring to restarting the server with Java-based frameworks. Sorry for the confusion.
  14. yes...[ Go to top ]

    at least for using Groovy/Grails with some nice component framework like Wicket instead of the non-OO tag based default view technology. Gracelets may be more of 'lipstick on a pig' as they say though. I can only hope JSF2 is radically different and better than JSF1.x. The Groovy builder isn't enough to make JSF a pleasant and productive framework to work with. Graeme did recently update the wicket plugin for 1.3. It's a fairly minimal plugin at this point. It be nice if there were Grails-oriented Wicket components for quick CRUD. As well as a Groovy WicketBuilder (I did see one started awhile back). Then we can call it Gricket. It'd be nice if there was more interest in Groovy/Grails in the Wicket community. It seems like potentially a really good match. When I get more spare time.... Some of the other Grails plugins like GWT seem further along at this point. But they're not an option for me. I need bookmarkable URLs, more server side management of events, security, etc.
  15. Re: Groovy on the web the right way?[ Go to top ]

    Seriously: What's wrong with JSP? Of course we have all seen bloated, scriptlet-infested JSPs -- however when using JSP 2.0 with tag files, custom tags, and the XML syntax, JSP (in my opinion) is as clean and powerful as any other templating system. What am I missing?
  16. Seriously: What's wrong with JSP? Of course we have all seen bloated, scriptlet-infested JSPs -- however when using JSP 2.0 with tag files, custom tags, and the XML syntax, JSP (in my opinion) is as clean and powerful as any other templating system. What am I missing?
    +1
  17. Re: What's wrong with JSP?[ Go to top ]

    Seriously: What's wrong with JSP? Of course we have all seen bloated, scriptlet-infested JSPs -- however when using JSP 2.0 with tag files, custom tags, and the XML syntax, JSP (in my opinion) is as clean and powerful as any other templating system. What am I missing?
    I always got errors about being "scriptless" or had trouble when I had JSP includes that included other tags and scripts and such. And I could never get a custom tag to render a partial template (a la GSP render( template "myForm", model : someBean )). Maybe I was just never doing it right.
  18. Seriously: What's wrong with JSP? Of course we have all seen bloated, scriptlet-infested JSPs -- however when using JSP 2.0 with tag files, custom tags, and the XML syntax, JSP (in my opinion) is as clean and powerful as any other templating system. What am I missing?
    The primary problem with JSP has always been that it mixes too many concerns which encourages bad practices like putting business logic or even data management logic (SQL) in the presentation tier. Mixing concerns also means that the JSP authors have to know a lot about a number of things - layouts, UI design, styles, programming, HTML, etc. You can argue that JSP has improved and that good developers can avoid doing bad things, but that doesn't make JSPs your best alternative. It just means JSPs don't have to be as bad as they often are. Most programmers are not very good. ("Average" sets the bar too low and we don't live in Lake Wobegon.) Programming, UI design and graphical design are distinctly different skill sets. Most people are not "good" at all of them. A better approach better facilitates, encourages and rewards the separation of concerns and the ability to have different people with different skills each contribute without stepping over each other.
  19. Let's rework this a little...
    The primary problem with Java has always been that it mixes too many concerns which encourages bad practices like putting business logic or even data management logic (SQL) in the presentation tier. Mixing concerns also means that the Java authors have to know a lot about a number of things - layouts, UI design, styles, programming, HTML, etc.

    You can argue that Java has improved and that good developers can avoid doing bad things, but that doesn't make Java your best alternative. It just means Java don't have to be as bad as they often are. Most programmers are not very good. ("Average" sets the bar too low and we don't live in Lake Wobegon.) Programming, UI design and graphical design are distinctly different skill sets. Most people are not "good" at all of them.

    A better approach better facilitates, encourages and rewards the separation of concerns and the ability to have different people with different skills each contribute without stepping over each other.
    There, that's much better.
  20. Sorry, but Java is a general purpose programming language whereas JSP, a rip off of ASP is a "technology" devised to support the presentation tier. As such JSP is poorly conceived and designed. Java as a programming language, especially one that claims to be object-oriented has its own problems, but being general purpose is not one of them.
  21. pebkac?[ Go to top ]

    Seriously: What's wrong with JSP? Of course we have all seen bloated, scriptlet-infested JSPs -- however when using JSP 2.0 with tag files, custom tags, and the XML syntax, JSP (in my opinion) is as clean and powerful as any other templating system. What am I missing?


    The primary problem with JSP has always been that it mixes too many concerns which encourages bad practices like putting business logic or even data management logic (SQL) in the presentation tier. Mixing concerns also means that the JSP authors have to know a lot about a number of things - layouts, UI design, styles, programming, HTML, etc.

    You can argue that JSP has improved and that good developers can avoid doing bad things, but that doesn't make JSPs your best alternative. It just means JSPs don't have to be as bad as they often are. Most programmers are not very good. ("Average" sets the bar too low and we don't live in Lake Wobegon.) Programming, UI design and graphical design are distinctly different skill sets. Most people are not "good" at all of them.

    A better approach better facilitates, encourages and rewards the separation of concerns and the ability to have different people with different skills each contribute without stepping over each other.
    This looks like a "Problem exist between keyboard and chair" scenario to me. No seriously. I'd rather have an architect/senior/evangelist/etc build some abstraction that promotes good design on top of any technology of choice than rely *and pray* on the 3rd party technology to foster it. I've been there, seen a good abstraction that makes mediocre developers produce decent code on ejb 2.0 at a respectable throughput. That's one criteria in my book that separates a good architect/senior/tech lead/etc from the others. So what if he/she knows the Java api in and out or can produce code that wins software practice trophies. I'd rather have one that can promote good code/practice and throughput across the team.
  22. JSP is fine[ Go to top ]

    Seriously: What's wrong with JSP? Of course we have all seen bloated, scriptlet-infested JSPs -- however when using JSP 2.0 with tag files, custom tags, and the XML syntax, JSP (in my opinion) is as clean and powerful as any other templating system. What am I missing?
    Nothing. You're right. +1 Arguments that JSP is not good because developers use it badly and that we can solve that problem with a different tool are so clueless they bring tears to my eyes. Count on it - developers will find new and ingenious ways to use any tool badly. Never underestimate the energy and dedication with which we strive to complicate our lives ;-)
  23. Re: JSP is fine[ Go to top ]

    Who said anything about it being bad because developers use it badly? I think it's just bad period. As an example, when was the last time you got an exception generated because of some broken logic in your jsp page? What did jsp tell you about that error other than one big ass ugly stack trace? There are better tools. Not sure about ~all~ of the options out there - but I do love my line-precise (and context-aware) error reporting. http://opencomponentry.com:8080/workbench/ErrorFest.page
    Seriously: What's wrong with JSP? Of course we have all seen bloated, scriptlet-infested JSPs -- however when using JSP 2.0 with tag files, custom tags, and the XML syntax, JSP (in my opinion) is as clean and powerful as any other templating system. What am I missing?


    Nothing. You're right. +1

    Arguments that JSP is not good because developers use it badly and that we can solve that problem with a different tool are so clueless they bring tears to my eyes.

    Count on it - developers will find new and ingenious ways to use any tool badly. Never underestimate the energy and dedication with which we strive to complicate our lives ;-)
  24. Re: JSP is fine[ Go to top ]

    Never got such an exception because there isnt't any kind of major logic in my jsp except for some el expression deciding what to render and what not against the values of flag variables put in the model.
    Who said anything about it being bad because developers use it badly? I think it's just bad period. As an example, when was the last time you got an exception generated because of some broken logic in your jsp page? What did jsp tell you about that error other than one big ass ugly stack trace?
  25. Seriously: What's wrong with JSP?
    1. The error reporting is based on stack trace of the compiled jsp, which is a really horrible way for finding problems (compared to something like facelets for example). 2. Writing tag handlers for JSPs is just antique grunt work. 3. The compiled nature of JSP means slight delay when making changes. OTOH i don't blame JSP for mixing logic (scriplets) with markup. If that is done, it's not JSP who did it, but the programmer! /Henri Karapuu
  26. 1. The error reporting is based on stack trace of the compiled jsp, which is a really horrible way for finding problems (compared to something like facelets for example).
    If you rely on EL, this isn't problem as you rarely get exceptions at all. Its a real concern, but in in my experience it does't happen that often. And, frankly, inscrutable stacks traces plague much of Java, JSP is hardly alone here.
    2. Writing tag handlers for JSPs is just antique grunt work.
    JSP 2.0 tag files hit the 80-85% mark of what most folks need tag files for. I've never written a normal JSP tag, but I've done dozens of tag files. Trvial ones are trivial to write. A complicated one are straightforward. JSP 2.0 tag files really change the face and use of JSP, IMHO.
    3. The compiled nature of JSP means slight delay when making changes.
    I'll agree with you here. I haven't moved to Java 6. My understanding is with Java 6 and (at least) Glassfish, JSP compiles are MUCH faster now.
  27. We've seemed to have gone a bit off topic. There is an argument out there, that says that Groovy feels a lot more natural to Java programmers then Ruby, whilst retaining the power and flexibility of a fully dynamic OO language. Grails from all reports is a great framework based on the same philosophy as Rails (YAGNI, KISS, DRY etc). Is Groovy/Grails more Java friendly then JRuby/Rails? Is the learning curve easier for Java programmers ? Is it just as productive? Does it offer better integration with Java/J2EE then JRuby/Rails? What are the downsides compared to Rails? Is Groovy/Grails the best way to go for people who only know Java and want to get into dynamic language web development? Anyone with hands-on experience with Groovy/Grails it would be great to hear from you. Anyone else need not respond :). Cheers, Paul.
  28. Room to grow[ Go to top ]

    I'm working on my third Grails based application and I also have a Groovy DSL under my belt. During these four separate efforts I have found Grails & Groovy to be the embodiment of the idea that it is best to provide an entry level api with default behavior that is backed up with more sophisticated and complex options. I also have found consuming plug-ins to be spectacularly easy and effective. While I have got down the mechanics of the more dynamic stuff in Groovy - Expando rocks - when I see others presenting their neat, concise efforts I see that I'm still not doing the language justice. With JSF, and with EJB's I felt the technology was constraining and at times frustrating. With Grails, I feel I'm the one who has to grow and evolve not the platform. So far, it seems to me that my efforts have been constrained by my own personal limitations not the limitations of the technology. I regard this as a good thing, something I can fix and gain lasting value from.