Hi Patrik,
Ok. And the operation params would need also some additional infos like
@PathVariable? Or for the first run we can generate pretty good defaults as
you say. Or can you post me an example how a param would look like in this
case with the @Pathv.
(Even if we do not change the metamodel based on the service itself a
controller can be generated quite easily :) )
I have looked yesterday in detail into the dsl and code generation model
trafos, generation so i have got quite a good overview of it.
In the example you provided it would be fast enough not to have a separate
model element for the Controller because if a Service is restful it gets a
Controller generated.
The Controller is just a thin layer and basically delegates always to the
service.
But as the Boss of the project i ask you to please make this decision and
then i will proceed along that path.
Patrik Nordwall wrote:
>
> Hi Attila, I'm happy to see you are back in the team again.
>
> We also need to decide if we need separate DslController or if we can use
> DslService, with some additions.
>
> Service PlanetService {
> restful
>
> @Planet findById(Long id) restPath="/planet/{id}" restMethod=GET
> delegates to PlanetRepository.findById;
>
> save(@Planet planet) restPath="/planet" restMethod="POST"
> delegates to PlanetRepository.save;
> }
>
>
> We can probably come up with good defaults for restPath and restMethod
> based on naming conventions, so that it is optional to define them.
>
>
> Another design decision is if we should have a separate Controller in the
> meta model, that is used by the code generation templates. You know we
> have a transformation between dsl model and code generation model, so they
> don't have to have the same structure.
> Maybe a Controller extends Service is nice in the meta model, because then
> it is easy to use polymorphism in the xpand templates.
>
> /Patrik
>
>
>
> Bak Attila wrote:
>>
>> Hi Patrik,
>>
>> How would you image this one in the dsl as annotated?
>> I mean how should it look in the textual language?
>> The problem ist that operations and params need "annotations" there.
>> Could you give me an example?
>>
>> @RequestMapping(value = "/inquiry/{id}", method = RequestMethod.GET)
>> public String show(@PathVariable("id") Long id, ModelMap modelMap)
>> throws InquiryNotFoundException
>>
>> Thanks
>> attila
>>
>>
>> Patrik Nordwall wrote:
>>>
>>> Hi all, I have an idea of a new feature and would like to have your
>>> input.
>>>
>>> When we have evaluated Google App Engine we have used the new REST
>>> features in Spring 3.0. REST is a perfect style for the cloud and I
>>> think it would be rather easy to generate the Spring Controllers,
>>> delegating to Services. I'm not looking for another gui solution. It
>>> should primarily support json and xml content, which can be used by
>>> various client applications (not only cloud environment).
>>>
>>> My suggestion is to generate Spring Controllers with @RequestMapping
>>> annotations. The methods should delegate to Service methods, or be
>>> implemented by hand written code in gap subclass.
>>>
>>> It might look something like this:
>>>
>>> @RequestMapping(value = "/inquiry/{id}", method = RequestMethod.GET)
>>> public String show(@PathVariable("id") Long id, ModelMap modelMap)
>>> throws InquiryNotFoundException {
>>> Key inquiryKey =
>>> KeyFactory.createKey(Inquiry.class.getSimpleName(), id);
>>> Inquiry inquiry = inquiryService.findById(serviceContext(),
>>> inquiryKey);
>>> modelMap.put("inquiry", inquiry);
>>> return "inquiry/show";
>>> }
>>>
>>> @RequestMapping(value = "/inquiry", method = RequestMethod.POST)
>>> public String create(@ModelAttribute("inquiry") Inquiry inquiry,
>>> BindingResult result) {
>>> if (inquiry == null) {
>>> throw new IllegalArgumentException("A inquiry is required");
>>> }
>>> Inquiry savedInquiry = inquiryService.save(serviceContext(),
>>> inquiry);
>>> return "redirect:/rest/inquiry/" + savedInquiry.getId().getId();
>>> }
>>>
>>>
>>> What I think should be done:
>>> - In meta model add Controller and ControllerOperation, similar to
>>> Service. ControllerOperation should include things necessary to define
>>> RequestMapping and delegation to ServiceOperation.
>>> - In DSL add DslController similar to DslService
>>> - In transformation add transformaton from DslController to Controller
>>> - In transformation add scaffold for controller, similar to Service,
>>> i.e. the CRUD operations can be automated using single scaffold keyword
>>> - Generation template for Controller and its operations. Support for gap
>>> class.
>>> - Generation template for spring configuration for
>>> ContentNegotiatingViewResolver
>>>
>>> References:
>>> - http://www.infoq.com/articles/designing-restful-http-apps-roth
>>> - http://blog.springsource.com/2009/03/08/rest-in-spring-3-mvc
>>> -
>>> http://stsmedia.net/spring-finance-part-7-adding-support-for-json-and-xml-views/
>>> http://code.google.com/p/spring-finance-manager/source/checkout
>>> I have tried the setup described here and I think it is working.
>>> - http://curl.haxx.se/ (useful for testing)
>>>
>>> What do you thing? Would this be useful for you?
>>>
>>> /Patrik
>>>
>>>
>>>
>>
>>
>
>
--
View this message in context:
http://old.nabble.com/-sculptor--RESTful-Services-tp25407858s17564p29489406.html
Sent from the Fornax-Platform mailing list archive at Nabble.com.
------------------------------------------------------------------------------
This SF.net email is sponsored by
Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev
_______________________________________________
Fornax-developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/fornax-developer
