Magento 2는 UI 구성 요소를 도입했습니다.

그중 하나가 UI 컴포넌트 그리드입니다 (자세한 정보는 여기에서 찾을 수 있습니다 : Magento 2의 UI 컴포넌트 그리드 설명 ).

사용자 지정 모듈을 만들 때 이전 Magento 1 방법을 Grid.php고수하고 adminhtml 그리드를 처리 하는 파일을 만들었습니다 .

Grid.php메서드 대신 UI 구성 요소 표를 사용하면 어떤 이점이 있는지 궁금합니다 .

지금까지 찾은 것을 나열하겠습니다.

• 확장 성. 새 열을 추가하기 위해 새 xml을 추가 할 수 있습니다.
• 코드를 통한 구성. 논리 코드가 적고 선언적 XML이 더 많습니다.
• 네트워크를 통한 트래픽 감소 xml은 json으로 변환되어 브라우저로 전송됩니다. 또한 각 필드 유형은 브라우저로 한 번만 전송되며 양식 생성은 클라이언트에서 발생합니다.
• 새로운 시스템은 열 순서 변경 및 상태 저장을 허용합니다.

오프 주제 : 계획에 모든 그리드와 양식을 UI 구성 요소로 옮기는 것이 "내부 정보"입니다. 따라서 사용을 시작해야합니다.

@ raphael-at-digital-pianism은 adminhtml 그리드 UI 구성 요소 XML에 잘못되었다고 생각하는이 목록을 게시하도록 요청했습니다.

adminhtml 그리드 UI 구성 요소 XML에 어떤 문제가 있습니까?

• 개발 중 느린 피드백주기
• 이해하기 어렵다
• 무언가 잘못되면 디버깅하기가 어렵습니다 (주로 코어의 XML과 비교하여 만 가능)
• 많은 구현 세부 사항 노출
• 복사하여 붙여 넣기 권장
• XML은 인간이 읽고 쓰는 것이 아닙니다
• 테스트하기 어렵다
• 사용 가능한 다른 옵션이 확실하지 않습니다
• 많은 상용구와 마법 (두 세계에서 최악)
• DB 테이블 데이터 표시 아이디어와 결합
• 파일에 많은 중복 된 이름 문자열

"더 나은 솔루션으로 올라와 라"라고 말하는가?

글쎄요. 그러나 여기 개발자로서 관리 HTML 격자 및 양식을 만들 수있는 방법에 대한 대략적인 아이디어가 있습니다.

• 구현 구현 GridDataSourceInterface
• 그리드 구성 요소는 GridDataSourceInterface::getGridItemType()메소드를 사용 하여 클래스 이름 또는 인터페이스 이름을 가져옵니다.
• 인터페이스가 반영되고 가능한 모든 열을 사용하여 가능한 열을 결정합니다.
• 열 유형은 반환 유형에서 유추됩니다.
• 유효한 열 유형으로 자동 추론 할 수없는 유형은 무시됩니다.
• GridDataSourceInterface구현 인스턴스가 필요 좋은 설명 방법을 사용하여 구성 기본이 아닌 가시성 및 열 유형에 사용할 수 있습니다.

혜택:

• IDE는 메소드 자동 완성을 통해 그리드 및 폼의 정의를 지원
• 합리적인 기본값
• 구현 불가지론
• 간단한 엔티티의 경우 아주 작은 코드 만 작성하면됩니다.
• XML 접근 방식과 비교하여 기능 손실 없음
• 인터셉터를 통한 확장 성
• 클래스 인터페이스가 완료되면 그리드와 폼을 정의하는 것이 XML처럼 선언적 일 수 있습니다 (그러나 훨씬 더 간단합니다).
• 서비스 계약 클래스에 대한 Magento 2의 "사고 방식"과 일치
• 프론트 엔드 코드와의 현재 상호 작용에 대한 변경이 필요하지 않습니다 (전선을 통한 동일한 트래픽)
• 프런트 엔드 열 정렬 및 구성은 지금처럼 계속 작동 할 수 있습니다
• 무어 XML 없음

원래의 질문에 관해서는, 관리 HTML 인터페이스를 구축하기 위해 오래된 Magento 1 스타일 블록을 사용하는 것이 옳은 일이라고 생각하지 않습니다.
나는 새로운 XML 기반 그리드 선언을 가능한 한 빨리 더 나은 것으로 대체해야한다고 주장하고 있습니다.