현재 우리는 응용 프로그램을위한 새로운 구성 프론트 엔드를 설계하고 있습니다. 브라우저에서 응용 프로그램을 XBAP로 실행하려면 모달 대화 상자를 사용하고 싶지 않습니다. 내가 원반 던지기 사용자 인터페이스 디자인 자체를 원하지 않지만 우리의 접근 방식이 기술적 측면에서 좋은지 몇 가지 기술적 인 질문을하고 싶습니다. 대부분의 사용법은 WPF에 대해 자세히 설명되어 있지 않지만 MVVM 패턴에 익숙하며 주요 목표 중 하나는 GUI에서 대부분의 코드를 분리하고 UI 정의에 주로 xmal을 사용하는 것입니다.WPF 응용 프로그램 레이아웃
이제 스케치를 완성합니다.
은 "Mainmenue"트 리뷰와 같은 일부 Outlook을해야하는 것은 사용자가 "MENUE 따라 상황"
을 편집하고자하는 구성 섹션을 선택합니다 :해야 "Mainmenue"에서 선택한 항목에 따라 MENUE 예 리본 바. "새 항목 추가"또는 "항목 제거"와 같은 기능을 제공하지만 "구성 파일로드"와 같은 응용 프로그램 기능이 모두 있습니다.
"컨텍스트"는 "Mainmenue"에서 선택된 항목 뒤에있는 데이터 여야합니다. 선택한 카테고리의 구성 항목 그리드
실제 개념은 한 페이지가 두 개의 프레임으로 분리되어 있고 왼쪽에 하나의 "Mainmenue"페이지가로드되고 오른쪽에 두 번째 페이지가로드되어 있습니다. 사용자가 메뉴에서 무언가를 선택하면 올바른 것이 교환됩니다. 그러나 xaml의 사용자 정의를 상속받을 수 없기 때문에 새로운 컨텍스트 뷰를 만드는 것이 고통이 아닙니다. 여기서 설명한 2 해결 방법을 시도했지만 그다지 좋지 않습니다. 그리고 우리는 C#으로 UI를 정의하고 싶지 않습니다. 이것은 문제의 또 다른 해결 방법입니다.
이제 레이아웃을 리팩터링하기 위해 새로운 스케치를 만들었습니다. 이제 우리는 메인 페이지를 세 개의 프레임으로 나누고 싶습니다. 하나는 "메인맨", "컨텍스트"는 하나는 "컨텍스트에 따라 달라집니다"입니다. 실제로 모든 컨텍스트 뷰에는 고유 한 ViewModel이 있습니다. 각 뷰 모델에는 "menue entries"와 같은 속성이 있고 컨텍스트에 대한 menue를 표시해야하는 "contextual menue"에 바인딩되어 있다고 생각했습니다. 또한 넓은 범위의 응용 프로그램을 한 번만 프로그래밍하면됩니다.
이제이 접근법의 단점이 있습니까? Databinding을 사용하면 약간의 문제가 발생할 수 있습니다.
