최근에 CSS 프레임워크에 대한 소개를 많이 봤습니다. “제 제한된 시야에서는 진정으로 CSS 프레임워크라고 부를 수 있는 것을 본 적이 없습니다~”라고 말한 적이 있습니다. 내 것이 될 수도 있고, 시야가 너무 작을 수도 있고, 세상이 너무 클 수도 있습니다.
먼저 내가 동의하는 개념을 살펴보겠습니다.
프레임워크는 White-Box와 Black-Box의 두 가지 유형으로 나눌 수 있습니다.
상속 기반 프레임워크를 화이트박스 프레임워크라고 합니다. 소위 화이트 박스에는 가시성이 있으며 상속된 상위 클래스의 내부 구현 세부 사항이 하위 클래스에 알려집니다. 화이트박스 프레임워크를 활용하는 애플리케이션 개발자는 하위 클래스를 파생하거나 상위 클래스의 멤버 메서드를 재정의하여 시스템을 개발합니다. 하위 클래스의 구현은 상위 클래스의 구현에 크게 의존하며 이러한 종속성은 재사용의 유연성과 완전성을 제한합니다. 그러나 이 제한을 해결하는 방법은 추상 부모 클래스만 상속하는 것입니다. 왜냐하면 추상 클래스는 기본적으로 구체적인 구현을 제공하지 않기 때문입니다. 화이트박스 프레임워크는 프로그램 뼈대이며 사용자 파생 하위 클래스는 이 뼈대에 대한 액세서리입니다.
개체 구성요소 조립을 기반으로 하는 프레임워크는 블랙박스 프레임워크입니다. 애플리케이션 개발자는 객체를 정렬하고 조립하여 시스템 구현을 얻습니다. 사용자는 구성 요소의 외부 인터페이스만 이해하면 되며 특정 내부 구현을 이해할 필요는 없습니다. 또한 어셈블리는 상속보다 유연하며 동적으로 변경될 수 있습니다. 상속은 정적 컴파일 타임 개념일 뿐입니다.
이상적인 상황에서는 기존 구성 요소를 조립하여 필요한 기능을 얻을 수 있습니다. 실제로 사용 가능한 구성 요소는 요구 사항을 충족하지 못합니다. 따라서 기존 구성 요소를 사용하여 새 구성 요소를 조립하는 것보다 상속을 통해 새 구성 요소를 얻는 것이 더 쉽습니다. 화이트박스와 블랙박스는 동시에 시스템 개발에 사용될 예정이다. 그러나 화이트박스 프레임워크는 블랙박스 프레임워크로 발전하는 경향이 있으며, 블랙박스 프레임워크는 시스템 개발이 달성하고자 하는 이상적인 목표이기도 합니다.
오늘날 인터넷에 떠도는 수많은 CSS 프레임워크(YUI는 "YUI CSS Frameworks"가 아닌 "YUI Library CSS Tools"라고 불림)를 되돌아보겠습니다. 그 중 실제로 프레임워크라는 개념으로 작성된 것은 몇 개나 됩니까? 스타일 기본 클래스를 정의하면 됩니다. 물론, 프레임워크에 대한 모든 사람의 이해가 동일하지 않을 수도 있고, 제가 말하는 내용에 동의하지 않을 수도 있습니다.
CSS 프레임워크에 대해 다시 이야기하자면, 제가 이런 것의 존재를 인식하지 못한 것은 아닙니다. 1~2년 전부터 그런 일을 시도해 왔습니다. 대규모 웹사이트의 경우 프런트엔드 개발에는 솔루션이 필요합니다. 당연히 프레임워크가 첫 번째 선택입니다. 너무 멀어서 너무 약해서 아쉽네요 T_T.
아래 내용을 관리하는 것
클래스/컴포넌트
분명히 첫 번째 점은 CSS가 할 수 없다는 점이고, 두 번째 점은 다른 언어에 비해 매우 약하다는 점입니다.
1년 전쯤에 중간 규모의 웹사이트를 만들 때, 게을러지기 위해 콘텐츠를 모듈화하고 프로그래머들이 페이지를 구성하게 하려고 생각했습니다. 일반적인 방향은 기능 블록을 하나씩 캡슐화하는 것입니다. 프로그래머는 어떤 콘텐츠를 사용하려고 할 때에만 해당 페이지를 작성하고 싶지 않습니다. 코드를 반복할 필요가 없습니다. 안녕하세요 여러분. 정말 좋습니다.
동일한 웹사이트에서는 유사한 콘텐츠 블록이 여러 번 사용되는 것이 일반적입니다. 이로 인해 사진 목록, 사용자 아바타 목록, 그룹 아이콘 목록 등의 모듈화가 가능해집니다. 같은 말을 이렇게 써야 하나?
.photoListUesr,.photoListGroup{ /*_*/ }
그렇다고 불가능한 것은 아니지만, 갑자기 비슷한 것을 추가하고 싶다면 이때 스타일을 조정해야 할 수도 있습니다. 나는 다음과 같이 사용해 보았습니다.
<div class="photoList UesrCt" />
<div class="photoList GroupCt" />
이 경우 처음부터 공통 표현식을 분리하고 .photoList를 프로토타입으로 사용하고 추가 클래스를 통해 세부 사항을 처리합니다. 며칠 전에는 객체지향 XHTML과 CSS 프로그래밍에 대해 글을 썼습니다. 사실 나머지 절반은 상세한 예제였지만, 너무 많은 예제를 작성해야 했기 때문에 끝내지 못했습니다. ^^ 물론 이것도 몇 가지 문제가 있습니다. 즉, 초기 프로토타입의 정의는 매우 신중해야 하며, 향후에 수정되더라도 그럴 필요가 없도록 노력해야 합니다. 수정되었습니다. CSS를 사용하면 기본적으로 프레임워크는 최대 하나의 웹 사이트에만 적합할 수 있습니다. 물론 웹 사이트가 충분히 크면 이 방법을 사용하는 것이 합리적입니다.
HTML과 CSS가 모듈화될수록 파일은 더욱 단편화되고 이 문제는 더욱 심각해집니다. HTML은 응용 프로그램이 결국 하나의 복사본을 병합하고 출력하므로 처리하기 쉽지만 CSS는 일반적으로 폐기되고 직접 사용됩니다. 지금의 예에서 CSS를 웹 페이지로 가져오는 방법은 다음과 같습니다.
@가져오기 URL(/xxx/photoList.css);
@가져오기 URL(/xxx/UserCt.css);
@가져오기 URL(/xxx/GroupCt.css);
프로그램을 사용하여 페이지를 결합하는 것을 고려할 수도 있지만 사용하기 쉽고 요청 수에 비례하여 일반적으로 모든 사람이 파일을 수동으로 병합하도록 선택합니다. 인간의 두뇌는 컴퓨터보다 지능이 뛰어나지만, 많은 경우 인간 두뇌의 컴퓨팅 능력은 컴퓨터만큼 좋지 않습니다. CSS 릴리스 메커니즘을 처리하기 위해 서버 측 프로그램을 사용하는 아이디어가 있었던 적이 있습니다. 일반적인 방향은 웹 사이트 액세스 로그를 통해 전체 사이트의 다양한 페이지 사용을 분석하고 프로그램을 사용하여 어떤 대중이 사용하는지 계산하는 것입니다. 순서(CSS 파일의 순서가 우선순위에 영향을 미칩니다) 등 다양한 계산 및 압축된 출력이 필요합니다.
불행하게도 이러한 복잡한 프로그램은 하나의 방송국이나 동일한 시리즈의 방송국 그룹에만 적합할 수 있습니다. 조금 번거롭기는 하지만 포털 수준의 웹사이트에서는 이 방법을 사용해야 한다고 생각합니다. 물론 팀 전체가 동일한 디자인 패턴을 사용해야 한다는 전제가 있습니다.
추신: 위의 CSS 게시 프로그램은 아직 시도하지 않았습니다. 관심 있는 친구가 시도할 수 있습니다. 사고가 발생하면 책임을 지지 않습니다.
물론 위의 내용은 CSS 프레임워크라고 할 수 없으며 아마도 시스템 수준의 솔루션이라고만 할 수 있을 것입니다. 결국 CSS는 설명적인 언어일 뿐입니다.
어젯밤 Yueying과 오리구이를 먹다가 이 문제에 관해 이야기를 나눴고 그는 나에게 통합 프런트엔드 솔루션이 있는지 물었습니다. JS가 컴포넌트화될 때에도 동일한 문제가 발생하며 유사한 게시 메커니즘이 JS에도 적용되어야 합니다. 하지만 아직 완전히 통합된 솔루션은 생각하지 못했습니다. 아마도 Yueying이 저에게 몇 번 더 오리 구이를 해줄 것이고 제가 알아낼 수 있을 것입니다.