블로그 이미지
Max.

calendar

1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31        

Notice

2009. 9. 9. 18:30 개발관련


1. 리소스 메시지를 하나 찍기 위해 <spring:message code="${rsvp.email}"/> 같은 많은 양의 코딩을 해야 한다 이런 하드코딩을 개선할 생각이 없는가? 이미 관련해서 가능한 개선을 했고, trunk에서 checkout 받아서 테스트 하면, 잘 된다는것을 확인할수 있단다.

2. Roo UI를 구성하는 jsp 화면을 보면, 아주 simple하게 구성되어 있는데, 이를 좀더 편리하고 실제 프로젝트에서 쓸만한 다양한 검색이나 Order 기능을 포함한 풍부한 UI를 제공하길 바라는 글이 올라왔다. (마치 Appfuse처럼) 질문자의 첨부된 파일을 보면, 혹 할정도 인데, 개발진에서 코멘트가 없는걸 보니, 아직 그것까지 신경쓸 여력이 없는것 같다.

3. DAO,Service, Facade 같은 addon을 후속으로 제공할 것인가에 대한 물음에 Stefan의 대답은 이것이다.

At the moment Roo generated applications do not generate a traditional repository or service layer, but instead encourage a rich domain layer. The data access is fully included in the domain layer without actually showing up in the Java sources. It is, instead, handled by introduced code (ie Roo_Entity aspects). Since most JPA-managed repositories we see today do actually not add much value we believe Roo's approach can offer the same without the need for this extra layer. Keep in mind that Roo allows you to customize your data access as you wish.

As for the services layer, it is really hard to figure out what you want to do in there. Roo allows you to create simple java classes to get you started. Roo cannot determine which methods for business logic that is not included in your rich domain layer you need in the services layer. Again, we don't much value in a services layer which acts as a simple facade that just hides a repository by mapping its methods 1:1. So long story short, Roo does not prevent you from creating your own services layer when needed but this cannot be generated by Roo as this layer would typically contain application specific business logic.

컨설턴트 집단이라 그런지, 말과 글이 구렁이 담넘어간다.

4. Web 프로젝트로 인식 시킬려면, 적어도 하나이상의 Controller 명령을 내려야만 한다. 이거 이해가 안된다 라고 Roo 골수팬인 Raul이 말하자. Stefan은 이미 알고 있지만, 이슈로 등록해 주길 바란다고 한다. 그런데 가만히 보면, 이사람들도 개발자다 보니, 이슈를 고객으로 부터 나오는것을 선호(?) 또는 의도(?) 하는것 같다. 사업주에게 보여지는 부분을 신경쓰는것 같다.

5. @RequestMapping 이 모두 ITDs로 설정되기 때문에, URL을 개발자가 마음대로 설정할수 없다.(ROO-183)라는 이슈에 대해, @RooWebScaffold에 -path 라는 속성을 추가 해서 변경 가능하도록 업데이트 했다. 2009-09-08일자 Stefan이 한 짓이다.

posted by Max.
TAG ,

댓글을 달아 주세요

  1. 저는 controller 만들 때에 web project로 인식되로록 하는 게 합리적일 것 같네요. 저 같아도 당장은 도메인 생성툴로 더 관심이 많으니까요. web 쪽은 spring mvc가 아닌 다른 더 생산성 높은 프레임워크를 쓰고 싶을 수도 있고...

    • Favicon of https://yunsunghan.tistory.com BlogIcon Max. 2009.09.28 14:00 신고  Addr Edit/Del

      만약, 도메인만 Roo로 생성하고 controller는 직접 구현한다면, web.xml 같은 것을 직접 만들어야 하는데, 그러면 약간 불편하니, 어쩔수 없이 new controller 명령을 하나 내려야 하는데, 그럴때, 해당 명령없이도 가능하게 하는 방법을 제공하려는 것 같습니다.

      지금 이대로도 굳이 불편하다는 생각은 잘 안드는 이유는, 다른 기능이 워낙 거시기(?)하기 때문에, 빨리 RA가 나와야 하는데 말이죠...