Announcement Announcement Module
Collapse
No announcement yet.
RESTful controllers without full scaffolding Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • RESTful controllers without full scaffolding

    I want to use Roo's very nice generation of JSON-slinging RESTful controllers. I DON'T want a full HTML scaffold built--I'm building all the front end myself.

    I can't seem to find a way to separate the two. The JSON functions get built when the scaffold view controller classes get the @RooJson annotation. When a model class gets that annotation, the JSON functions that are built are much "model-y".

  • #2
    Ooh, I like that idea too. Why don't you add a JIRA to the Spring Roo project as an enhancement request? I'd gladly vote it up. It is something that would skip an unnecessary step for using controllers from Javascript clients.

    Comment


    • #3
      Not to bogart the thread, but did you notice that when you issue a GET in 1.2 trunk, you get this:

      Code:
      [pizzashop-activerecord (master)]$ curl -i -H "Accept: application/json" http://localhost:8080/pizzashop/bases
      HTTP/1.1 200 OK
      Content-Type: application/text; charset=utf-8
      Content-Length: 82
      Server: Jetty(8.0.1.v20110908)
      
      [{"id":1,"name":"asfsadfsd","version":1},{"id":3,"name":"Thin Crust","version":1}][pizzashop-activerecord (master)]
      On mine, there is an extra array - [pizzashop-activerecord (master)], which seems to be the git repository branch and project name, at the end of the response.

      Is this new? I don't remember seeing it, and I think it will cause problems with standard RESTful clients as it is additional information not asked for.

      Comment


      • #4
        One more thing. If you want the effect of the scaffolded RESTful controller, you could:

        1. scaffold
        2. push-in refactor all methods from the _Roo_Controller.aj ITD
        3. Remove the @RooWebScaffold tag
        4. Remove the generated views.

        That isn't ideal but it works just as well. Since you'd never really modify this when adding/removing fields, it holds up pretty well. You'd just lose any updates to functionality provided when Roo gets upgraded and have to reverse engineer them / apply them to the controller manually. But that's a minor point.

        There, thread un-bogarted

        Comment


        • #5
          Originally posted by krimple View Post
          Ooh, I like that idea too. Why don't you add a JIRA to the Spring Roo project as an enhancement request? I'd gladly vote it up. It is something that would skip an unnecessary step for using controllers from Javascript clients.
          Submitted. https://jira.springsource.org/browse/ROO-2896

          Thanks!

          Comment


          • #6
            Originally posted by krimple View Post
            One more thing. If you want the effect of the scaffolded RESTful controller, you could:

            1. scaffold
            2. push-in refactor all methods from the _Roo_Controller.aj ITD
            3. Remove the @RooWebScaffold tag
            4. Remove the generated views.

            That isn't ideal but it works just as well. Since you'd never really modify this when adding/removing fields, it holds up pretty well. You'd just lose any updates to functionality provided when Roo gets upgraded and have to reverse engineer them / apply them to the controller manually. But that's a minor point.

            There, thread un-bogarted
            It could be I'm trying to do something un-Spring-ish here (this is my first Java/Spring/Roo project, I'm really a PHP/Perl guy), but I'm writing controllers that aren't tied one-to-one with models. I've got controllers (actually a small set of them) for each logical area of the site I'm building, and each one is intimately related with several model entities.

            I could pick the "main" model I'm working with in each controller and use @RooWebScaffold to get its RESTful interface built, and push that in, but that would only cover maybe 1/5 of the models I'm working with. I could make "stub" controllers solely for the purpose of housing the @RooWebScaffold annotation for the models I haven't got another home for the RESTful interface of, but then I'm back where I started--that's pretty much what Roo generates.

            In a design like this one, it seems to me like the RESTful stuff ought to get generated from the MODEL, not the CONTROLLER. I want a model-level annotation that generates the RESTful interface, which I can then call from my client without necessarily firing up my hand-written controllers. It's a separation-of-concerns violation to do that, I suppose, but a RESTful interface is so "model-y" anyway, I think it can probably be justified.

            Comment

            Working...
            X