Yii로 빠른 시작 (1)
- 黄舟원래의
- 2016-12-20 11:07:221332검색
전재할 출처를 표시해 주세요: Yii Quick Start(1)
Ⅰ. 기본 개념
1. 항목 파일
항목 파일 내용: 일반적인 형식은
$yii=dirname(__FILE__)입니다. /.. /../framework/yii.php';//Yii 프레임워크 위치
$config=dirname(__FILE__).'/protected/config/main.php';//기본 구성 파일 위치 현재 애플리케이션
//정식 환경 배포 시 다음 줄을 제거
// 정의('YII_DEBUG') 또는 정의('YII_DEBUG',true);//디버그 모드에서 실행할지 여부
require_once($yii);//Yii 프레임워크 포함
Yii::createWebApplication($config)->run();//기본 구성 파일을 기반으로 애플리케이션 인스턴스를 생성하고 실행합니다. . 현재 애플리케이션의 어디에서나 Yii::app()을 통해 이 인스턴스에 액세스할 수 있습니다.
2. 기본 구성 파일
저장 위치: your application/protected/config/main.php
파일 내용: 일반적인 형식은 다음과 같습니다.
return array(
'basePath'=>dirname(__FILE__).DIRECTORY_SEPARATOR.'..', //현재 애플리케이션 루트 디렉터리의 절대 물리적 경로
'name'=>'Yii Blog Demo', //현재 애플리케이션 이름
// 로그(기록) 애플리케이션 컴포넌트를 미리 로드합니다. 즉, 애플리케이션 컴포넌트가 액세스 여부에 관계없이 생성된다는 의미입니다. 애플리케이션은 아래 "컴포넌트"로 구성됩니다. 키워드 배열
'preload'=>array('log'), //log는 컴포넌트 ID입니다
// 자동으로 로드되는 모델 및 컴포넌트 클래스
' import'=>array(
'application.models.*', //"application/models/" 폴더의 모든 모델 클래스 로드
'application.comComponents.*' , //"application/comComponents/" 폴더 아래의 모든 애플리케이션 컴포넌트 클래스 로드
),
'defaultController'=>'post', //기본 컨트롤러 클래스 설정
// 현재 애플리케이션의 구성요소 구성에 대한 자세한 내용은 아래 "핵심 애플리케이션 구성요소"를 참조하세요.
'comComponents'=>array(
'user'=>array( //user (사용자 ) 구성 요소 구성, "User"는 구성 요소 ID입니다
// 쿠키 기반 인증을 사용할 수 있습니다
'allowautologin' = & gt; true, // 자동 로그인 허용
),
'캐시 ' = & gt; 배열( //캐시 구성요소
~ > ~ ' Weight'=>40), //캐시 서버 2
),
),
'db'=>array( //db(데이터베이스) 컴포넌트 구성, "db"는 컴포넌트 ID입니다.
'connectionString' => 'sqlite:protected/data/blog.db', //데이터베이스에 연결하기 위한 DSN 문자열
'tablePrefix' => 'tbl_', // 데이터 테이블 접두사
) ,
// MySQL 데이터베이스를 사용하려면 다음 주석을 해제하세요.
'erRraRantion' = & gt; 'site/error', // 오류가 발생하면 실행됩니다. 컨트롤러 이름과 메서드 이름은 모두 소문자이며 슬래시로 구분됩니다. "/"
),
//URL 라우팅 관리자
'urlManager'=>array(
'urlFormat'=>'경로', //URL 형식입니다. 두 가지 형식이 지원됩니다: '경로' 형식(예: /path/to/EntryScript.php/name1/value1/name2/value2...) 및 'get' 형식(예: /path/to/EntryScript.php ? 이름1=값1&이름2=값2...). 'path' 형식을 사용할 때 다음 규칙을 설정해야 합니다: id:d+>/
'posts/
w+>'=>'
),
),
), '로그' =>array( //기록
'class' = & gt; 'Clogrouter', // 레코드 정보를 처리하는 클래스
'Routes' = & GT; Array(
Array(
'class' = & gt; 'cfileLogroute ', //
'levels' = & gt; 'error, warning', // 오류 수준
),
// 웹 페이지에 오류 기록 메시지를 표시하려면 댓글을 취소하세요. 아래애플리케이션 계층 매개변수
'params'=>require(dirname(__FILE__).'/params.php'),
);
핵심 애플리케이션 구성 요소:
Yii 사전 정의됨 일반적인 웹 애플리케이션에서 사용되는 기능을 제공하는 핵심 애플리케이션 구성요소 세트입니다. 예를 들어 요청 구성 요소는 사용자 요청을 구문 분석하고 URL, 쿠키 등과 같은 정보를 제공하는 데 사용됩니다. 이러한 핵심 구성요소의 속성을 구성함으로써 Yii의 기본 동작을 거의 임의로 수정할 수 있습니다.
아래에는 CWebApplication에서 사전 정의한 핵심 구성 요소가 나열되어 있습니다.
assetManager: CAssetManager - 개인 자산 파일의 릴리스를 관리합니다.
authManager: CAuthManager - 역할 기반 액세스 제어(RBAC)를 관리합니다.
cache: CCache - 데이터 캐싱 기능을 제공합니다. 실제 클래스(예: CMemCache, CDbCache)를 지정해야 합니다. 그렇지 않으면 이 구성 요소에 액세스할 때 NULL이 반환됩니다.
clientScript: CClientScript - 클라이언트측 스크립트(javascript 및 CSS)를 관리합니다.
coreMessages: CPhpMessageSource - Yii 프레임워크에서 사용되는 핵심 메시지의 번역을 제공합니다.
db: CDbConnection - 데이터베이스 연결을 제공합니다. 이 구성 요소를 사용하려면 해당 연결 문자열 속성을 구성해야 합니다.
errorHandler: CErrorHandler - 발견되지 않은 PHP 오류 및 예외를 처리합니다.
형식: CFormatter - 형식화된 숫자 표시입니다. 이 기능은 버전 1.1.0부터 사용할 수 있습니다.
메시지: CPhpMessageSource - Yii 애플리케이션에 사용되는 메시지 번역을 제공합니다.
request: CHttpRequest - 사용자의 요청에 대한 정보를 제공합니다.
securityManager: CSecurityManager - 해싱, 암호화 등 보안 관련 서비스를 제공합니다.
session: CHttpSession - 세션 관련 기능을 제공합니다.
statePersister: CStatePersister - 전역 상태 지속성 방법을 제공합니다.
urlManager: CUrlManager - URL 파싱 및 생성 관련 기능을 제공합니다.
user: CWebUser - 현재 사용자의 식별 정보를 제공합니다.
themeManager: CThemeManager - 테마를 관리합니다.
애플리케이션 컴포넌트에 접근하려면 Yii::app()->컴포넌트 ID를 사용하세요
3. Controller(Controller)
Controller는 CController 클래스의 하위 클래스 인스턴스입니다. 사용자가 요청할 때 애플리케이션에 의해 생성됩니다. 컨트롤러가 실행되면 일반적으로 필요한 모델을 도입하고 해당 뷰를 렌더링하는 요청된 작업(컨트롤러 클래스 메서드)을 수행합니다. 액션은 이름이 액션(액션 + 대문자로 된 액션 이름)으로 시작하는 컨트롤러 클래스 메서드입니다.
컨트롤러 클래스 파일은 protected/controllers/
컨트롤러와 액션은 ID로 식별됩니다.
컨트롤러 ID는 '상위 디렉토리/하위 디렉토리/컨트롤러 이름' 형식으로, 해당 컨트롤러 클래스 파일 protected/controllers/상위 디렉토리/하위 디렉토리/컨트롤러 이름(대문자 Controller.php)에 해당합니다.
작업 ID는 작업 접두사가 없는 작업 메서드 이름입니다.
1. 라우팅
사용자는 라우팅 형태로 특정 컨트롤러와 작업을 요청합니다. 경로는 슬래시로 구분된 컨트롤러 ID와 작업 ID로 연결됩니다.
예를 들어 post/edit 경로는 PostController와 해당 편집 작업을 나타냅니다. 기본적으로 URL http://hostname/index.php?r=post/edit는 이 컨트롤러와 작업을 요청합니다.
참고: 기본적으로 경로는 대소문자를 구분합니다. 응용 프로그램 구성에서 CUrlManager::caseSensitive를 false로 설정하여 라우팅에서 대/소문자를 구분하지 않도록 할 수 있습니다. 대소문자를 구분하지 않는 모드에서는 컨트롤러 클래스 파일이 포함된 디렉터리 이름이 소문자이고 컨트롤러 맵과 작업 맵에 사용되는 키가 소문자라는 규칙을 따라야 합니다.
라우팅 형식: 컨트롤러 ID/액션 ID 또는 모듈 ID/컨트롤러 ID/액션 ID(중첩 모듈인 경우 모듈 ID는 상위 모듈 ID/하위 모듈 ID)
컨트롤러 인스턴스화
애플리케이션은 다음 규칙을 사용하여 컨트롤러 클래스와 클래스 파일의 위치를 결정합니다.
1. CWebApplication::catchAllRequest가 지정된 경우 컨트롤러는 이 속성을 기반으로 생성되며 사용자가 지정한 컨트롤러 ID는 무시됩니다. 이는 일반적으로 애플리케이션을 유지 관리 상태로 전환하고 정적 프롬프트 페이지를 표시하는 데 사용됩니다.
2. CWebApplication::controllerMap에서 ID를 찾으면 해당 컨트롤러 구성을 사용하여 컨트롤러 인스턴스를 생성합니다.
3. ID가 'path/to/xyz' 형식인 경우 컨트롤러 클래스 이름은 XyzController로 판단되며 해당 클래스 파일은 protected/controllers/path/to/XyzController입니다. .php. 클래스 파일이 없으면 404 CHttpException이 트리거됩니다.
모듈의 경우 애플리케이션은 이 ID가 모듈의 컨트롤러를 나타내는지 확인합니다. 그렇다면 모듈 인스턴스가 먼저 생성되고 모듈 내의 컨트롤러 인스턴스가 생성됩니다.
3. 액션
액션은 액션이라는 단어를 접두사로 하여 명명된 메서드로 정의됩니다. 더 발전된 방법은 액션 클래스를 정의하고 컨트롤러가 요청을 받을 때 이를 인스턴스화하도록 하는 것입니다. 이를 통해 작업을 재사용할 수 있어 재사용성이 향상됩니다.
1. 액션 클래스를 정의합니다. 기본 형식은 다음과 같습니다.
class UpdateAction extends CAction
{
public function run()
{
// 여기에 액션 로직을 배치합니다.
}
}
2. 액션 클래스 사용: 컨트롤러가 이 액션을 알 수 있도록 하려면 다음과 같은 방법으로 컨트롤러 클래스의 actions() 메서드를 재정의해야 합니다.
class PostController 확장 CController
{
공용 함수 actions()
{
return array(
.php" 파일을 편집 작업
);
}
}
위에 표시된 대로 "application.controllers.post.UpdateAction" 경로 별칭을 사용하여 "protected/controllers/post/UpdateAction.php" 액션 클래스 파일을 지정했습니다.
클래스 기반 액션을 작성하면 애플리케이션을 모듈 스타일로 구성할 수 있습니다. 예를 들어, 다음 디렉토리 구조를 사용하여 컨트롤러 관련 코드를 구성할 수 있습니다:
protected/
Controllers/
PostController.php
UserController.php
post/
CreateAction.php
ReadAction .php
UpdateAction.php 업데이트 작업 UpdateAction.php
필터
필터는 컨트롤러 작업 전후에 실행되도록 구성할 수 있는 코드 조각입니다.
작업 하나에 여러 개의 필터가 있을 수 있습니다. 필터가 여러 개인 경우 필터 목록에 나타나는 순서대로 실행됩니다. 필터는 작업 및 기타 후속 필터가 실행되는 것을 방지할 수 있습니다.
필터는 컨트롤러 클래스의 메서드로 정의될 수 있습니다. 필터 메소드 이름은 filter로 시작해야 합니다. 예를 들어 기존 filterAccessControl 메서드는 accessControl이라는 필터를 정의합니다. 필터 메소드는 다음 구조를 가져야 합니다:
public function filterAccessControl($filterChain)
{
// $filterChain->run()을 호출하여 후속 필터 및 작업 실행을 계속합니다.
}
$filterChain(필터 체인)은 요청된 작업과 관련된 필터 목록을 나타내는 CFilterChain의 인스턴스입니다. 필터 메소드 내에서 $filterChain->run()을 호출하여 후속 필터와 작업을 계속 실행할 수 있습니다.
액션과 마찬가지로 필터도 객체일 수 있습니다. 객체는 CFilter의 인스턴스이거나 해당 하위 클래스 중 하나입니다. 다음 코드는 새로운 필터 클래스를 정의합니다:
class PerformanceFilter extends CFilter
{
protected function preFilter($filterChain)
{
// 액션이 실행되기 전에 적용되는 로직
Return true; // 액션을 실행하지 말아야 할 경우 false를 반환하세요.
}
protected function postFilter($filterChain)
{
// 액션 실행 후 적용되는 로직
}
}
액션에 필터를 적용하려면 CController::filters() 메서드를 재정의해야 합니다. 이 메소드는 필터 구성 배열을 반환해야 합니다. 예:
class PostController는 CController를 확장합니다
{
...
public functionfilters()
{
return array(
'postOnly + edit, create' , / /postOnly 필터를 편집 및 생성 작업에 적용합니다(메서드 기반 필터입니다)
array( //필터를 구성하는 데 배열이 사용됩니다. , // 편집을 제외한 모든 항목에 application.filters.perFormancefilter 필터를 적용합니다. 및 생성(객체 기반 필터)
'unit' = & gt;의 단위 속성 값은 두 번째입니다
),
);
}
}
위 코드는 postOnly와 PerformanceFilter라는 두 가지 필터를 지정합니다. postOnly 필터는 메소드 기반입니다(해당 필터 메소드는 CController에 정의되어 있음).performanceFilter 필터는 객체 기반입니다. 경로 별칭 application.filters.PerformanceFilter는 필터 클래스 파일이 protected/filters/PerformanceFilter임을 지정합니다. 필터 개체의 속성 값을 초기화하는 데 사용할 수 있도록 PerformanceFilter를 배열로 구성합니다. 여기서 PerformanceFilter의 단위 속성 값은 초로 초기화됩니다.
더하기 및 빼기 기호를 사용하여 필터를 적용해야 하거나 적용하지 말아야 하는 작업을 지정할 수 있습니다. 위 코드에서 postOnly는 edit, create 액션에만 적용되어야 하고, PerformanceFilter는 edit, create 액션이 아닌 액션에만 적용되어야 합니다. 필터 구성에 더하기 또는 빼기 기호가 사용되지 않으면 이 필터가 모든 작업에 적용됩니다.
5. 모델(Model)
모델은 CModel 또는 그 하위 클래스의 인스턴스입니다. 모델은 데이터 및 이와 관련된 비즈니스 논리를 보유하는 데 사용됩니다.
모델은 별도의 데이터 개체입니다. 데이터 테이블의 행일 수도 있고 사용자가 입력한 양식일 수도 있습니다.
데이터 객체의 각 필드는 모델의 속성에 해당합니다. 각 속성에는 라벨이 있으며 일련의 규칙으로 확인할 수 있습니다.
Yii는 폼 모델과 액티브 레코드라는 두 가지 모델을 구현합니다. 둘 다 동일한 기본 클래스 CModel에서 상속됩니다.
양식 모델은 CFormModel의 인스턴스입니다. 양식 모델은 사용자 입력에서 얻은 데이터를 보유하는 데 사용됩니다. 이 데이터는 종종 획득, 사용 및 폐기됩니다. 예를 들어 로그인 페이지에서 양식 모델을 사용하여 최종 사용자가 제공한 사용자 이름과 비밀번호 정보를 나타낼 수 있습니다.
AR(Active Record)은 객체 지향 스타일로 데이터베이스 액세스를 추상화하기 위한 디자인 패턴입니다. 각 AR 개체는 CActiveRecord의 인스턴스 또는 해당 하위 클래스 중 하나입니다. 데이터 테이블의 행을 나타냅니다. 행의 필드는 AR 개체의 속성에 해당합니다.
6. 뷰
뷰는 주요 사용자 상호작용 요소를 포함하는 PHP 스크립트입니다.
뷰에는 렌더링 시 뷰 스크립트 파일을 식별하는 데 사용되는 이름이 있습니다. 보기 이름은 보기 스크립트 이름과 동일합니다. 예를 들어, 뷰 편집의 이름은 edit.php라는 스크립트 파일에서 나옵니다. 렌더링하려면 뷰 이름을 전달하여 CController::render()를 호출하세요. 이 방법은 "protected/views/controller ID" 디렉터리에서 해당 보기 파일을 검색합니다.
뷰 스크립트 내에서 $this를 통해 컨트롤러 인스턴스에 액세스할 수 있습니다. "$this->property name"을 사용하여 뷰에서 컨트롤러의 모든 속성을 가져올 수 있습니다.
다음 푸시 메소드를 사용하여 뷰에 데이터를 전달할 수도 있습니다.
$this->render('edit', array(
'var1'=>$value1,
' var2 '=>$value2,
));
위 메소드에서 render() 메소드는 배열의 두 번째 매개변수를 변수로 추출합니다. 그 결과 뷰 스크립트에서 $var1 및 $var2 변수에 직접 액세스할 수 있습니다.
1. 레이아웃
레이아웃은 뷰를 수정하는 데 사용되는 특수 뷰 파일입니다. 일반적으로 사용자 인터페이스 보기의 공통 부분이 포함됩니다. 예를 들어 레이아웃에는 머리글과 바닥글 부분이 포함될 수 있으며 그 사이에 콘텐츠가 포함될 수 있습니다.
......머리글은 여기......
......바닥글은 여기..... .
$content는 콘텐츠 보기의 렌더링 결과를 저장합니다.
render()를 사용하면 레이아웃이 암시적으로 적용됩니다. 보기 스크립트 protected/views/layouts/main.php가 기본 레이아웃 파일입니다. 이는 CWebApplication::layout을 변경하여 사용자 정의할 수 있습니다. 레이아웃 없이 뷰를 렌더링하려면 renderPartial() 을 호출하세요.
2. 작은 개체
작은 개체는 CWidget 또는 그 하위 클래스의 인스턴스입니다. 데이터를 표현하는데 주로 사용되는 컴포넌트입니다. 위젯은 복잡하고 독립적인 사용자 인터페이스를 생성하기 위해 뷰에 포함되는 경우가 많습니다. 예를 들어 달력 위젯을 사용하여 복잡한 달력 인터페이스를 렌더링할 수 있습니다. Gizmos는 사용자 인터페이스를 더욱 재사용 가능하게 만듭니다.
다음 뷰 스크립트에 따라 위젯을 사용할 수 있습니다:
beginWidget('위젯 클래스의 경로 별칭'[,'속성 초기화 값을 포함하는 배열']) ? >
...위젯에서 얻을 수 있는 콘텐츠 본문...
endWidget() ?>
또는
widget('위젯 클래스의 경로 별칭'[,'속성 초기화 값을 포함하는 배열']) ?>
후자는 본문 내용이 필요하지 않은 구성 요소에 사용됩니다.
위젯은 성능을 맞춤설정하도록 구성할 수 있습니다. 이는 CBaseController::beginWidget 또는 CBaseController::widget을 호출하여 초기화 속성 값을 설정함으로써 수행됩니다.
이러한 속성의 초기화 값을 전달하는 배열을 전달하여 이를 수행합니다. 배열의 키는 속성의 이름이고 배열의 값은 작은 개체 속성에 해당하는 값입니다. 아래와 같이:
$this->widget('CMaskedTextField',array(
'mask'=>'99/99/9999'
));
?>
CWidget을 상속하고 init() 및 run() 메서드를 재정의하여 새 위젯을 정의합니다.
class MyWidget은 CWidget을 확장합니다
{
public function init()
{
// 이 메서드는 CController::beginWidget()에 의해 호출됩니다.
}
public function run()
{
// 이 메서드는 CController::endWidget()에 의해 호출됩니다.
}
}
위젯을 호출하면 컨트롤러처럼 자체 보기를 가질 수 있습니다.
기본적으로 위젯의 보기 파일은 위젯 클래스 파일 디렉터리가 포함된 views 하위 디렉터리(protected/comComponents/views) 아래에 있습니다. 이러한 뷰는 컨트롤러와 마찬가지로 CWidget::render()를 호출하여 렌더링할 수 있습니다. 유일한 차이점은 위젯의 보기에는 레이아웃 파일 지원이 없다는 것입니다. 또한 위젯 뷰의 $this는 컨트롤러 인스턴스가 아닌 위젯 인스턴스를 가리킵니다.
3. 시스템 뷰
시스템 뷰 렌더링은 일반적으로 Yii 오류 및 로그 정보를 표시하는 데 사용됩니다.
시스템 뷰의 이름은 몇 가지 규칙을 따릅니다. 예를 들어 "errorXXX"와 같은 이름은 오류 번호 XXX와 함께 CHttpException을 표시하는 뷰를 렌더링하는 데 사용됩니다. 예를 들어 CHttpException이 404 오류를 발생시키면 error404가 표시됩니다.
프레임워크/뷰에서 Yii는 일련의 기본 시스템 뷰를 제공하며 protected/views/system에서 동일한 이름의 뷰 파일을 생성하여 사용자 정의할 수 있습니다.
7. 구성요소
Yii 애플리케이션은 구성요소를 기반으로 구축됩니다. 구성 요소는 CComponent의 인스턴스이거나 해당 하위 클래스 중 하나입니다. 구성 요소를 사용하는 것은 주로 해당 속성에 액세스하고 이를 트리거하거나 처리할 시기를 포함합니다. 기본 클래스 CComponent는 속성과 이벤트가 정의되는 방법을 지정합니다.
1. 구성요소 속성
구성요소의 속성은 객체의 공용 멤버 변수와 같습니다. 읽고 쓸 수 있습니다.
컴포넌트 속성을 정의하려면 컴포넌트 클래스에 공용 멤버 변수만 정의하면 됩니다.
더 유연한 방법은 getter 및 setter 메서드를 정의하는 것입니다. 예를 들면 다음과 같습니다.
public function getTextWidth() // textWidth 속성 가져오기
{
return $this->_textWidth;
}
public function setTextWidth($value) // TextWidth 속성 설정
{
$this->_textWidth=$value;
}
위 코드는 textWidth(이름은 대소문자를 구분하지 않음)라는 쓰기 가능한 속성을 정의합니다. 속성을 읽으면 getTextWidth()가 호출되고 해당 반환 값은 속성 값이 됩니다. 마찬가지로 속성이 기록되면 setTextWidth()가 호출됩니다. setter 메서드가 정의되지 않은 경우 속성은 읽기 전용이 되며 속성에 기록하면 예외가 발생합니다. getter 및 setter 메서드를 사용하여 속성을 정의하면 속성을 읽거나 쓸 때 추가 논리가 수행될 수 있다는 이점이 있습니다(예: 유효성 검사 수행, 이벤트 트리거).
참고: getter/setter를 통해 정의된 속성과 클래스 멤버 변수 사이에는 미묘한 차이가 있습니다. 속성 이름은 대소문자를 구분하지만 클래스 멤버 변수는 대소문자를 구분합니다.
2. 컴포넌트 이벤트
컴포넌트 이벤트는 이벤트 핸들러라는 메소드를 값으로 사용하는 특수 속성입니다. 이벤트에 메서드를 할당하면 이벤트가 발생할 때 메서드가 자동으로 호출됩니다. 따라서 구성 요소 개발 중에 예상하지 못한 방식으로 구성 요소의 동작이 수정될 수 있습니다.
구성요소 이벤트는 on으로 시작하는 이름으로 정의됩니다. getter/setter 메소드를 통해 정의된 속성과 마찬가지로 이벤트 이름은 대소문자를 구분하지 않습니다. 다음 코드는 onClicked 이벤트를 정의합니다.
public function onClicked($event)
{
$this->raiseEvent('onClicked', $event);
}
여기서 event $event 매개변수는 CEvent의 인스턴스 또는 해당 하위 클래스 중 하나입니다.
다음과 같이 이 이벤트에 메소드를 할당할 수 있습니다.
$comComponent->onClicked=$callback;
여기서 $callback은 유효한 PHP 콜백을 가리킵니다. 전역 함수일 수도 있고 클래스의 메서드일 수도 있습니다. 후자의 경우 배열(array($object,'methodName'))로 제공되어야 합니다.
이벤트 핸들의 구조는 다음과 같습니다.
함수 메서드 이름($event)
{
...
}
$event 여기에서 이벤트를 설명하는 매개 변수( raiseEvent() 호출에서 발생). $event 매개변수는 CEvent의 인스턴스 또는 해당 서브클래스 중 하나입니다. 최소한 이벤트를 트리거한 사람에 대한 정보가 포함되어 있습니다.
이벤트 핸들러는 PHP 5.3 이상에서 지원되는 익명 함수일 수도 있습니다. 예:
$comComponent->onClicked=function($event) {
...
}
지금 onClicked()를 호출하면 onClicked 이벤트가 트리거됩니다( onClicked( )), 연결된 이벤트 핸들러가 자동으로 호출됩니다.
이벤트는 여러 핸들에 바인딩될 수 있습니다. 이벤트가 발생하면 이러한 핸들러는 이벤트에 바인딩된 순서대로 실행됩니다. 핸들러가 후속 핸들러가 실행되지 않도록 결정하면 $event->handled를 true로 설정합니다.
3. 구성 요소 동작
구성 요소에 mixin에 대한 지원이 추가되었으며 하나 이상의 동작을 바인딩할 수 있습니다. 동작은 특수한 상속(예: 일반 클래스 상속)이 아니라 함수를 수집하여 바인딩된 구성 요소에 메서드를 상속할 수 있는 개체입니다. 구성 요소는 '다중 상속'을 통해 여러 동작의 바인딩을 구현할 수 있습니다.
Behavior 클래스는 IBehavior 인터페이스를 구현해야 합니다. 대부분의 동작은 CBeavior 에서 상속될 수 있습니다. 동작을 모델에 바인딩해야 하는 경우 모델에 대해 특별히 바인딩 속성을 구현하는 CModelBehavior 또는 CActiveRecordBehavior에서 상속할 수도 있습니다.
비헤이비어를 사용하려면 먼저 이 비헤이비어의 attachment() 메서드를 호출하여 구성 요소에 바인딩해야 합니다. 그런 다음 구성 요소를 통해 이 동작 메서드를 호출할 수 있습니다.
// $name은 구성 요소의 동작을 고유하게 식별합니다.
$comComponent->attachBehavior($name,$behavior);
// test() 행동의 방법이다.
$comComponent->test();
바운드 동작은 구성 요소의 일반 속성처럼 액세스할 수 있습니다. 예를 들어 tree라는 동작이 구성 요소에 바인딩된 경우 다음 코드를 통해 이 동작에 대한 참조를 얻을 수 있습니다.
$behavior=$comComponent->tree;
//는 다음 코드와 같습니다.
// $behavior=$comComponent->asa('tree');
동작은 다음과 같습니다. 일시적으로 금지된 경우 해당 메서드는 구성 요소에서 유효하지 않습니다. 예:
$comComponent->disableBehavior($name);
// 다음 코드는 예외를 발생시킵니다
$comComponent->test();
$comComponent->enableBehavior ($name);
// 이제 사용할 수 있습니다
$comComponent->test();
동일한 이름을 가진 두 개의 동작을 동일한 구성요소에 바인딩하는 것이 가능합니다. 이 경우 먼저 바인딩하는 작업이 우선 적용됩니다.
이벤트와 함께 사용하면 동작이 더욱 강력해집니다. 동작이 구성 요소에 바인딩되면 동작의 일부 메서드가 구성 요소의 일부 이벤트에 바인딩될 수 있습니다. 이런 방식으로 동작을 유기적으로 관찰하거나 구성 요소의 일반적인 실행 흐름을 변경할 수 있습니다.
동작의 속성은 바인딩된 구성 요소를 통해 액세스할 수도 있습니다. 이러한 속성에는 공용 멤버 변수와 getter 및/또는 setter를 통해 설정된 속성이 포함됩니다. 예를 들어, 동작에 xyz 속성이 있고 이 동작이 $a 구성 요소에 바인딩된 경우 $a->xyz 표현식을 사용하여 이 동작의 속성에 액세스할 수 있습니다.
8. 모듈
모듈은 모델, 뷰, 컨트롤러 및 기타 지원 구성 요소를 포함하는 독립적인 소프트웨어 단위입니다. 여러 면에서 모듈은 애플리케이션처럼 보입니다. 주요 차이점은 모듈을 개별적으로 배포할 수 없으며 애플리케이션 내에 있어야 한다는 것입니다. 사용자는 일반 애플리케이션에서 컨트롤러에 액세스하는 것처럼 모듈의 컨트롤러에 액세스할 수 있습니다.
모듈은 일부 시나리오에서 유용합니다. 대규모 애플리케이션의 경우 여러 모듈로 나누어야 할 수 있으며 각 모듈은 독립적으로 유지 관리 및 배포될 수 있습니다. 사용자 관리, 댓글 관리 등 일부 공통 기능을 모듈 형태로 개발해 향후 프로젝트에서 쉽게 재사용할 수 있습니다.
1. 모듈 생성
모듈은 디렉토리로 구성되며, 디렉토리 이름은 모듈의 고유 ID입니다. 모듈 디렉터리의 구조는 응용 프로그램 기본 디렉터리와 매우 유사합니다. Fourm 모듈의 일반적인 디렉토리 구조 아래:
포럼/모듈 폴더
forummodule.php 모듈 파일
구성 요소/재사용 가능한 사용자 구성 요소 포함
보기/작은 개체의 보기 파일 포함
컨트롤러/ 포함 컨트롤러 클래스 파일
DefaultController.php 기본 컨트롤러 클래스 파일
Extensions/ 타사 확장 포함
models/ 모델 클래스 파일 포함
views/ 컨트롤러 뷰 및 레이아웃 파일 포함
레이아웃/ 레이아웃 포함 files
default/ DefaultController에 대한 보기 파일이 포함되어 있습니다.
index.php 홈 페이지 보기 파일
모듈 CWebModule에서 상속되는 모듈 클래스가 있어야 합니다. 클래스 이름은 ucfirst($id).'Module' 표현식으로 결정됩니다. 여기서 $id는 모듈의 ID(또는 모듈의 디렉터리 이름)를 나타냅니다. 모듈 클래스는 모듈 코드 간에 공유할 수 있는 정보를 저장하는 중심 장소입니다. 예를 들어 CWebModule::params를 사용하여 모듈 매개변수를 저장하고 CWebModule::comComponents를 사용하여 모듈 수준 애플리케이션 구성 요소를 공유할 수 있습니다.
2. 모듈 사용
모듈을 사용하려면 먼저 애플리케이션 기본 디렉토리의 모듈 폴더에 모듈 디렉토리를 배치합니다. 그런 다음 앱의 모듈 속성에서 모듈 ID를 선언하세요. 예를 들어 위의 포럼 모듈을 사용하려면 다음 애플리케이션 구성을 사용할 수 있습니다.
return array(
...
'modules'=>array('forum',... ) ,
...
);
모듈은 초기 속성 값으로 구성될 수도 있습니다. 접근 방식은 애플리케이션 구성 요소를 구성하는 것과 매우 유사합니다. 예를 들어, 포럼 모듈은 모듈 클래스에 postPerPage라는 속성을 가질 수 있으며, 이는 다음과 같이 애플리케이션 구성에서 구성할 수 있습니다:
return array(
...
'modules'=> ;array (
'forum'=>array(
'postPerPage'=>20,
),
),
...
);
모듈 인스턴스 현재 활성 컨트롤러의 모듈 속성을 통해 액세스할 수 있습니다. 모듈 인스턴스 내에서 모듈 수준에서 공유된 정보에 액세스할 수 있습니다. 예를 들어 위의 postPerPage 정보에 액세스하려면 다음 표현식을 사용할 수 있습니다.
$postPerPage=Yii::app()->controller->module->postPerPage;
// 예: $ this 컨트롤러 인스턴스가 참조되는 경우 다음 문을 사용할 수 있습니다.
// $postPerPage=$this->module->postPerPage;
모듈의 컨트롤러 작업은 "모듈 ID/컨트롤러 ID/작업 ID" 또는 "모듈 ID/컨트롤러 클래스 파일이 저장된 하위 디렉터리 이름/컨트롤러 ID/작업 ID" 경로를 통해 액세스할 수 있습니다. 예를 들어 위의 포럼 모듈에 PostController라는 컨트롤러가 있다고 가정하면 forum/post/create 경로를 통해 이 컨트롤러의 생성 작업에 액세스할 수 있습니다. 이 경로에 해당하는 URL은 http://www.example.com/index.php?r=forum/post/create입니다.
3. 중첩 모듈
모듈은 무한히 중첩될 수 있습니다. 이는 하나의 모듈이 다른 모듈을 포함할 수 있고, 다른 모듈이 다른 모듈을 포함할 수 있음을 의미합니다. 전자를 상위 모듈, 후자를 하위 모듈이라고 부릅니다. 하위 모듈은 이전에 애플리케이션 구성에서 모듈을 정의한 것처럼 상위 모듈의 모듈 속성에서 정의되어야 합니다.
하위 모듈의 컨트롤러 작업에 액세스하려면 경로 상위 모듈 ID/하위 모듈 ID/컨트롤러 ID/작업 ID를 사용해야 합니다.
9. 경로 별칭
경로 별칭은 Yii에서 널리 사용됩니다. 경로 별칭은 디렉터리 또는 파일의 경로와 연결됩니다. 이는 널리 사용되는 네임스페이스 형식과 유사한 도트 구문으로 지정됩니다.
RootAlias.path.to.target
여기서 RootAlias는 YiiBase::setPathOfAlias( )를 호출하여 기존 디렉터리의 별칭입니다. 새로운 경로 별칭을 정의할 수 있습니다. 편의를 위해 Yii는 다음 루트 별칭을 미리 정의합니다.
system: Yii 프레임워크 디렉터리를 나타냅니다.
zii: Zii 라이브러리 디렉터리를 나타냅니다.
application: 애플리케이션의 기본 디렉터리를 나타냅니다. 항목 스크립트 파일이 있는 디렉터리를 나타냅니다.
ext: 모든 타사 확장 기능이 포함된 디렉터리를 나타냅니다.
또한 애플리케이션이 모듈을 사용하는 경우 (Yii)는 각 모듈 ID에 대한 루트 별칭을 정의하여 해당 모듈의 루트 디렉터리를 가리킵니다.
YiiBase::getPathOfAlias()를 사용하면 별칭을 해당 경로로 변환할 수 있습니다.
별칭을 사용하면 클래스 정의를 쉽게 가져올 수 있습니다. 예를 들어 CController 클래스의 정의를 포함하려면 다음 코드를 호출하면 됩니다.
Yii::import('system.web.CController');
가져오기 방법은 include 및 require와 다릅니다. , 더 효율적입니다. 가져온 클래스 정의는 처음 참조될 때까지 실제로 포함되지 않습니다. 동일한 네임스페이스를 여러 번 가져오는 것이 include_once 및 require_once보다 훨씬 빠릅니다.
또한 다음 구문을 사용하여 전체 디렉터리를 가져올 수 있으므로 필요할 때 이 디렉터리의 클래스 파일이 자동으로 포함됩니다.
Yii::import('system.web.*');
가져오기 외에도 별칭은 다른 여러 위치의 클래스를 가리킵니다. 예를 들어 경로 별칭을 Yii::createComponent()에 전달하여 해당 클래스의 인스턴스를 만들 수 있습니다. 클래스 파일이 이전에 포함된 적이 없더라도 마찬가지입니다.
경로 별칭을 네임스페이스와 혼동하지 마세요. 네임스페이스는 클래스 이름이 동일하더라도 서로 구별될 수 있도록 논리적으로 조합한 것입니다. 경로 별칭은 클래스 파일이나 디렉터리를 가리키는 데 사용됩니다. 경로 별칭은 네임스페이스와 충돌하지 않습니다.
10. 개발 사양
아래에서는 Yii 프로그래밍에서 권장되는 개발 사양을 설명합니다. 단순화를 위해 WebRoot가 Yii 애플리케이션이 설치된 디렉터리라고 가정해 보겠습니다.
1. URL
기본적으로 Yii는 다음 형식의 URL을 인식합니다.
http://hostname/index.php?r=ControllerID/ActionID
r 변수는 경로를 의미하며, Yii가 컨트롤러와 액션으로 파싱합니다. ActionID가 생략되면 컨트롤러는 기본 작업(CController::defaultAction에 정의됨)을 사용합니다. ControllerID도 생략되면(또는 r 변수가 존재하지 않으면) 응용 프로그램은 기본 컨트롤러(CWebApplication::defaultController에 정의됨)를 사용합니다. ).
CUrlManager의 도움으로 http://hostname/ControllerID/ActionID.html과 같이 보다 식별 가능하고 SEO 친화적인 URL을 만들 수 있습니다.
2. 코드
Yii는 변수, 함수, 클래스 이름을 지정할 때 카멜 케이스 스타일을 사용할 것을 권장합니다. 즉, 각 단어의 첫 글자는 대문자로 사용하고 공백 없이 서로 연결됩니다. 변수 및 함수 이름은 클래스 이름과 구별하기 위해 첫 번째 단어가 모두 소문자여야 합니다. 비공개 클래스 멤버 변수의 경우 이름 앞에 밑줄을 붙이는 것이 좋습니다(예: $_actionList).
컨트롤러 클래스 이름의 특별한 규칙은 Controller라는 단어로 끝나야 한다는 것입니다. 그런 다음 컨트롤러 ID는 소문자로 된 클래스 이름의 첫 글자이고 Controller라는 단어가 제거됩니다. 예를 들어 PageController 클래스의 ID는 page입니다. 이 규칙은 애플리케이션을 더욱 안전하게 만듭니다. 또한 컨트롤러 관련 URL을 더 단순하게 만듭니다(예: /index.php?r=PageController/index 대신 /index.php?r=page/index).
3. 구성
구성은 키-값 쌍의 배열입니다. 각 키는 구성된 객체의 속성 이름을 나타내며, 각 값은 해당 속성의 초기 값입니다.
클래스의 쓰기 가능한 모든 속성을 구성할 수 있습니다. 구성되지 않은 경우 속성은 기본값을 사용합니다. 속성을 구성할 때 초기값이 올바른지 확인하기 위해 설명서를 읽어보는 것이 좋습니다.
4. 파일
파일 이름 지정 및 사용 규칙은 파일 유형에 따라 다릅니다.
클래스 파일은 포함된 공개 클래스의 이름을 따서 명명되어야 합니다. 예를 들어 CController 클래스는 CController.php 파일에 있습니다. 공개 클래스는 다른 클래스에서 사용할 수 있는 클래스입니다. 각 클래스 파일에는 최대 하나의 공용 클래스가 포함되어야 합니다. 프라이빗 클래스(하나의 퍼블릭 클래스에서만 사용할 수 있는 클래스)는 이를 사용하는 퍼블릭 클래스와 동일한 파일에 배치할 수 있습니다.
뷰 파일의 이름은 뷰 이름을 따라 지정해야 합니다. 예를 들어, 인덱스 보기는 index.php 파일에 있습니다. 뷰 파일은 콘텐츠를 렌더링하는 데 사용되는 HTML 및 PHP 코드가 포함된 PHP 스크립트 파일입니다.
구성 파일 이름은 임의로 지정할 수 있습니다. 구성 파일은 구성을 구현하는 연관 배열을 반환하는 것이 주요 목적인 PHP 스크립트입니다.
5. 디렉터리
Yii는 다양한 상황에 맞는 일련의 기본 디렉터리를 가정합니다. 필요한 경우 각 디렉토리를 사용자 정의할 수 있습니다.
WebRoot/protected: 보안에 민감한 모든 PHP 스크립트와 데이터 파일이 저장되는 애플리케이션 기본 디렉터리입니다. Yii에는 이 디렉터리를 가리키는 기본 애플리케이션 별칭이 있습니다. 이 디렉토리와 그 안에 있는 파일은 웹 사용자의 액세스로부터 보호되어야 합니다. CWebApplication::basePath를 통해 사용자 정의할 수 있습니다.
WebRoot/protected/runtime: 이 디렉터리에는 애플리케이션이 실행될 때 생성된 개인 임시 파일이 포함되어 있습니다. 이 디렉토리는 웹 서버 프로세스에서 쓸 수 있어야 합니다. CApplication::runtimePath를 통해 사용자 정의할 수 있습니다.
WebRoot/protected/extensions: 이 디렉터리에는 모든 타사 확장 프로그램이 포함되어 있습니다. CApplication::extensionPath를 통해 사용자 정의할 수 있습니다.
WebRoot/protected/modules: 이 디렉터리에는 모든 애플리케이션 모듈이 위치하며 각 모듈은 하위 디렉터리를 사용합니다.
WebRoot/protected/controllers: 이 디렉터리에는 모든 컨트롤러 클래스 파일이 포함되어 있습니다. CWebApplication::controllerPath를 통해 사용자 정의할 수 있습니다.
WebRoot/protected/views: 이 디렉토리에는 컨트롤러 보기, 레이아웃 보기 및 시스템 보기를 포함한 모든 보기 파일이 포함되어 있습니다. CWebApplication::viewPath를 통해 사용자 정의할 수 있습니다.
WebRoot/protected/views/ControllerID: 이 디렉터리는 단일 컨트롤러 클래스에 사용되는 보기 파일을 배치합니다. 여기서 ControllerID는 컨트롤러의 ID를 나타냅니다. CController::viewPath를 통해 사용자 정의할 수 있습니다.
WebRoot/protected/views/layouts: 이 디렉토리에는 모든 레이아웃 보기 파일이 포함되어 있습니다. CWebApplication::layoutPath를 통해 사용자 정의할 수 있습니다.
WebRoot/protected/views/system: 이 디렉터리에는 모든 시스템 보기 파일이 포함되어 있습니다. 시스템 보기 파일은 예외 및 오류를 표시하는 데 사용되는 템플릿입니다. CWebApplication::systemViewPath를 통해 사용자 정의할 수 있습니다.
WebRoot/assets: 이 디렉토리는 공용 리소스 파일을 저장합니다. 리소스 파일은 웹 사용자가 게시하고 액세스할 수 있는 개인 파일입니다. 이 디렉토리는 웹 서버 프로세스에서 쓸 수 있어야 합니다. CAssetManager::basePath
를 통해 사용자 정의할 수 있습니다. WebRoot/themes: 이 디렉터리는 애플리케이션에서 사용하는 다양한 테마를 배치합니다. 각 하위 디렉터리는 주제이고 주제의 이름은 디렉터리의 이름입니다. CThemeManager::basePath를 통해 사용자 정의할 수 있습니다.
6. 데이터베이스
대부분의 웹 애플리케이션은 데이터베이스에 의해 구동됩니다. 테이블과 열의 이름을 지정할 때 다음 명명 규칙을 사용하는 것이 좋습니다. Yii에는 이러한 사양이 필요하지 않습니다.
㈠데이터베이스 테이블 이름과 열 이름에는 소문자를 사용하세요.
이름의 단어는 밑줄로 구분해야 합니다(예: product_order).
㈢테이블 이름은 단수, 복수 모두 가능합니다. 그러나 두 가지를 동시에 사용하지 마십시오. 단순화를 위해 단일 이름을 사용하는 것이 좋습니다.
테이블 이름에는 tbl_과 같은 공통 접두사를 사용할 수 있습니다. 이는 응용 프로그램에서 사용하는 테이블이 다른 응용 프로그램에서 사용하는 테이블과 동일한 데이터베이스에 공존하는 경우 특히 유용합니다. 이 두 애플리케이션의 테이블은 서로 다른 테이블 접두사를 사용하여 쉽게 구별할 수 있습니다.
Ⅱ. 양식 사용
Yii에서 양식을 처리할 때 일반적으로 다음 단계가 필요합니다.
1. 수집할 데이터 필드를 나타내는 모델 클래스를 만듭니다.
2. 양식 제출에 응답하는 컨트롤러 작업을 만듭니다.
3. 뷰 스크립트에서 컨트롤러 액션과 관련된 폼을 생성합니다.
1. 모델 만들기
양식에 필요한 HTML 코드를 작성하기 전에 먼저 최종 사용자가 입력하는 데이터 유형과 데이터가 준수해야 하는 규칙을 결정해야 합니다. 모델 클래스를 사용하여 이 정보를 기록할 수 있습니다. 모델 장에서 정의한 대로 모델은 사용자 입력을 저장하고 해당 입력을 검증하는 중앙 위치입니다.
사용자가 입력한 데이터가 어떻게 사용되는지에 따라 두 가지 유형의 모델을 만들 수 있습니다. 사용자 입력을 수집하고 사용한 다음 삭제하는 경우 양식 모델을 만들어야 하며, 사용자 입력을 수집한 후 데이터베이스에 저장하는 경우 활성 레코드를 사용해야 합니다. 두 가지 유형의 모델 모두 양식에 필요한 공통 인터페이스를 정의하는 동일한 기본 클래스 CModel을 공유합니다.
1. 모델 클래스 정의
예를 들어 양식 모델을 생성합니다.
class LoginForm extends CFormModel
{
public $username;
public $password;
public $ 기억하세요= false;
}
LoginForm에는 $username, $password 및 $rememberMe라는 세 가지 속성이 정의되어 있습니다. 이는 사용자가 입력한 사용자 이름과 비밀번호를 저장하는 데 사용되며 사용자가 자신의 로그인을 기억하려는 경우에도 사용할 수 있습니다. $rememberMe의 기본값은 false이므로 로그인 양식에 처음 표시될 때 해당 옵션이 선택 취소됩니다.
우리는 이러한 멤버 변수를 일반 속성과 구별하기 위해 속성 대신 속성이라고 부릅니다. 속성은 주로 사용자 입력이나 데이터베이스의 데이터를 저장하는 데 사용되는 속성입니다.
2. 유효성 검사 규칙 선언
사용자가 입력을 제출하고 모델이 채워지면 사용하기 전에 사용자의 입력이 유효한지 확인해야 합니다. 이는 일련의 규칙에 따라 사용자 입력을 검증함으로써 달성됩니다. 규칙 구성 배열을 반환해야 하는 규칙() 메서드에 이러한 유효성 검사 규칙을 지정합니다.
클래스 LoginForm은 CFormModel을 확장합니다
{
public $username;
public $password;
public $rememberMe=false;
private $_identity;
공용 함수 규칙()
{
return array(
array('사용자 이름, 비밀번호', '필수'), //사용자 이름과 비밀번호가 필요합니다
array('rememberMe', ' boolean' ), //rememberMe는 부울 값이어야 합니다
array('password', 'authenticate'), //비밀번호는 인증되어야 합니다
);
}
공개 함수 authenticate($ 속성,$params)
{
$this->_identity=new UserIdentity($this->username,$this->password);
if(!$this ->_identity- >인증())
~ rules()에서 반환된 각 규칙은 다음 형식이어야 합니다.
array('AttributeList', 'Validator', 'on'=>'ScenarioList', ... 추가 옵션)
여기서:
AttributeList는 이 규칙으로 확인해야 하는 속성 목록의 문자열입니다. 각 속성 이름은 쉼표로 구분됩니다.
Validator(유효성 검사기)는 수행할 확인 유형을 지정합니다.
on 매개변수는 선택사항입니다. 이 규칙을 적용해야 하는 시나리오 목록을 지정합니다.
추가 옵션은 해당 유효성 검사기의 속성 값을 초기화하는 데 사용되는 이름-값 쌍의 배열입니다.
유효성 검사 규칙에 Validator를 지정하는 세 가지 방법이 있습니다.
첫째, Validator는 위 예의 authenticate와 같이 모델 클래스의 메소드 이름일 수 있습니다. 유효성 검사 방법은 다음과 같은 구조를 가져야 합니다.
공용 함수 유효성 검사기 이름($attribute, $params) { ... }
둘째, 유효성 검사기는 유효성 검사기 클래스의 이름이 될 수 있습니다. 적용되면 실제 유효성 검사를 수행하기 위해 유효성 검사기 클래스의 인스턴스가 생성됩니다. 규칙의 추가 옵션은 인스턴스의 속성 값을 초기화하는 데 사용됩니다. 유효성 검사기 클래스는 CValidator에서 상속되어야 합니다.
셋째, Validator는 미리 정의된 Validator 클래스의 별칭일 수 있습니다. 위의 예에서 필수 이름은 유효성을 검사하는 속성이 비어 있지 않은지 확인하는 데 사용되는 CRequiredValidator의 별칭입니다. 다음은 사전 정의된 유효성 검사기 별칭의 전체 목록입니다.
boolean: CBooleanValidator에 대한 별칭으로, 속성에 CBooleanValidator::trueValue 또는 CBooleanValidator::falseValue 값이 있는지 확인합니다.
captcha: CCaptchaValidator의 별칭으로, 속성 값이 CAPTCHA에 표시된 확인 코드와 동일한지 확인합니다.
비교: CCompareValidator의 별칭으로, 속성이 다른 속성이나 상수와 동일한지 확인합니다.
email: CEmailValidator의 별칭으로, 속성이 유효한 이메일 주소인지 확인합니다.
기본값: CDefaultValueValidator의 별칭, 속성의 기본값을 지정합니다.
exist: CExistValidator의 별칭으로, 지정된 테이블의 열에서 속성 값을 찾을 수 있도록 합니다.
file: CFileValidator의 별칭, 속성에 업로드된 파일의 이름이 포함되어 있는지 확인하세요.
filter: CFilterValidator의 별칭으로, 필터를 통해 이 속성을 변경합니다.
in: CRangeValidator의 별칭으로, 데이터가 미리 지정된 값 범위 내에 있는지 확인합니다.
length: CStringValidator의 별칭으로, 데이터 길이가 지정된 범위 내에 있는지 확인합니다.
일치: CRegularExpressionValidator의 별칭으로, 데이터가 정규 표현식과 일치할 수 있는지 확인합니다.
숫자: CNumberValidator의 별칭으로, 데이터가 유효한 숫자인지 확인합니다.
필수: CRequiredValidator의 별칭으로, 속성이 비어 있지 않은지 확인합니다.
유형: CTypeValidator의 별칭으로, 속성이 지정된 데이터 유형인지 확인합니다.
고유: CUniqueValidator의 별칭으로, 데이터 테이블의 열 간에 데이터가 고유한지 확인합니다.
url: CUrlValidator의 별칭으로, 데이터가 유효한 URL인지 확인합니다.
아래에는 사전 정의된 유효성 검사기만 사용하는 몇 가지 예가 나열되어 있습니다.
// 사용자 이름이 필요합니다.
array('username', 'required'),
// 사용자 이름은 3자 사이여야 합니다. 및 12자
array('username', 'length', 'min'=>3, 'max'=>12),
// in 등록 시나리오에서 비밀번호는 일치해야 합니다. 비밀번호2로.
array('password', 'compare', 'compareAttribute'=>'password2', 'on'=>'register'),
// 로그인 시나리오에서는 비밀번호를 확인해야 합니다.
array('password', 'authenticate', 'on'=>'login'),
3. 안전한 속성 할당
클래스 인스턴스가 생성된 후 일반적으로 속성은 최종 사용자가 제출한 데이터로 채워져야 합니다. 이는 다음과 같은 대규모 할당으로 쉽게 달성할 수 있습니다:
$model=new LoginForm;
if(isset($_POST['LoginForm']))
$model->attributes=$ _POST[' LoginForm'];
마지막 표현식은 $_POST['LoginForm']의 각 항목을 해당 모델 속성에 복사하는 대규모 할당이라고 합니다. 이는 다음 할당 방법과 동일합니다:
foreach($_POST['LoginForm'] as $name=>$value)
{
if($name is a safe feature)
$ model ->$name=$value;
}
탐지 기능의 보안은 매우 중요합니다. 예를 들어 안전하다고 생각하여 테이블의 기본 키를 노출하면 공격자가 수정을 얻을 수 있습니다. 기본 키를 기록하여 승인되지 않은 콘텐츠를 변조합니다.
해당 시나리오의 유효성 검사 규칙에 나타나는 기능은 안전한 것으로 간주됩니다. 예:
array('사용자 이름, 비밀번호', '필수', 'on'=>'로그인, 등록'),
array('email', 'required', 'on'=> '등록'),
위에 표시된 것처럼 로그인 시나리오에서는 사용자 이름과 비밀번호 속성이 필요합니다. 등록 시나리오에는 사용자 이름, 비밀번호 및 이메일 속성이 필요합니다. 따라서 로그인 시나리오에서 블록 할당을 수행하면 사용자 이름과 비밀번호만 블록 할당됩니다. 로그인 유효성 검사 규칙에 나타나는 유일한 규칙이기 때문입니다. 반면, 시나리오가 등록된 경우에는 세 가지 속성을 모두 블록 할당할 수 있습니다.
// 로그인 시나리오에서
$model=new User('login');
if(isset($_POST['User']))
$model->attributes=$ _POST['User'];
// 등록 시나리오에서
$model=new User('register');
if(isset($_POST['User']))
$ model->attributes=$_POST['User'];
그럼 속성이 안전한지 확인하기 위해 왜 그러한 전략을 사용합니까? 이에 대한 근거는 다음과 같습니다. 기능에 이미 유효성을 탐지할 수 있는 하나 이상의 유효성 검사 규칙이 있는 경우 무엇을 걱정해야 합니까?
유효성 검사 규칙은 코드에서 생성된 데이터(예: 타임스탬프, 자동 생성된 기본 키)가 아닌 사용자가 입력한 데이터를 확인하는 데 사용된다는 점을 기억하세요. 따라서 최종 사용자 입력을 허용하지 않는 기능에 대해서는 유효성 검사 규칙을 추가하지 마십시오.
때때로 어떤 규칙을 지정하지 않더라도 기능이 안전하다고 선언하고 싶을 때가 있습니다. 예를 들어 기사의 콘텐츠는 사용자의 모든 입력을 받아들일 수 있습니다. 특별한 안전 규칙인
array('content', 'safe')
속성을 안전하지 않다고 선언하는 안전하지 않은 규칙도 있습니다:
array('permission' , 'unsafe' )
안전하지 않은 규칙은 일반적으로 사용되지 않으며 앞서 정의한 안전 속성의 예외입니다.
4. 검증 트리거
사용자가 제출한 데이터로 모델이 채워지면 CModel::validate()를 호출하여 데이터 검증 프로세스를 트리거할 수 있습니다. 이 메서드는 확인 성공 여부를 나타내는 값을 반환합니다. CActiveRecord 모델의 경우 CActiveRecord::save() 메서드를 호출하면 유효성 검사가 자동으로 트리거될 수도 있습니다.
시나리오 속성을 설정하여 시나리오 속성을 설정할 수 있으며, 해당 시나리오의 유효성 검사 규칙이 적용됩니다.
검증은 시나리오를 기반으로 수행됩니다. 시나리오 속성은 모델이 현재 사용되는 시나리오와 현재 사용되는 유효성 검사 규칙 집합을 지정합니다. 예를 들어, 로그인 시나리오에서는 사용자 모델의 사용자 이름과 비밀번호 입력만 검증하고 등록 시나리오에서는 이메일, 주소 등과 같은 추가 입력을 검증해야 합니다. 다음 예에서는 등록 시나리오에서 유효성 검사를 수행하는 방법을 보여줍니다.
// 등록 시나리오에서 사용자 모델을 만듭니다. 다음과 동일:
// $model=new User;
// $model->scenario='register';
$model=new User('register'); //모델 클래스 제공 트리거할 검증 시나리오인 매개변수를 추가합니다
// 모델에 입력값을 입력합니다
$model->attributes=$_POST['User'];
//검증 수행
if($model->validate()) // 입력이 유효한 경우
...
else
...
규칙과 관련된 시나리오는 규칙의 on 옵션을 통해 지정할 수 있습니다. on 옵션이 설정되지 않은 경우 이 규칙은 모든 시나리오에 적용됩니다. 예:
공용 함수 규칙()
{
return array(
array('username, 비밀번호', 'required'),
array('password_repeat', 'required', ' on'=>'register'),
array('password', 'compare', 'on'=>'register'),
);
}
첫 번째 규칙 모든 시나리오에 적용되지만 두 번째는 등록 시나리오에만 적용됩니다.
5. 추출 검증 오류
검증이 완료된 후 발생할 수 있는 모든 오류는 모델 객체에 저장됩니다. CModel::getErrors() 및 CModel::getError()를 호출하여 이러한 오류 메시지를 추출할 수 있습니다. 이 두 방법의 차이점은 첫 번째 방법은 모든 모델 속성에 대한 오류 정보를 반환하는 반면, 두 번째 방법은 첫 번째 방법에 대한 오류 정보만 반환한다는 것입니다.
6. 기능 라벨
양식을 디자인할 때 일반적으로 각 양식 필드에 대한 라벨을 표시해야 합니다. 레이블은 사용자에게 이 양식 필드에 어떤 정보를 입력해야 하는지 알려줍니다. 뷰에 라벨을 하드코딩할 수도 있지만 해당 모델에 (라벨을) 지정하면 더 유연하고 편리합니다.
기본적으로 CModel은 속성 이름을 라벨로 반환합니다. attributeLabels() 메서드를 재정의하여 이를 사용자 정의할 수 있습니다. 다음 섹션에서 살펴보겠지만, 모델에 태그를 지정하면 더 강력한 양식을 더 빠르게 만들 수 있습니다.
2. 액션 생성
모델이 준비되면 이 모델을 작동하기 위한 로직 작성을 시작할 수 있습니다. 이 논리를 컨트롤러 작업에 넣습니다. 로그인 양식 예의 경우 해당 코드는 다음과 같습니다.
public function actionLogin()
{
$model=new LoginForm;
if(isset($_POST['LoginForm']))
{
// 사용자가 입력한 데이터 수집
$model->attributes=$_POST['LoginForm'];
// 사용자 입력을 확인하고 이전 페이지로 리디렉션
if($model ->validate())
$this->redirect(Yii::app()->user->returnUrl) //인증 페이지 URL로 리디렉션하기 전에 필요합니다
}
/ / 로그인 폼 표시
$this->render('login',array('model'=>$model));
}
위와 같이 먼저 LoginForm을 생성합니다. 모델 예; 요청이 POST 요청(로그인 양식이 제출되었음을 의미)인 경우 제출된 데이터 $_POST['LoginForm']을 사용하여 $model을 채웁니다. 그런 다음 이 입력을 검증하고 검증에 성공하면 사용자의 브라우저를 이전에 인증이 필요했던 페이지로 리디렉션합니다. 확인이 실패하거나 이 작업에 처음으로 액세스하면 로그인 보기가 렌더링됩니다. 이 보기의 내용은 다음 섹션에서 설명됩니다.
팁: 로그인 작업에서는 Yii::app()->user->returnUrl을 사용하여 이전에 인증이 필요했던 페이지 URL을 얻습니다. Yii::app()->user 구성 요소는 사용자 세션 정보(예: 사용자 이름, 상태)를 나타내는 CWebUser(또는 해당 하위 클래스)입니다.
로그인 작업에 나타나는 다음 PHP 문에 특별한 주의를 기울여 보겠습니다.
$model->attributes=$_POST['LoginForm'];
안전한 속성 할당에서 말했듯이 이 문은 코드 줄은 사용자가 제출한 데이터로 모델을 채웁니다. 속성 속성은 이름-값 쌍의 배열을 받아들이고 각 값을 해당 모델 속성에 할당하는 CModel에 의해 정의됩니다. 따라서 $_POST['LoginForm']이 이와 같은 배열을 제공하는 경우 위 코드는 다음과 같은 긴 단락과 동일합니다(필요한 모든 기능이 배열에 존재한다고 가정).
$model-> ;username=$ _POST['LoginForm']['사용자 이름'];
$model->password=$_POST['LoginForm']['password'];
$model->rememberMe=$ _POST['LoginForm ']['rememberMe'];
참고: $_POST['LoginForm']이 문자열 대신 배열을 전달하려면 양식 필드 이름을 지정할 때 규칙을 따라야 합니다. 구체적으로 모델 클래스 C의 기능 a에 해당하는 양식 필드의 이름을 C[a]로 지정합니다. 예를 들어, LoginForm[username]을 사용하여 사용자 이름 속성에 해당하는 양식 필드의 이름을 지정할 수 있습니다.
이제 남은 것은 필수 입력 사항이 포함된 HTML 양식을 포함하는 로그인 보기를 만드는 것입니다.
三、创建表单
编写 login 视图是很简单的，我们以一个 form 标记开始，它的 action 属性应该是前面讲述的 login 动作的URL。然后我们需要为 LoginForm 类中声明的属性插入标签和表单域。最后，我们插入一个可由用户点击提交此表单的提交按钮。所有这些都可以用纯HTML代码完成。
Yii 提供了几个助手（helper）类简化视图编写。例如，要创建一个文本输入域，我们可以调用 CHtml::textField()；要创建一个下拉列表，则调用 CHtml::dropDownList()。
例如， 如下代码将生成一个文本输入域，它可以在用户修改了其值时触发表单提交动作。
CHtml::textField($name,$value,array('submit'=>''));
下面，我们使用 CHtml 创建一个登录表单。我们假设变量 $model 是 LoginForm 的实例。
上述代码生成了一个更加动态的表单，例如， CHtml::activeLabel() 生成一个与指定模型的特性相关的标签。如果此特性有一个输入错误，此标签的CSS class 将变为 error，通过 CSS 样式改变了标签的外观。相似的， CHtml::activeTextField() 为指定模型的特性生成一个文本输入域，并会在错误发生时改变它的 CSS class。
我们还可以使用一个新的小物件 CActiveForm 以简化表单创建。这个小物件可同时提供客户端及服务器端无缝的、一致的验证。使用 CActiveForm, 上面的代码可重写为：
beginWidget('CActiveForm'); ?>
errorSummary($model); ?>
label($model,'username'); ?>
textField($model,'username') ?>
label($model,'password'); ?>
passwordField($model,'password') ?>
checkBox($model,'rememberMe'); ?>
label($model,'rememberMe'); ?>
endWidget(); ?>
4. 양식 입력 수집
때때로 일괄 모드를 통해 사용자 입력을 수집하고 싶을 때가 있습니다. 즉, 사용자는 여러 모델 인스턴스에 대한 정보를 입력하고 동시에 제출할 수 있습니다. 이러한 입력은 일반적으로 HTML 테이블로 표시되므로 이를 테이블 형식 입력이라고 부릅니다.
테이블 입력을 사용하려면 먼저 데이터를 삽입할지 업데이트할지 여부에 따라 모델 인스턴스 배열을 생성하거나 채워야 합니다. 그런 다음 $_POST 변수에서 사용자가 입력한 데이터를 추출하여 각 모델에 할당합니다. 단일 모델 입력과 약간의 차이점은 $_POST['ModelClass']를 사용하는 대신 $_POST['ModelClass'][$i]를 사용하여 입력 데이터를 추출해야 한다는 것입니다.
공용 함수 actionBatchUpdate()
{
// 각 항목이 'Item' 클래스의 인스턴스라고 가정합니다.
// 일괄 모드로 업데이트할 항목을 추출합니다.
$ 항목 =$this->getItemsToUpdate();
if(isset($_POST['Item']))
{
$valid=true;
foreach($items as $i= > ;
$valid=$valid && $item->validate(); 일부 작업
}
// 양식 입력을 수집하기 위한 뷰 표시
$this->render('batchUpdate', array('items'=>$items));
}
이 작업이 준비되면 HTML 테이블에 입력 항목을 표시하기 위해 일괄 업데이트 보기 작업을 계속해야 합니다.
| 이름< ;/th> | 가격 | ;개수 | 설명 |
|---|---|---|---|