RESTful controllers without full scaffolding

[danray0424]

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".

[krimple]

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.

[krimple]

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

[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.

[krimple]

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

[danray0424]

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!

[danray0424]

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.