이벤트 중심의 개념은 광범위합니다. 클라이언트 측에 있을 수도 있고 서버 측에 있을 수도 있습니다.
WEB 애플리케이션에서 클라이언트 측 이벤트는 JS나 플러그인 또는 JAVAAPPLET을 기반으로 합니다. 기본적으로 플러그인이나 JAVAAPPLET이라면 실제로 JS가 있어야 하는 경우는 없습니다. 실제로 사용되는 것은 많지 않으며 기껏해야 FORM 제출이나 링크 클릭과 같은 기본적인 작업이므로 이벤트에 대해 이야기하는 것은 의미가 없습니다.
이벤트 중심의 진정한 의미는 시각적 프로그래밍에 있는 것이 아니라 OO와 마찬가지로 개념에 있습니다. 이벤트 중심은 실제로 OO의 확장이며 원래 프로토타입은 메시지 메커니즘입니다. 그러나 이벤트 드라이버는 API의 콜백 함수와 유사한 호출 가능한 함수로 메시지를 캡슐화합니다. 이러한 함수의 실행 내용을 직접 정의할 수 있습니다. 시각적 프로그래밍은 이러한 기능을 분리하고, 매개변수(주로 이미 만들어진 개체)를 정의하며, 사용자가 자신의 코드를 작성하고 이러한 매개변수(실제로는 이러한 개체)를 사용하여 작업을 수행할 수 있도록 합니다.
따라서 주로 프레임워크 설계로 인해 PHP가 이벤트 중심이 되는 것이 전적으로 가능합니다. VB와 같은 소위 시각적 이벤트 드라이버를 만들려면 페이지 디자인, 이벤트 인코딩, 컴파일 및 트랜스코딩과 같은 일련의 기능을 포함하는 지원 통합 개발 환경이 있어야 합니다. 실제로 NET과 같은 이벤트 기반 요소는 버튼, 텍스트 상자 등과 같이 일반적으로 사용되는 일부 WEB 요소나 컨트롤을 캡슐화하므로 컴파일된 후에도 시각적 인터페이스를 가질 수 있습니다. , 이벤트 코드를 JS 또는 서버측 코드로 변환하기만 하면 됩니다. PHP의 경우 주된 이유는 IDE가 충분히 풍부하지 않고 사전 컴파일 메커니즘이 없기 때문입니다. 따라서 제출된 최종 코드는 NET 리소스 코드와 이벤트 코드(일반적으로 ASP)의 혼합이 아닌 여전히 최종 PHP 코드입니다. 비표준 HTML 코드를 포함하는 문서입니다. 따라서 PHP는 모든 사람이 생각하는 좁은 의미의 이벤트 중심 프로그래밍을 여전히 달성할 수 없지만 실제로는 전혀 문제가 없습니다.
관심이 있으시면 www.php.net의 공식 홈페이지로 가서 중국 친구(Qiang Xue)가 작성한 이벤트 중심 PHP 프레임워크인 PRADO를 살펴보시기 바랍니다. 높은 표를 받았으며 적극 권장됩니다. http://www.zend.com/php5/contest 를 참조하세요. 소스 코드를 읽고 나면 PHP의 이벤트 드라이버가 무엇인지 이해할 수 있습니다. 하지만 이런 점에서 PHP에는 사전 컴파일 메커니즘이 없고 OO에 너무 많이 의존하기 때문에(코드는 PHP5로 작성되었지만) 이 프레임워크는 약간 부피가 크고 사용하기 복잡하며 확장성이 좋지 않다고 생각합니다. 그러나 개념은 매우 훌륭하고 일부 아이디어는 며칠 동안 나를 곤혹스럽게 만들었던 문제를 해결했습니다. 아래에서 이 프레임워크를 간략하게 소개하겠습니다.
프레임워크는 ZDE 및 PHP5로 작성되었습니다. 자세한 문서, 매우 명확한 구조 및 충분한 설명이 포함되어 있으며 코드가 매우 읽기 쉬워서 작성자의 코딩 수준이 매우 높다는 것을 알 수 있습니다. 저자는 이 프레임워크가 ASP.NET 및 Borland Delphi의 개념을 참조한다고 분명히 밝혔습니다.
이 프레임워크는 검증에 매우 강력하고(로그인 검증과 같은 모듈이 없음) 매우 견고하며, 외부에서 침투할 수 있는 직접적인 허점이 거의 불가능합니다. 사양 파일의 개념을 도입합니다. , 대규모 검증에서 효율성 병목 현상을 효과적으로 해결합니다. 이 검증 방법의 유일한 문제점은 사양 파일 자체를 생성하는 것이 더 힘들다는 것입니다(물론 도구를 사용하는 것은 또 다른 문제입니다). 사양 파일 자체 형식 및 사양 포함), 매번 사람이 호출할 필요 없이 프레임워크에 의해 검증이 자연스럽게 수행됩니다. 해당 이벤트는 사양 파일에서도 정의할 수 있습니다(필수는 아닌 것 같습니다). 실제로 해당 사양 파일은 DELPHI 또는 VB의 FORM 정의 파일과 다소 유사하지만 XML이 아닌 일반 텍스트로 작성됩니다. 심상. 이벤트 기반의 경우 프레임워크에는 NET과 유사한 기본 이벤트 흐름 세트가 내장되어 있습니다. 실제로 다양한 단계에서 이러한 이벤트를 사용자 정의할 수 있습니다. 이는 이러한 OnXXX 함수를 재정의하고 매개변수를 사용하는 것을 의미합니다. 예를 들어, 자체 구성요소를 정의할 때 나중에 해당 구성요소가 허용하는 기능을 직접 정의할 수 있습니다. 하지만 이 방법은 너무 복잡하고 읽고 분석하기 위해 많은 양의 XML 파일이 필요하다고 생각합니다. 매우 엄격하고 안전하지만 다소 과도하고 PHP 자체의 유연성을 완전히 활용하지 못합니다. 내 생각은 DELPHI와 유사한 것을 사용하는 것입니다. 함수 핸들을 할당하거나 C의 콜백 함수 기능을 사용하면 코드를 작성하는 동안 언제 어디서나 이벤트를 정의할 수 있으며 여전히 이벤트 발신자와 유형을 명확하게 식별할 수 있습니다. 기계가 필요 없이 충분한 보안을 보장하므로 각 구성 요소에 특정 이벤트만 있도록 효과적으로 강제하여 코드 수정 및 확장을 매우 편리하게 만듭니다. 물론 대규모 프로젝트를 작업할 때는 엄격한 정의가 필요하지만, 그럼에도 불구하고 프레임워크의 이벤트 처리 방식은 다소 구식입니다.
템플릿은 컴파일 전 NET의 ASP 파일과 다소 유사하지만(ASP NET에 익숙하지 않지만 몇 가지 원리는 이해합니다) 작동 방식은 DELPHI와 유사한 FORM 파일입니다. 유일한 단점은 DW와 같은 WYSIWYG 일반 편집기를 사용하는 것이 그리 편리하지 않다는 것입니다. 상호 배타적인 여러 구성 요소를 동시에 하나의 템플릿으로 결합하고 어떤 것만 표시할지 결정할 수 있기 때문입니다. 런타임 중.
이 프레임워크의 코드를 보면 여전히 매우 약한 항목이 있다는 것을 알 수 있습니다. 가장 중요한 것은 경로 문제입니다. 확장성이 매우 낮습니다. 전용 호스트에 더 적합해야 합니다. 일부 제한된 호스트(디렉터리 제한 또는 권한 제한)에 대해서는 할 수 있는 일이 없으며 해당 알림 조치도 없습니다( 관련 인터페이스가 없습니다). 특정 리소스나 파일의 경로를 지정하기 위해 AssetService라는 번거로운 메커니즘을 사용하는데, 이 서비스를 사용하면 실제로 시스템 소비가 크게 증가한다고 저자도 밝혔습니다. FLASH의 자산 라이브러리 개념을 사용하면 경로를 임의로 지정할 수 있지만 매번 다시 확인해야 하므로 이득을 얻을 가치가 없습니다. 내 접근 방식은 여러 주요 경로를 수정하는 것이며, 해당 하위 디렉터리는 임의적일 수 있으므로 둘 사이의 모순을 포괄적으로 균형을 맞춥니다. 경로 문제에 대한 고려가 부족하여 프레임워크는 언어 설정, 개인화된 템플릿 등에 무력합니다. 프로젝트를 번역하려면 절차가 복잡하고 작업량이 많고 번역하기가 쉽다고 생각할 수 있습니다. 실수를 하다. 이것이 프레임워크의 가장 심각한 문제입니다.
일반적으로 이 프레임워크의 개념, 디자인 및 코드는 절대적으로 일류입니다. 물론 항상 단점이 있지만 이것이 우리가 그것을 공부하고 배우는 데 전혀 방해가 되지는 않습니다. 나는 그 코드를 전부 읽지는 않았고 몇 가지 핵심 프로그램과 몇 가지 지침만 읽었지만 그 구조와 아이디어를 분명히 알 수 있지만 저자를 깊이 존경하지만 단점도 깊이 후회합니다. 어쨌든 PHP 이벤트 중심 코드를 연구하는 데는 확실히 좋은 작업입니다. 그러므로 적극 추천합니다!