•  09-06-2019
  •  | 
  •  

문제

저는 ASP.NET에 들어가고 있습니다(C# - 이 특정 질문에는 중요하지 않지만 전체 공개 등 모든 것이 중요하다는 것을 알고 있습니다). asp:-스타일 컨트롤을 사용하면 지루한 HTML 제작 작업이 많이 줄어들고 특정 동작으로 인해 종종 좌절감을 느낍니다.어젯밤 마스터 페이지 작업을 하다가 다음과 같은 문제를 만났습니다.나의 <asp:BulletedList ID="nav">, HTML로 변환하면 <ul id="ct100_nav">.

다른 문제도 있습니다. DataGrid를 자동으로 채울 때 결과 테이블에 반드시 원하지 않는 속성이 추가된다는 사실을 발견했습니다.

지루한 업무 중 일부를 프레임워크에 의존할 때 수락해야 하는 "구성에 대한 규칙"이 어느 정도 있다는 것을 알고 있지만, 이 경우 "규칙"은 확립된 규칙이 아닙니다. , 오히려 불필요한 추가 항목입니다.알아요 왜 ID는 접두사를 추가하지만 이와 같은 것을 조정하고 끌 수 있어야 합니다. 특히 웹 표준 전도사로서 HTML ID를 단일 페이지에 복제하지 않기 때문입니다.

따라서 여기서 질문은 저보다 더 노련한 ASP.NET 개발자를 위한 것입니다.앱 개발 및 배포 경험에서 이러한 제어를 어떻게 활용합니까?하드 코딩된 HTML을 다시 사용하고 계십니까?블렌드를 사용하시나요?나는 이러한 컨트롤의 특이한 특징을 중심으로 HTML을 디자인하고 싶지 않지만 가능하다면 이를 활용하고 싶습니다.

소년은 무엇을 해야 할까요?

도움이 되었습니까?

해결책

몸소,

저는 표준 ASP.NET 컨트롤이 사내 작업에 적합하다고 생각합니다. 이 시나리오에서는 빠르고 더러운 것이 좋습니다.그러나 디자이너이기도 한 웹 개발자와 일한 적이 있는데 그는 ASP.NET 컨트롤 사용을 거부하고 HTML 코드만 사용하고 필요할 때 runat="server" 태그를 추가했습니다.그는 자신의 HTML이 어떻게 렌더링될지 정확히 알고 싶었고 당시에는 ASP.NET 컨트롤 중 일부가 표준 준수에 맞게 렌더링되지 않았기 때문에 더욱 그렇습니다.

나는 중간 어딘가에 앉아 있습니다. 적절할 때는 HTML을 사용하고 그렇지 않을 때는 HTML을 사용하지 않습니다.당신은 두 세계의 장점을 모두 누릴 수 있습니다. CSS 제어 어댑터

다른 팁

나는 실제로 내 의견에 동의하는 몇 가지 의견을 보고 매우 안심했습니다.템플릿 언어로서의 ASP.NET은 매우 열악합니다.

저는 여기서 제시된 몇 가지 장점을 반박하고 싶습니다(플레임수트 착용!).

Dave Ward는 ID 충돌에 대해 언급했습니다. 이것은 사실이지만 처리가 얼마나 형편없었는지 모르겠습니다.나는 clientID와 같은 ASP.NET 내부를 연기하는 것을 제외하고는 ID를 효과적으로 쓸모 없게 만드는 것보다 xpath 또는 깊은 CSS 선택기에 의해 참조되는 노드를 보는 것을 선호했습니다. 이는 CSS 및 JS 작성을 무의미하게 훨씬 더 어렵게 만듭니다.

Rob Cooper는 컨트롤이 어떻게 HTML을 대체하는지에 대해 이야기하므로 모든 것이 괜찮습니다(다른 말로 바꿔서 설명하면 Rob을 용서해 주세요). 하지만 괜찮지는 않습니다. 왜냐하면 그들은 기존의 잘 이해되는 언어를 사용하여 "아니요, 우리 방식대로 해야 합니다"라고 말했기 때문입니다. 지금", 그들의 방식은 매우 제대로 구현되지 않았습니다.예를 들어asp:panel은 한 브라우저에서는 테이블을 렌더링하고 다른 브라우저에서는 div를 렌더링합니다!문서화나 실행 없이는 로그인 컨트롤(및 기타 여러 항목)에 대한 마크업을 예측할 수 없습니다.디자이너가 이에 대해 CSS를 작성하도록 어떻게 유도할 건가요?

Espo는 플랫폼이 HTML을 변경하는 경우 컨트롤이 어떻게 추상화의 이점을 제공하는지에 대해 씁니다. 음 이것은 분명히 순환적입니다(플랫폼이 변경되기 때문에 변경되는 것일 뿐이며 대신 내 자신의 HTML이 있는 경우에는 필요하지 않습니다). 실제로 문제가 발생합니다.업데이트로 인해 컨트롤이 다시 변경된다면 내 CSS는 이에 어떻게 대처해야 합니까?

사과하는 사람들은 "그렇지만 구성에서 이를 변경할 수 있습니다"라고 말하거나 컨트롤 및 사용자 지정 컨트롤 재정의에 대해 이야기합니다.그런데 내가 왜 그래야 합니까?이러한 문제 중 일부를 해결하기 위한 CSS 친화적인 컨트롤 패키지는 의미 없는 마크업을 제외하고 ID 문제를 해결하지 않습니다.

웹 양식 앱을 사용하여 MVC(3.5 구현이 아닌 추상 개념)를 즉시 구현하는 것은 불가능합니다. 이러한 컨트롤이 보기와 컨트롤을 너무 밀접하게 연결하기 때문입니다.CSS와 JS의 별도 도메인이었던 것을 구현하기 위해 서버 측 코드에 참여해야 하기 때문에 이제 전통적인 웹 디자이너에게는 진입 장벽이 있습니다.나는이 사람들에게 공감합니다.

나는 컨트롤을 사용하면 특정 프로필의 앱을 매우 빠르게 개발할 수 있다는 Kiwi의 주장에 강력히 동의합니다. 어떤 이유로든 일부 프로그래머가 HTML을 불쾌하게 여긴다는 점과 ASP.NET의 다른 부분이 제공하는 이점도 인정합니다. 이러한 제어가 필요한 5월 가격만큼 가치가 있습니다.

하지만, 나 통제력 상실에 분개하고 코드 숨김에서 클래스, 스타일 및 스크립팅과 같은 항목을 처리하는 모델이 잘못된 단계라고 생각하며 템플릿을 위한 더 나은 모델이 있다고 생각합니다(이 플랫폼에 대한 마이크로포맷 및 xslt 구현). 컨트롤을 이것으로 교체하는 것은 쉽지 않습니다.

저는 ASP.NET이 LAMP 및 레일 세계의 관련 기술로부터 많은 것을 배울 수 있다고 생각합니다. 그때까지는 가능한 한 3.5 MVC로 작업하고 싶습니다.

(너무 길어서 죄송합니다 </rant>)

짧은 대답은 ASP를 절대 사용해서는 안된다는 것입니다....특별한 이유가 없는 한 표준 HTML 컨트롤 버전을 사용하세요.

주니어 개발자는 대부분의 ASP.NET 책에서 이러한 컨트롤을 다루기 때문에 이러한 컨트롤을 사용하는 데 어려움을 겪는 경우가 많습니다. 따라서 이 컨트롤이 더 좋을 것이라고 가정합니다.그들은 아니다.8년 동안 매일 ASP.NET을 개발한 지금 이 시점에서 실제로 ASP.NET을 사용하는 것이 적합한 경우는 2~3가지밖에 생각나지 않습니다....표준 HTML에 대한 INPUT 제어.

서버 컨트롤의 ID는 다음과 같습니다.ClientID에 접속하면 브라우저에 실제로 기록될 ID를 확인할 수 있습니다.이렇게 하면 서버 측 및 클라이언트 측 스크립팅을 결합할 수 있으며 여전히 _id="ct100_nav"_를 하드코딩할 필요가 없습니다.

나는 항상 HTML을 "해킹"하는 대신 포함된 컨트롤을 사용하려고 노력합니다. 왜냐하면 나중에 업데이트나 개선 사항이 있어도 프레임워크만 교체하면 모든 코드가 계속 작동하고 HTML을 변경할 필요가 없기 때문입니다.

도움이 되었기를 바랍니다

@Brian, 네!당신은 거의 모든 행동을 통제 할 수 있습니다 ..사용자 정의 컨트롤 생성을 고려해 보십시오(세 가지 유형이 있음).나는 최근에 내 질문에 대한 개요를 제공했습니다. 여기.

나는 강하게 확인해 보시길 권합니다. 끝없이 도움이 되었습니다 :)

