Sencha Architect와의 예상되는 공동 작업 흐름은 무엇입니까?

Question

내가 센차 아키텍트의 재판을 시작하고, 더 많은 질문은 개발 환경에서 실제 타당성 사용에 대한 내 마음에 와서 그것을 더 내가 사용하는, 내가 가지고있는 큰 질문 중 하나는 환경에서

입니다 당신이 할 수있는 'T는 다른 편집기에서 개별 파일을 편집하는 방법을 여러 사람은 있지만, 예를 들어, 자식을 사용할 수있는 각 파일을 배포하기 위해 정기적 환경에서 예를

app/models|components|views/Model1.js <- In charge of developer one 
app/models|components|views/Model2.js <- In charge of developer two. 

를 들어, 사이트의 다른 부분을 개발에 협력 할 수 건축가라면 파일을 수동으로 편집 할 필요가 없습니다. 프로파일과 같은 기능이 건축가에게 노출되지 않기 때문에 짜증이납니다. 수동으로 편집하는 경우 문제가 발생하거나 프로젝트 파일에있는 모든 데이터로 코드를 덮어 쓸 수 있으므로 Sencha와의 적절한 또는 예상되는 공동 작업 흐름이 궁금합니다.

Answer 1

이 주제를 검색했을 때 프로젝트의 중요한 부분 인 metadata/ 디렉토리이며 모든 구성 요소가 자체 메타 데이터 파일로 분리되어 있음을 발견했습니다. 이것은 루트 레벨 프로젝트 파일과 함께 버전 제어에 중요한 부분 일 것입니다. app/은 저장시 다시 생성되며 버전 제어에서 제외 될 수 있습니다.

기본 xds 프로젝트 파일 컨테이너는보다 일반적인 참조이며 메타 데이터 구성 요소보다 자주 변경되지 않습니다. 새로운 구성 요소가 생성되거나 프로젝트/앱 수준 설정이 수정되면 변경됩니다.

루트 파일과 메타 데이터 폴더를 체크 인하는 것이 이상적입니다.

Answer 2

유용하고 완전한 기능을 갖춘 개발 환경을 만들기위한 Sencha의 노력에 감사드립니다. Sencha Architect는 비교적 큰 프로젝트와 개발자 팀을 위해 준비가되어 있지 않습니다.

원본 설계자 소프트웨어는 빠른 프로토 타이핑과 복잡한 UI 구조 설계에 매우 유용하지만, UI 요소가 JS 파일에 저장되는 방식을 파악한 후에는 기존 JS를 복사하여 붙여 넣기가 더 쉽고 빠릅니다 암호.

나는 이것이 당신이 찾고 있던 대답이라고 생각하지 않습니다. 나는 단지 내 생각을 나누고 싶었습니다.

Answer 3

저는 Sencha의 Aaron에게 개인 메시지로 같은 질문을했습니다. 그는 앱과 메타 데이터를 포함하여 전체 프로젝트 구조를 점검 할 것을 제안했습니다. 우리 팀에서 하나의 흐름을 보였습니다.

Answer 4

소스/버전 제어 기능을 갖춘 팀에서 작업하는 것은 Sencha Architect에서 매우 쉽습니다. Architect 프로젝트는 모두 프로젝트 디렉토리에 있습니다. 이 n 개의 부품

1. 프로젝트 파일로 구성 인사이드 - 열고 프로젝트를 유지하기 위해 건축가에 의해 사용되는 적은 양의 데이터로 구성되어 있습니다. 더블 클릭하여 열 수있는 단일 파일입니다.

2. 메타 데이터 디렉토리 - 프로젝트의 모든 부분을 설명하는 파일로 구성됩니다. 각 클래스 (컨트롤러, 뷰, 모델, 저장소, 리소스)에는 자체 파일에 저장된 정보가 있습니다.

3. app 디렉토리 - 만든 프로젝트의 src로 구성됩니다. 각 클래스의 자바 스크립트 파일.

4. 다른 루트 파일 - 응용 프로그램의 런치 패드 인 app.html과 app.js와 응용 프로그램을 미리 볼 때 실행되는 내용. 이것은 또한 귀하의 packager.json, app.json이 갈 곳입니다.

   는

