반응형
블로그 이미지
개발자로서 현장에서 일하면서 새로 접하는 기술들이나 알게된 정보 등을 정리하기 위한 블로그입니다. 운 좋게 미국에서 큰 회사들의 프로젝트에서 컬설턴트로 일하고 있어서 새로운 기술들을 접할 기회가 많이 있습니다. 미국의 IT 프로젝트에서 사용되는 툴들에 대해 많은 분들과 정보를 공유하고 싶습니다.
솔웅

최근에 받은 트랙백

글 보관함

Kurogo Tutorial 10 - Module 만들기 -

2012. 5. 12. 13:27 | Posted by 솔웅


이번주 제가 회사에서 할당받은 일이 Kurogo의 Map 과 관련된 것 하고 새 모듈을 하나 만드는 겁니다.

지금 Kurogo Tutorial 을 번역하고 있는데요.

급하게 제가 처리해야 할 일이 생겨서 그 부분 부터 번역을 하고 있는데요.

지난번에 MAP 부분을 정리했고 이번에는 Module 만들기를 정리합니다.


=====================


Writing Modules

쿠로고 프레임워크는 모듈을 기본으로 만들어 졌습니다. 각 모듈들은 유저에게 보여지는 그들만의 데이타 세트와 서비스들을 제공합니다.


The Module Object


각 모듈은 Module object의 subclass 입니다. 대부분의 core logic이 이 클래스에 위치해 있습니다.


  • configuration과 런타임 파라미터들을 수집하는것
  • internal URL들의 생성
  • Authorization


웹에서 유저에게 제공되는 모듈을 만들기 위해서는 (홈 스크린에 나타나던지 그렇지 않던지 간에) 그 모듈은 반드시 WebModule 객체의 subclass 이어야 합니다. 웹서비스로서 native(iOS같은) 앱이나 앱의 AJAX functionality 들이 그 데이터를 사용하도록 만드려면 그 모듈은 반드시 APIModule 객체의 subclass 이어야 합니다.


대부분의 모듈들은 WebModule과 APIModule 모두의 subclass 입니다. 모듈이 이 중 하나의 subclass 이고 다른 하나의 subclass가 아닌 경우도 있을 수 있습니다. 예를 들어 에러 모듈의 경우에는 유저에게 에러를 알려주기 위한 웹 인터페이스인데 API counterpart를 가지고 있지 않습니다.각 모듈들의 WebModule과 APIModule subclass 는 대부분 비슷합니다. WebModule과 APIModule에 관한 자세한 사항들은 아래 링크로 가서 확인하세요.



    The WebModule Object
    The APIModule Object




Module life cycle

request가 한번 만들어지면 loading system은 factory method를 사용해서 어떤 모듈이 load 되어야 결정하고 모듈을 생성합니다. URL은 어떤 모듈이 로드 되고 어떤 페이지가 할당되고 includ 돈 파라미터들을 설정합니다.

url의 첫번째 path component 는 모듈의 아이디 입니다. 이것은 어떤 모듈을 로드할 지를 정할 수 있도록 해 줍니다. factory method는 SITE_DIR/config/ID/ 에서 config 폴더를 찾아봅니다. 그리고 module.ini 파일을 로드하죠. 그 파일 안에서 id 값을 찾고 해당 ID의 module을 로드합니다. 만약 ID property가 없다면 config folder 를 id로 module을 load 할 겁니다.

그 URL에 대한 config folder가 없다면 site.ini에 있는 CREATE_DEFAULT_CONFIG 의 값을 찾아보게 됩니다.

    만약 true 이면 그 ID를 근거로 모듈을 로드하려고 할 겁니다. 그리고나서 모듈이 발견되면 자동적으로 config folder를 생성합니다.
    만약 false면 (디폴트임) 또는 그 ID로 모듈을 찾을 수가 없으면 fail이 일어날 겁니다.

두번째 path component는 (WebModule에 대한) page 입니다. 이것으로 로드할 code path와 template file 을 설정합니다. 만약 가리키는 page가 없으면 그 페이지는 index로 세팅 될 겁니다.

APIModule에 대해서는 이것은 command 입니다. 이 command는 항상 존재해야 합니다. 필요한 id/command URL format의 single exception(예외상황)은 CoreAPIModule을 request 하는 것입니다. CoreAPIModule은 single command (hello) 이고 모듈 아이디가 없습니다.

