포럼
page_full_width" class="col-xs-12" |cond="$__Context->page_full_width">
애드온 처리와 트리거 처리의 문제점 검토
2011.05.20 12:05
XE 모듈에서 애드온과 트리거 처리는 장점과 단점을 가진 기능입니다.
예전에 멀티태스킹과 OS차원에서 하드웨어를 제어할때 사용했던(지금도 사용하는진 모르겠지만요 ^^)
인터럽트기능과 매우 유사하다고 보여집니다.
아주 유용한 기능이지만 시스템을 먹통으로 만드는 기능(?)도 가지고 있죠.
시스템이 돌아가는 중간중간에 시스템코드가 아니면서도 시스템의 제어권한을 가지고 필요한 처리를 하므로해서
유용성과 위험성을 함께 가진 방식이라 생각됩니다.
제가 최근에 겪은 문제는 트리거의 경우
분명히 에러처리코드를 리턴했음에도 불구하고 에러처리를 하지 않고 정상처리 되는 경우였습니다.
그래서 이유를 생각해 보았을때
한가지 모듈트리거 호출에 대해서(예를들면 $oModuleController->insertTrigger('file.insertFile', 'eboard', 'controller', 'triggerInsertFile', 'after'); eboard는 board모듈을 상속(카피가 아닌 부모객체의 속성을 그대로)받아 만든 모듈입니다.)
eboard만 처리하는게 아니라 다른 모듈에서도 처리할경우
eboard에서 에러코드를 리턴하더라도 다른모듈에서 다시 리턴코드를 정상코드로 리턴하게 되면
시스템에 리턴되는 최종리턴코드는 호출되는 순서에 따라 달라져서 그런것이 아닌가 하는 생각이 들었습니다.
제가 아직 XE코어의 동작순서나 처리방식에 대해 자세히 알지 못해 추정만 하고 있지만
이런 개연성이 농후해 보입니다.
애드온 역시 호출되는 순서에 따라 앞에서 어떤 값을 셋팅해서 이후에 원하는 결과를 얻고자 하지만
뒤에서 호출된 애드온이 그값을 변경했을때는 원하는 결과를 얻을 수 없습니다.
그래서 저의 생각은
애드온과 트리거처리의 경우는 처리순서와 리턴코드에 대한
엄격한 기준과 원칙을 만들어야 하지 않을까 합니다.
예전에 멀티태스킹과 OS차원에서 하드웨어를 제어할때 사용했던(지금도 사용하는진 모르겠지만요 ^^)
인터럽트기능과 매우 유사하다고 보여집니다.
아주 유용한 기능이지만 시스템을 먹통으로 만드는 기능(?)도 가지고 있죠.
시스템이 돌아가는 중간중간에 시스템코드가 아니면서도 시스템의 제어권한을 가지고 필요한 처리를 하므로해서
유용성과 위험성을 함께 가진 방식이라 생각됩니다.
제가 최근에 겪은 문제는 트리거의 경우
분명히 에러처리코드를 리턴했음에도 불구하고 에러처리를 하지 않고 정상처리 되는 경우였습니다.
그래서 이유를 생각해 보았을때
한가지 모듈트리거 호출에 대해서(예를들면 $oModuleController->insertTrigger('file.insertFile', 'eboard', 'controller', 'triggerInsertFile', 'after'); eboard는 board모듈을 상속(카피가 아닌 부모객체의 속성을 그대로)받아 만든 모듈입니다.)
eboard만 처리하는게 아니라 다른 모듈에서도 처리할경우
eboard에서 에러코드를 리턴하더라도 다른모듈에서 다시 리턴코드를 정상코드로 리턴하게 되면
시스템에 리턴되는 최종리턴코드는 호출되는 순서에 따라 달라져서 그런것이 아닌가 하는 생각이 들었습니다.
제가 아직 XE코어의 동작순서나 처리방식에 대해 자세히 알지 못해 추정만 하고 있지만
이런 개연성이 농후해 보입니다.
애드온 역시 호출되는 순서에 따라 앞에서 어떤 값을 셋팅해서 이후에 원하는 결과를 얻고자 하지만
뒤에서 호출된 애드온이 그값을 변경했을때는 원하는 결과를 얻을 수 없습니다.
그래서 저의 생각은
애드온과 트리거처리의 경우는 처리순서와 리턴코드에 대한
엄격한 기준과 원칙을 만들어야 하지 않을까 합니다.
애드온의 실행순서 를 정하는 옵션을 추가하는것은,
어차피 그 실행순서를 개발자가 정할텐데, 그것이 애드온이 중첩되면서 버그를 발생할수 있는 문제를 해결하긴 어렵다고 생각합니다.
오히려, 저는 개인적으로 예를들어서 DocumentItem 을 다룬다면,
DocumentItem 의 특정 부분을 애드온등이 억세스할때 특정 값등을 보호할수 있는 수단을 만들면 이 문제의 감소효과가 조금 있지 않을까 싶습니다.
에러 반환의 경우도 사실 지금은 각 애드온에서 종료를 해야하는경우 exit() 등을 사용하고 있는데
예를들어
이런식으로 말이죠.
이것이 공통된 처리 알고리즘 하에서 이루어지고, 에러메세지도 제대로 출력되도록
애드온용 예외 종료 루틴을 추가하면 어떨까 합니다.