проект ещё не требует кастомных компонентов, значит он просто недостаточно большой
Проект у меня, действительно, небольшой, но все кастомные компоненты были написаны без каких-либо проблем, т.к. в основном требовали нестандартного поведения, а не вида.
По поводу дикой цепочки наследования и порой странного кода внутри самого фреймворка согласен. Иногда приходилось проводить неоправданно много времени под дебаггером, чтобы понять, почему метод работает не совсем так, как описано в документации или подсказывает здравый смысл.
У меня ни разу проблем с доступом к html/css не возникало. Во-первых, можно конкретной кнопке задать свой стиль, который определить вообще отдельно от темы. А во-вторых, если совсем всё плохо, можно сделать разметку в отдельном файле и загрузить её.
В общем, полагаю, у нас слишком разный опыт с ExtJs, т.ч. спорить бессмысленно.
С универсальными UI библиотеками, типа Extjs бывает сложно сделать юзабельный интерфейс.
А с неуниверсальными? «Юзабельный интерфейс» — это вообще субъективное понятие.
Все компоненты фиксированные, нельзя так просто взять и сделать большую зеленую кнопку «Выполнить операцию»
Даже во времена второй версии это спокойно реализовывалось подключением css с переопределением/добавлением необходимых стилей. С четвёртой или пятой версии имеются sass (или less) шаблоны для подстройки темы оформления под свои нужны.
Самый главный плюс ExtJS — это, как и сказал автор статьи, возможность не заморачиваться ни с чем, кроме, собственно, бизнес-логики.
По большей части бизнесу совершенно второстепенно как система будет выглядеть, главное — чтобы она выполняла возложенные на неё задачи. А свистелки и перделки прикрутить можно потом, когда функционал будет готов.
Да, в ExtJS есть проблемы и со скоростью рисования сложных интерфейсов, и баги внутри самого фреймворка встречаются. Но это, пожалуй, единственный фронт-фреймворк, который охватывает вообще всё, от описания бизнес-моделей, до их отображения в UI.
И, честно говоря, стильно/модно/молодёжные реакты с ангулярами уступают extjs именно в том, что каждый раз приходится придумывать как данные будут читаться/храниться на клиенте и отправляться на сервер, как сделать простое текстовое поле с валидацией введённого значения, как поля будут связываться с моделями данных.
Какую площадь роботы обслуживали? Какая была урожайность? Какой ландшафт полей: на картинке поле чистое прямоугольное, а если поле где-нибудь рядом с лесом, и то тут, то там, имеются околки.
Без ivy, сделать каталог в проекте, в который складывать необходимые зависимости. При компиляции засовывать этот каталог в classpath. Тэг в ant для этого есть.
Неправильная регулярка. Квадратные скобки должны быть заменены на круглые.
Проект у меня, действительно, небольшой, но все кастомные компоненты были написаны без каких-либо проблем, т.к. в основном требовали нестандартного поведения, а не вида.
По поводу дикой цепочки наследования и порой странного кода внутри самого фреймворка согласен. Иногда приходилось проводить неоправданно много времени под дебаггером, чтобы понять, почему метод работает не совсем так, как описано в документации или подсказывает здравый смысл.
В общем, полагаю, у нас слишком разный опыт с ExtJs, т.ч. спорить бессмысленно.
А с неуниверсальными? «Юзабельный интерфейс» — это вообще субъективное понятие.
Даже во времена второй версии это спокойно реализовывалось подключением css с переопределением/добавлением необходимых стилей. С четвёртой или пятой версии имеются sass (или less) шаблоны для подстройки темы оформления под свои нужны.
Зависит от нестандартности штуки, но по большей части всё можно решить, переопределив для своей кнопки шаблон, по которому генерится DOM.
По большей части бизнесу совершенно второстепенно как система будет выглядеть, главное — чтобы она выполняла возложенные на неё задачи. А свистелки и перделки прикрутить можно потом, когда функционал будет готов.
Да, в ExtJS есть проблемы и со скоростью рисования сложных интерфейсов, и баги внутри самого фреймворка встречаются. Но это, пожалуй, единственный фронт-фреймворк, который охватывает вообще всё, от описания бизнес-моделей, до их отображения в UI.
И, честно говоря, стильно/модно/молодёжные реакты с ангулярами уступают extjs именно в том, что каждый раз приходится придумывать как данные будут читаться/храниться на клиенте и отправляться на сервер, как сделать простое текстовое поле с валидацией введённого значения, как поля будут связываться с моделями данных.
Если в туалет во время посиделок к тебе может кто-то просто зайти?
есть подозрение, что эта штука поддерживает только mysql.
Eclipse на swt писан, который весь UI делегирует нативным библиотекам. А вот Netbeans/Idea — это свинговые приложения.
Без ivy, сделать каталог в проекте, в который складывать необходимые зависимости. При компиляции засовывать этот каталог в classpath. Тэг в ant для этого есть.
А потом в другом проекте, использующем другие версии артефактов, всё поломается.
Не надо ничего складывать ext-каталог, если без этого можно обойтись. А обойтись можно в 145% процентах случаев.