hVosttdbpatchу меня нет задачи "дизайна". у меня кодогенератор форм от базы данных, что-то вроде Oracle Apex, для сугубо внутренних задач, там невиданные лебедевые красоты не нужны.

и что это меняет для пользователей?

Это меняет для разработчиков. Тут нет задачи ваять сайт именно как сайты для public сектора.
Скорее задача сделать что-то вроде 1С (Oracle Forms, Oracle APEX) с веб браузром для UI.

Разработчик описывает UI без огрядки на дизайн, важна лишь функциональность.

Т.е. есть формочка для ввода единицы оборудования - вот набор полей, их типы (просто текст, LOV, дата), сколько примерно символов должно вмещать, порядок (первое-второе-третье), а как их покажет браузер - уже не важно, т.е. разработчик об этом думать не должен.


hVosttdbpatchсчитать фиксированно ширину меток - да, это похоже и придется делать.
можно сделать её адаптивной, как это сделано в bootstrap. также ограниченно адаптивно резиновыми они тоже быть могут.
ну, мне проще - адаптивная разметка на самом деле не нужна, мониторы у всех пользователей типовые - 1920x1080(1200),
для планшетов UI в основном не нужен, кроме пары-тройки спецтализированных форм (вроде инветаризации).


hVosttdbpatchв конце концов это уже приходится делать, чтоб сделать fixed-header, fixed-footer таблицы, там тоже - иначе никак, кроме как на server-side считать em-ки с запасом 20% чтоб не "налезало", но признаться я не думал, что и в области форм все настолько печально в этом вашем html.вот здесь, признаться, ничего не понял

Типовая таблица в корпоративной формочке - заголовок колонок, строки (скроллируются) и подвал, там слово Итого и суммы.
заголовок и подвал не должны улетать с экрана если число строк больше, чем высота экрана, и не должны скроллироваться.

Т.е. нужно получить что-то вроде этого:




В вебе по дефолту скроллируется всё, это крайне неудобно - потому что видишь ты пятнадцать колонок цифр - абсолютно не видно,
какая к чему относится - заголовок уплыл за область видимости.

Как решение - делаем три html таблицы, для header, rows, footer. rows живет в своем контейнере с overflow-y: auto, header и footer заданы через position:relative, и все это вместе - в своем контейнере с overflow-x: auto

Так как колонки в трех таблицах теперь не связаны, то автоматический расчет ширин не работает, все что мы можем - это задать их размер заранее, чтоб все три таблицы были одинаковой ширины и горизонтальное скроллирование их контейнера работало по всем трем одинаково.

skyANAdbpatchу меня нет задачи "дизайна". у меня кодогенератор форм от базы данных, что-то вроде Oracle Apex, для сугубо внутренних задач, там невиданные лебедевые красоты не нужны
То вариант взять готовую либу, чтобы не тратить время и деньги на разработку своей, имеет право на жизнь.

Вот если бы стояла задача спроектировать (задизайнить) свой набор компонентов с определённым поведением, то да...

Веб это не Delphi, где написал раз, а потом просто перекомпилируешь и все работает как и раньше.
Уже был печальный опыт, когда новый браузер разрушает цивилизацию, а обновление всех внешних зависимостей вызывает системный кризис (и мы вынуждены жить на IE7 вечно).

Но даже это не суть проблемы.

Проблема в том, что разработчик вместо решения задач (работа в терминах предметной области) вынужден изучать всякую ерунду под названием миксины, плагины, бутстрапы, и прочее, просто чтоб сделать форму для банального заполнения таблицы в базе данных.

Есть желание избавить его от этого веселого занятия, оставив в доступности очень ограниченную семантическую модель (API) для UI.

hVosttdbpatchПроблема в том, что разработчик вместо решения задач (работа в терминах предметной области) вынужден изучать всякую ерунду под названием миксины, плагины, бутстрапы, и прочее, просто чтоб сделать форму для банального заполнения таблицы в базе данных.

Ой да ладно. Пусти веб разработчика в десктор, он проблюётся раз сто, и скажет, что такой жести он ещё никогда не видал, а на вебе вот это и это делается долбаным стилем за 10 сек.

Просто проблемы перехода ))
Это пройдёт.

Еще раз - нет задачи именно веб разработки. Есть задача сделать минимально достаточный UI для ввода данных в БД (на самом деле там не только и не сколько БД, но это не суть).

Я же говорил - тру лебедевиные дизайны не нужны.

А так да, десктоп UI сейчас стагнирует, кроссплатформы там не было и не намечается в обозримой перспективе, потому и взяли веб на вооружение - там вся кроссплатформа "бесплатна". Ну, есть свои конечно приколы с несовместимостями браузерами, но они локализируются очень малой кровью, в сравнении с.

Petro123 непонятно..
Вы делаете копию апекс?
Да, по мотивам. APEX на текущей стадии это, ИМХО, тупик.
Потому что version control там не решен и решен похоже не может - достаточно глянуть, ЧТО он экспортирует в текстовый дамп, чтоб отбросить идею о code review как класс. Впрочем, этим страдают все IDE с кодогенератором, без исключения.

Хотя в целом идея APEX, как средство избавить разработчика от HTML/CSS/JS знаний - очень оок.

Petro123 И почему скрин десктоп для веб?

Это просто пример того, что нужно получить - понятие фиксированный заголовк и фиксированный подвал в таблице.
Делать скриншоты из веба.... на наверное extjs такое может, мне лень было искать: http://examples.sencha.com/extjs/6.2.0/examples/kitchensink/#paging-grid

Petro123dbpatchЕсть задачалибо Apex бесплатно. Либо проф. Верстальщик в штат. Это же очевидно.