나 역시 ASP.NET으로 모험을 떠나고 있으며 비슷한 좌절감을 느꼈습니다.그러나 곧 익숙해집니다.기억해두시면 됩니다. 지루한 HTML 제작 작업이 필요 없는 이유는 ASP.NET 컨트롤이 모든 작업을 수행하기 때문입니다..

컨트롤을 상속하고 거기에서 HTML 출력을 조정하는 것을 의미하더라도 이러한 사항을 어느 정도 제어/조정할 수 있습니다.

과거에는 여기에 추가 마크업을 추가하여 특정 컨트롤이 기본적으로 W3C 유효성 검사를 통과하지 못하는 경우에 그렇게 해야 했기 때문에 필요에 따라 간단히 재정의하고 편집했습니다(수정 작업은 문자 그대로 몇 분 정도 소요됨).

제어 시스템이 어떻게 작동하는지 배우라고 말하고 싶습니다.그런 다음 몇 가지를 직접 결합하면 내부에서 무슨 일이 일어나고 있는지 파악하는 데 큰 도움이 되므로 문제가 발생하면 어디로 가야 할지 알 수 있습니다.

HTML은 ASP.NET의 ID 충돌 방지 방식 때문에 이러한 종류의 ID로 렌더링됩니다.마스터 페이지나 마법사 컨트롤과 같은 각 컨테이너 컨트롤은 자식 ID 앞에 "ID_"를 추가합니다.