After instantiating the object, the init method is called. This does several things:
객체를 초기화(instantiating) 하고 나서 init method 가 call 됩니다. 여기에 몇가지가 있습니다.

    - page, args, pagetype, platform 을 포함한 필요한 프로퍼티들을 할당한다.
    - data structure들을 셋업하기 위해 사용되는 initialize() 메소드를 call 합니다. 이 data structure는 inside a page와 outside(예를 들어 federated search 안의 instance에 대한 경우)를 사용합니다.
    - WebModules안에서 initializeForPage() 메소드가 call 됩니다. 이 메소드는 그 모듈 로직에 대한 primary entry point를 보여 줍니다. 특히 그 모듈이 그 페이지 프로퍼티으 ㅣ값에 근거한 다룬 로직을 처리하게 됩니다.
    - APIModules 안에서는 initializeForCommand() 메소드가 call 됩니다. 특히 이 모듈은 command property의 값에 근거한 다른 로직을 처리하게 됩니다.


마지막으로 output은 다음과 같은 것을 generate 됩니다. WebModule은 templatePage 프로퍼티의 값에 근거해 display 할 template을 선택합니다. 초기에는 page property로 셋하지만 좀 더 다이나믹한 template display 를 위해 필요하다면 overridden 할 수 있습니다. APIModule은 모듈 id, API version, command requested, response payload 를 포함한 JSON response를 생성합니다.

Methods to use

모듈 객체에는 많은 메소드가 있습니다. 대부분은 내부적으로 사용됩니다. 그러므로 얘기 나눌 부분은 별로 없습니다. 새로운 모듈을 만들 때 주의해야할 몇개의 메소드가 있습니다. WebModuleAPIModule을 위한 메소드들도 보셔야 합니다.

Accessors

    getArg($key, $default) - Retrieves an argument sent via GET/POST, if the $key is not present, then it will return the value specified in $default

Configuration

configuration data를 로드하기 위한 여러 메소드들이 있습니다. Configuratin은 server locations, urls 그리고 소스코드 밖의 다른 값들 같은 특정 detail 값들을 keep 할 수 있도록 해 줍니다. 각 모듈은 configuration file들의 폴더가 있습니다. primary configuration data 는 module.ini 파일안에 있습니다. pages.ini 모듈 안에 있는 Page data는 필요로 하는 configuration structure를 사용할 수 있습니다. 많은 경우 complex data structure는 다른 파일에 있을 필요가 있을 겁니다.

여러분은 key나 전체 section을 이용해서 값을 retrieve 할 수 있습니다. (배열로서 값을 받을 겁니다.) Module 객체에는 아래 메소드들이 있습니다.

    getModuleVar($key, $section=null, $config=’module’) - Gets a required module variable $key. If you specify $section it will only look in that section. Will throw an exception if the value is not present
    getOptionalModuleVar($key, $default=’‘, $section=null, $config=’module’) - Gets an optional module variable $key. If you specify $section it will only look in that section. If it is not present, $default will be used (empty string by default)
    getModuleSection($section, $config=’module’) returns an array of values in a module section. Will throw an exception if the section is not present
    getOptionalModuleSection($section, $config=’module’) returns an array of values in a module section. Will return an empty array if the section is not present
    getModuleSections($config) - Returns a complete dictionary of sections=>vars=>values for a particular config file. Very handy when you basically want the array structure of an entire file
    getOptionalModuleSections($config) - Like getModuleSections(), but if the config file does not exist it will return false


site configuration (site.ini)에서도 값을 retrieve 할 수 있습니다. 이것들은 모든 모듈에 의해 사용되는 값들입니다. Kurogo 객체의 static methods가 있습니다.

    Kurogo::getSiteVar($key, $section=null) - similar to getModuleVar
    Kurogo::getOptionalSiteVar($key, $default=’‘, $section=null) - similar to getOptionalModule Var
    Kurogo::getSiteSection($section) - similar to getModuleSection
    Kurogo::getOptionalSiteSection($section) similar to getOptionalModuleSection


site string(strings.ini)을 get 하기 위한 또 다른 2개의 다른 메소드들이 있습니다.

    Kurogo::getSiteString($key) - returns a site string. Will throw an exception if not present
    Kurogo::getOptionalSiteString($key, $default=’‘) - returns a site string. Will return $default if not present


User Sessions


    isLoggedIn() returns whether a user is logged in or not (see Authentication)
    getUser() returns a User object of the current user (or AnonymousUser if the user is not logged in)
    getSession() returns the Session object of hte current session.




반응형

Comment