이 모든 것을 설명 내 포인트는 건축가에 의해 생성 된 파일은 당신이 손으로 당신의 마음에 드는 편집기에서 만든 것입니다 무슨에 거의 동일 함을 보여주는 것입니다. 유일한 추가 정보는 메타 데이터 및 프로젝트 파일입니다. 메타 데이터는 모두 JSON입니다.

지금 신청하십시오! 계속해서 Architect를 편집자로 사용하고 20 명의 엔지니어가 Git 또는 SVN을 사용하여 완벽하게 안전하다고 요청합니다. 개발자가 변경하면 메타 데이터와 해당 파일의 앱이 모두 변경됩니다.

Answer 5

위의 글을 읽으면서, 나는 아직도 코드 저장소에 엽차 메타 데이터 파일을 유지하고 메타 데이터에서 모든 자바 스크립트를 생성하는 큰 프로젝트에 적합한 지 믿을 수 없다.

Sencha Architect의 아이디어는 코드를 자바 스크립트 파일이 아닌 JSON 메타 데이터로 유지하는 것입니다. 자바 스크립트 코드를 편집해야 할 때마다 IDE를 사용하고 메타 데이터를 편집해야합니다. Phil Strong은 "계속해서 Architect를 편집자로 사용하고 20 명의 엔지니어가 Git 또는 SVN을 사용하여 완벽하게 안전하다고 요청합니다." 물론이 워크 플로우는 Sencha에게 매우 유리합니다. 개발자가 Sencha Architect를 사용해야하는 한 줄의 JavaScript 코드를 변경하기 위해 Sencha Architect를 사용하려면 20 명의 사람들에게 라이센스가 부여 된 Sencha Architect를 사용해야합니다.

두 사람이 같은 파일을 편집하면 IDE에서 메타 데이터를 업데이트합니다. 그런 다음 파일을 코드 저장소에 체크인하고 그 중 하나가 충돌을 해결해야하므로 개발자는 JavaScript 파일이 아닌 두 개의 메타 데이터 파일을 병합해야합니다.

Sencha Architect를 사용하지 않는 한 개발자가 JavaScript를 편집하지 못하도록하는 전체적인 아이디어는 같은 사람이 Java 및 JavaScript 개발 또는 Python과 JavaScript 모두에서 자신이 좋아하는 IDE를 사용할 수 있기 때문에 비생산적입니다. 동일한 IDE에서 클라이언트와 서버 프로그래밍을 모두 수행하는 것은 두 IDE 간의 전환보다 빠릅니다. 큰 프로젝트의 현실은 다른 IDE를 사용하는 전 세계의 여러 팀이 있으며, 자신이 가장 좋아하는 IDE가있는 계약자가 구현 한 단기 프로젝트가있을 수도 있다는 것입니다.

ExtJS는 잘 설계된 프레임 워크이므로 한 줄의 JavaScript 코드를 수정하기 위해 SenchaArchitect가 필요하지 않습니다.

JavaScript로 코딩 할 때 JavaScript 파일을 저장하고 브라우저를 새로 고침하고 변경 사항을 즉시 확인하십시오. Sencha Archtect 추가 및 추가 단계, 그것은 당신이 자바 스크립트 (메타 데이터에서 자바 스크립트를 생성) 게시해야하며, 프로젝트가 클수록 지연이 더 길어집니다. 프로덕션 환경에서 JavaScript 파일을 수정해야하는 경우가 종종 있습니다. 한 줄을 변경하면 문제가 해결되는 경우가 있습니다. Sencha Architect를 사용하여 메타 데이터에서이 단일 행을 다시 생성해야합니다.

빠른 프로토 타입 작성을 위해 Sencha Architect를 사용한 다음 생성 된 파일을 코드 저장소에 체크인하고 수동으로 JavaScript를 계속 편집합니다. 이 접근 방식을 통해 버전 관리 시스템을 사용하여 JavaScript의 기록을 볼 수 있습니다. 내가 JSON 메타 데이터를 VCS로 체크인했다면 자바 스크립트의 히스토리를 가지지 않을 것입니다. JSON 메타 데이터의 역사가 어긋납니다.

GUI 형식의 메타 데이터는 괜찮 으면 좋겠지 만 메타 데이터에서 MVC 컨트롤러 수준도 생성해야한다는 제한은 없습니다.