검색 엔진의 로봇이 검색할 때 유형에 대해서는 text/html과 같은 "텍스트"의 친숙성이 가장 높지만(현 단계에서는 text/xml 제외) text/javascript의 친숙성은 이상적이지 않습니다. 그래도 DHTML 코드를 판단하려면 복잡성도 높아서 그럴 가치가 없습니다. 따라서 DHTML을 프로그래밍할 때 코드의 친숙성을 높이고 싶다면. 더 나은 방법은 "DHTML 코드를 HTML이 없는 코드로 최대한 단순화"하는 것입니다. 이 문장을 어떻게 이해해야 할까요?
예:
자바스크립트 메뉴.
방법 1. 기존 프로그래밍 방법 사용:
2. 검색 엔진에 보다 친숙한 프로그래밍 방법 사용
방법 1과 방법 2를 비교하면 이 방법은 일부 HTML을 neverDHTMLmenu()로 캡슐화하지만 이렇게 해도 실질적인 이점은 없습니다. CSS를 이 클래스에 넣으세요.
방법 2에는 많은 이점이 있다고 볼 수 있습니다. 예를 들어 뷰를 프로그램에서 분리할 수 있고 클라이언트 측 MVC를 구현할 수 있습니다. 다르게 말하면 개발 효율성을 향상시킬 수 있습니다.
어떤 친구들은 메뉴 외에 위의 방법으로 어떤 프로그램을 분리할 수 있는지 물어볼 수도 있습니다.
위에서 언급했듯이 이 방법은 일반적으로 페이지와 더 많이 상호 작용하고 많은 HTML을 생성하며 검색 엔진의 로봇에 영향을 미치는 사람들에게 사용될 수 있습니다. 물론 이는 검색의 친숙성에 대한 논의일 뿐입니다. Engine.이므로 모든 코드는 실제 상황에 따라 결정되어야 합니다.
왜 이것이 개발 효율성을 향상시키는가?라고 묻는 친구들도 있을 것입니다.
예를 들어, 아티스트가 템플릿을 만든 후(아티스트가 관련 HTML 작성 방법을 알고 있다고 가정) xhtml 표준에 따라(위의 예에 표시됨)
변경하고 싶다고 가정해 보겠습니다. 원래 홈을 기본 페이지로 이동한 다음 아티스트는 프로그래머와 통신하여 이 메뉴의 문구를 변경해야 한다고 말해야 하며, 이로 인해 개발 중에 통신 시간이 더 많이 소요됩니다. 따라서 이 시간도 개발 진행에 포함되어야 합니다. 템플릿을 변경하려면 여전히 의사소통이 필요합니다. 또는 js를 사용하여 생성된 원본 HTML이 테이블로 만들어진 메뉴이고 수정이 필요한 경우 프로그램을 다시 작성해야 합니다. 유지 관리에 도움이 되지 않습니다...
이 방법을 사용하는 것이 좋습니다. 주요 의미는 JS가 비즈니스 구현을 담당하고 뷰는 여전히 HTML로 처리된다는 것입니다.