글머리 기호 목록의 경우 ListView는 좋은 중간 지점을 제공합니다.여전히 데이터 소스에 바인딩할 수 있지만 렌더링된 HTML을 훨씬 더 엄격하게 제어할 수 있습니다.Scott Gu는 여기에서 ListView에 대한 멋진 소개를 제공합니다.

http://weblogs.asp.net/scottgu/archive/2007/08/10/the-asp-listview-control-part-1-building-a-product-listing-page-with-clean-css-ui. aspx

ASP.NET에서 추가한 ID의 접두사가 나중에 JS 등을 사용하여 액세스하는 데 문제가 되는 경우....ClientID 속성 서버 측이 있습니다.

ASP.NET으로 인해 오버헤드가 추가된 경우 내보낸 HTML을 완전히 제어할 수 있는 ASP.NET MVC(스틸 미리 보기)를 고려해야 합니다.

추가된 모든 것들이 마음에 들지 않기 때문에 MVC로 이동할 예정입니다....

나는 여기서 대부분의 답변이 디자이너의 관점을 취한다고 생각합니다.중소 규모 프로젝트에서는 코드와 CSS/HTML을 동기화하고 표준을 준수하고 깔끔하게 만드는 것이 오버헤드처럼 보일 수 있습니다.이를 수행하는 디자이너의 방법은 렌더링된 HTML을 완전히 제어하는 ​​것입니다.그러나 ASP.NET에서 이러한 모든 권한을 갖는 방법에는 여러 가지가 있습니다.그리고 나에게는 aspx/ascx 파일에 필수 HTML을 두는 것이 가장 확장성이 없고 지저분한 방법입니다.CSS를 통해 컨트롤의 스타일을 지정하려면 언제든지 CssClass 속성을 통해 서버측 클래스를 설정할 수 있습니다.JS를 통해 액세스하려면 서버 측에서 올바른 ID를 사용하여 JS를 다시 내보낼 수 있습니다.이것이 제공하는 유일한 단점은 개발자와 디자이너가 긴밀하게 협력해야 한다는 것입니다.어떤 대규모 프로젝트에서든 이는 피할 수 없는 일입니다.그러나 ASP.NET이 제공하는 이점은 이러한 어려움보다 훨씬 많습니다.그러나 렌더링된 마크업을 제어하기 위해 표준 호환 HTML, 스키닝 지원 및 기타 기능을 원하는 경우 언제든지 타사 컨트롤을 사용할 수 있습니다.

Dave Ward가 이미 언급했듯이 "이것은 ID 충돌을 방지하는 ASP.NET의 방법입니다."

이에 대한 아주 좋은 예는 사용자 정의 컨트롤 내부에 컨트롤을 넣은 다음 반복기에서 해당 사용자 정의 컨트롤을 사용하여 사용자 정의 컨트롤의 HTML이 페이지에 대해 여러 번 출력되도록 하는 것입니다.

다른 사람들이 언급했듯이 javascript 컨트롤에 액세스해야 하는 경우 ClientScriptManager에 액세스할 수 있는 ClientScript 속성을 사용하고 이 방법으로 스크립트를 페이지에 등록하세요.컨트롤의 ID를 입력하는 대신 참조하려는 컨트롤의 ClientID 속성을 사용하도록 스크립트를 작성할 때 확인하세요.

렌더링된 HTML을 그렇게 많이 제어하려면 다음을 살펴보세요. ASP.NET MVC 대신에.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top