Announcement Announcement Module
Collapse
No announcement yet.
Understanding GWT integration Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Understanding GWT integration

    Hi all,

    I'm trying to understand what the goals of the still-in-development GWT integration are. If someone could answer the following questions, it would go a long way in helping me understand how I should be looking at my project's design...

    1. Bigger picture question: Is this GWT integration intended to be:
    • A replacement for Spring MVC
    • Some sort of either / or proposition (either you do a "controller" command and use Spring MVC OR you do a "gwt setup" and use GWT for your web front end, but not both)
    • Or, is there some upcoming hybrid where Spring MVC deals with "super-scaffolding" / inter page design while GWT implements page-level views?

    2. I see from the Google IO demo that GWT entities should be following a ~.server.domain.<blah> format, while the tutorials are using the ~.domain.<blah> format (i.e., without the "server"). This kind of ties in to the first question. What's the best practice here - does it depend on if the user decides to go with GWT?

  • #2
    *ping*

    (...before these questions blow off the forums.)

    I really am curious to know what Roo's plans are for integration with GWT in this year's release. If I'm understanding the presentation content correctly, the architectural vision for the GWT integration looks like it should be informing our design decisions. Right?

    Comment


    • #3
      When writing your application with the help of Roo and you want a Web front end for it you have a number of choices:

      - Spring MVC / JSP
      - GWT
      - Flex
      - more to come

      So for Web front ends you can choose which technology you prefer or know best and let Roo scaffold it for you.

      If you wanted you could even scaffold several front ends for the same application and have them running in the same app (available under different URLs), but this is probably more of a fun exercise than something you would want in production.

      Cheers,
      Stefan

      Comment


      • #4
        Fantastic!

        Stefan,

        Thanks so much for your reply. That really does help clarify where you're going with Roo (as well as what to expect from the GWT integration when it comes out). I'm guessing this type of information is what would go in that section 2 of the reference docs.

        So here's a summary of the same info, connecting the dots in case someone else comes into the forums with the same question (but I would love for this type of info to be in the reference docs!). Hopefully I've got the info correct:

        ---
        Q. How should I be building my entities? What sort of front end should I be using?

        A: The second question should be addressed first. Roo provides (or will provide) scaffolding support for the following:
        - Spring MVC / JSP
        - GWT
        - Flex
        - ...

        While it is possible to combine these scaffoldings on different URLs, this would likely introduce more complexity than is needed in a production environment. Choose a scaffolding technology that best suits your task and that you are comfortable with, and then create your entities to follow the appropriate pattern:

        Spring MVC / JSP
        - Strengths of technology
        - Best practices for entities (e.g., "~.domain.class")

        GWT
        - Strengths of technology (e.g., good at single-page navigation, ajaxy stuff without getting your hands dirty with JavaScript)
        - Best practices for entities (e.g., "~.server.domain.class") - because GWT likes you to make a distinction between JVM-controlled classes and those that are compiled to JS and run on the client

        Flex
        - Strengths of technology
        - Best Practices for entities (...)

        Comment

        Working...
        X