оба варианта отпадают по причине связанных затрат на сопровождение и бесперспективность в среднесрочной перспективе.

hVostt что знаю о чём говорю?
Ок, скажи адрес, тебе пришлют медаль "15 лет веб победы"


hVosttdbpatchРазработчик описывает UI без огрядки на дизайн, важна лишь функциональность.

Т.е. есть формочка для ввода единицы оборудования - вот набор полей, их типы (просто текст, LOV, дата), сколько примерно символов должно вмещать, порядок (первое-второе-третье), а как их покажет браузер - уже не важно, т.е. разработчик об этом думать не должен.

Всё верно! Разработчик, программирующий ДОМЕН, не должен думать о формочка. Но разработчик, делающий генератор форм должен подумать раз эдак в пять по-больше разработчика, который верстает уникальную форму по образцу, так как как надо учитывать охрененное количество вариантов и ньюансов.
Не пойму, о чем ты вообще говоришь. Чтоб разработчику сделать типовую форму Заказ (наименование, количество, цена, сумма итого), ИМХО, особо думать не надоть.
Описал декларативно форму Документ как набор Полей, описал подчиненную таблицу Строки, аналогично....
Т.е. только свойства задать.... Все.

Если, конечно, ты не веб разработчик :)

Попрограммировать там можно только валидации какие.

hVosttАга, теперь понял. На HTML/CSS делается элементарно.
Да неужели? Пример покажешь?


hVosttdbpatchВ вебе по дефолту скроллируется всё

Ничё не всё. Фиксируешь свой <div>, задаешь его размеры по высоте, добавляешь в стилях скролл и получаешь результат. В HTML это делается разы проще, чем в десктоп.
Я сказал - по дефолту. А в десктопе скроллирование даже описывать не надо, оно где надо уже даром поставляется в компонентах гридов, о чем ты?


hVosttdbpatchКак решение - делаем три html таблицы, для header, rows, footer. rows живет в своем контейнере с overflow-y: auto, header и footer заданы через position:relative, и все это вместе - в своем контейнере с overflow-x: auto
Ну так себе решение. Может потом таки уйдёшь от таблиц, когда сам допетришь почему это bad ))
Ок, покажешь, как сделать типовой grid с fixed-header, fixed-footer на DIV-ах?


hVosttdbpatchТак как колонки в трех таблицах теперь не связаны, то автоматический расчет ширин не работает, все что мы можем - это задать их размер заранее, чтоб все три таблицы были одинаковой ширины и горизонтальное скроллирование их контейнера работало по всем трем одинаково.

Работать будет. Но таблицы это в первую очередь не адаптивно. Да-да, я знаю, в корпоративном секторе легко можно залупиться и тыкнуть в морду требованиями. Но, жизнь сложнее чуток.
В смысле не адаптивно? Тебе никто не мешает точно таким-же образом, через @media задавать предопределенно ширины колонок для каждого разрешения. Для FullHD однострочные таблицы, для каких планшетов - с вариантом текст в ячейке две строки, чтоб все в экран влезло по ширине, хотя за такое нужно, наверное, руки в двери.

В общем неадаптивность табличного отображения данных - тема не раскрыта, куда там что адаптировать?

Petro123dbpatchпропущено...


оба варианта отпадают по причине связанных затрат на сопровождение и бесперспективность в среднесрочной перспективе.
Ок. Свитчуйтесь сами в верстальщика.
Апекс очень достойный продукт. У меня был проект. Работает годами у заказчика федерала.

Я не спорю, что очень достойный. Но как я говорил выше - в нем все очень ООК, кроме source code version control.

Если заказчик один и существует только две версии - в проде и в разработке, и для деплоя разрешается лишь покликать мышкой, то APEX - ваше все

Petro123dbpatchЕсли заказчик один и существует только две версии
Нет логики. У вас куча вариантов, но нет денег на программиста.
Впрочем, оффтоп. Удачи!

почему нет? есть. просто нет задачи делать бег на месте, т.е. инвестировать в то, что через три года станет безнадежно deprecated

Petro123dbpatchбезнадежно deprecatedя о верстальщике для генератора.

а смысл? ну "наверстает" он за пару недель мегабайты "своего кода и зависимостей" для пары типовых форм, так, как он привык это делать всегда, красота, во всех браузерах все резинится и плавает, глаз не нарадуется.

а потом открываешь папку, и видишь там сразу 100500 css/js/ts/less/sass, которые он вкопипастил с предыдущего проекта, и что я буду с этим делать?

hVosttdbpatchВ смысле не адаптивно? Тебе никто не мешает точно таким-же образом, через @media задавать предопределенно ширины колонок для каждого разрешения. Для FullHD однострочные таблицы, для каких планшетов - с вариантом текст в ячейке две строки, чтоб все в экран влезло по ширине, хотя за такое нужно, наверное, руки в двери.

В общем неадаптивность табличного отображения данных - тема не раскрыта, куда там что адаптировать?

Ты похоже не понимаешь, что адаптивность, это не ширины колонок для каждого разрешения.

я тебя просил показать пример grid-а на HTML, с фиксированным заголовком и подвалом, а ты что показал?
в этом примере прекрасно всё, начиная с того, что фиксируешь высоту. что в век адаптивных разрешений выглядит дико странно.





давай лучше про фиксторованные заголовки. начать можно вот отсюда:
http://www.sql.ru/forum/1162633/tablica-fiksirovannyy-zagolovok-stolbec?mid=17822310#17822310


и никаких фейлов ни у кого нет. я вроде четко выразился, что есть задача отделить прикладную разработку от веб разработки.
все что касается веба - должно быть изолировано в собственной библиотеке-фреймворке, которую да, естественно, нужно один раз разработать, но это отдельная задача, прикладник к ней не имеет отношения.