Сообщение Re[19]: Вопрос топящим за браузерный софт. от 01.03.2023 8:55
Изменено 01.03.2023 9:10 paradok
Re[19]: Вопрос топящим за браузерный софт.
Здравствуйте, Философ, Вы писали:
Ф>Здравствуйте, paradok, Вы писали:
P>>так стандартный DOM документ-объект-модел...
P>>также есть шадоу дом....
P>>...
P>>вообще просто почитай или пролистай любую современную книжку хотя бы 2020 года по css/html
P>>...
P>>если кажется слишком низко-уровневым ...
Ф>Похоже ты суть вопроса не понял. Я спрашивал, как организуется логика изменения UI, если в ней участвует больше одного контрола. Вопрос задан в связи с тем, что ранее ты утверждал, что UI у вас делает дизайнер. Дизайнеры код обычно не умеют писать, соответственно код пишет программист. Если на стороне UI работает дизайнер, то логично полагать, что логику пишет программист на бэке. Соответственно, я полагаю, что на каждый клик пользователя стэйт отправляется на бэк. Бэк обрабатывает и отдаёт новый. Примерно так это было в WebForms. Но это моё предположение, мне интересно как на самом деле.
это уже не относится к дзайну... на каждый клик насиловать сервер или только на существенные изменения на клиенте или на сервере
(сейчас можно и события сервера без действий юзера на клиенте отображать на клиенте) это зависит от того что вам больше нравится...
конкретно, обычно (но были и другие варианты), в наших играх, например, расставлять фишки на поле можно без посылки на сервер,
и это сделано полностью дизайнером на css и немного подправлено программистом js,
и сейчас рулят не клики, а тапы и события драг-н-дроп, фишка — это объект DOM который можно переместить пальцем и дропнуть на объект DOM клетка поля,
обработчик события дропа изменит некоторые переменные — изменение переменных делал программист.
после расстановки фишек, юзер может тапнуть на кнопку играть, обработчик тапа свяжется с сервером, пошлет состояние переменных, получит результат в блоке переменных,
обработчик написанный программистом обновит данные для таблиц рекордов, очистит игровое поле, и обновит данные для холдеров фишек. Примерно так.
Различные игровые и даже весьма сложные анимации делал дизайнер на сss и немного доработал программист на js.
адаптация к разным размерам экранов сделана полностью дизайнером на css
Ф>Здравствуйте, paradok, Вы писали:
P>>так стандартный DOM документ-объект-модел...
P>>также есть шадоу дом....
P>>...
P>>вообще просто почитай или пролистай любую современную книжку хотя бы 2020 года по css/html
P>>...
P>>если кажется слишком низко-уровневым ...
Ф>Похоже ты суть вопроса не понял. Я спрашивал, как организуется логика изменения UI, если в ней участвует больше одного контрола. Вопрос задан в связи с тем, что ранее ты утверждал, что UI у вас делает дизайнер. Дизайнеры код обычно не умеют писать, соответственно код пишет программист. Если на стороне UI работает дизайнер, то логично полагать, что логику пишет программист на бэке. Соответственно, я полагаю, что на каждый клик пользователя стэйт отправляется на бэк. Бэк обрабатывает и отдаёт новый. Примерно так это было в WebForms. Но это моё предположение, мне интересно как на самом деле.
это уже не относится к дзайну... на каждый клик насиловать сервер или только на существенные изменения на клиенте или на сервере
(сейчас можно и события сервера без действий юзера на клиенте отображать на клиенте) это зависит от того что вам больше нравится...
конкретно, обычно (но были и другие варианты), в наших играх, например, расставлять фишки на поле можно без посылки на сервер,
и это сделано полностью дизайнером на css и немного подправлено программистом js,
и сейчас рулят не клики, а тапы и события драг-н-дроп, фишка — это объект DOM который можно переместить пальцем и дропнуть на объект DOM клетка поля,
обработчик события дропа изменит некоторые переменные — изменение переменных делал программист.
после расстановки фишек, юзер может тапнуть на кнопку играть, обработчик тапа свяжется с сервером, пошлет состояние переменных, получит результат в блоке переменных,
обработчик написанный программистом обновит данные для таблиц рекордов, очистит игровое поле, и обновит данные для холдеров фишек. Примерно так.
Различные игровые и даже весьма сложные анимации делал дизайнер на сss и немного доработал программист на js.
адаптация к разным размерам экранов сделана полностью дизайнером на css
Re[19]: Вопрос топящим за браузерный софт.
Здравствуйте, Философ, Вы писали:
Ф>Здравствуйте, paradok, Вы писали:
P>>так стандартный DOM документ-объект-модел...
P>>также есть шадоу дом....
P>>...
P>>вообще просто почитай или пролистай любую современную книжку хотя бы 2020 года по css/html
P>>...
P>>если кажется слишком низко-уровневым ...
Ф>Похоже ты суть вопроса не понял. Я спрашивал, как организуется логика изменения UI, если в ней участвует больше одного контрола. Вопрос задан в связи с тем, что ранее ты утверждал, что UI у вас делает дизайнер. Дизайнеры код обычно не умеют писать, соответственно код пишет программист. Если на стороне UI работает дизайнер, то логично полагать, что логику пишет программист на бэке. Соответственно, я полагаю, что на каждый клик пользователя стэйт отправляется на бэк. Бэк обрабатывает и отдаёт новый. Примерно так это было в WebForms. Но это моё предположение, мне интересно как на самом деле.
это уже не относится к дзайну... на каждый клик насиловать сервер или только на существенные изменения на клиенте или на сервере
(сейчас можно и события сервера без действий юзера на клиенте отображать на клиенте) это зависит от того что вам больше нравится...
конкретно, обычно (но были и другие варианты), в наших играх, например, расставлять фишки на поле можно без посылки на сервер,
и это сделано полностью дизайнером на css и немного подправлено программистом js,
и сейчас рулят не клики, а тапы и события драг-н-дроп, фишка — это объект DOM который можно переместить пальцем и дропнуть на объект DOM клетка поля,
обработчик события дропа изменит некоторые переменные — изменение переменных делал программист.
после расстановки фишек, юзер может тапнуть на кнопку играть, обработчик тапа свяжется с сервером, пошлет состояние переменных, получит результат в блоке переменных,
обработчик написанный программистом обновит данные для таблиц рекордов, очистит игровое поле, и обновит данные для холдеров фишек. Примерно так.
Различные игровые и даже весьма сложные анимации делал дизайнер на сss и немного доработал программист на js.
адаптация к разным размерам экранов сделана полностью дизайнером на css
---
так как ты знаком с дельфи то такой подход доолжен быть для тебя пнятен по идее. Та дизайнер мжет на дельфи в конструкторе форм сделать дзайн макеты
всех экранов, причем для всех разрешений и размеров экрана — дельфи сейчас это можно. Программист напишет обработчики событий кликов на кнопки и логику взаимодействия с севером.
Ф>Здравствуйте, paradok, Вы писали:
P>>так стандартный DOM документ-объект-модел...
P>>также есть шадоу дом....
P>>...
P>>вообще просто почитай или пролистай любую современную книжку хотя бы 2020 года по css/html
P>>...
P>>если кажется слишком низко-уровневым ...
Ф>Похоже ты суть вопроса не понял. Я спрашивал, как организуется логика изменения UI, если в ней участвует больше одного контрола. Вопрос задан в связи с тем, что ранее ты утверждал, что UI у вас делает дизайнер. Дизайнеры код обычно не умеют писать, соответственно код пишет программист. Если на стороне UI работает дизайнер, то логично полагать, что логику пишет программист на бэке. Соответственно, я полагаю, что на каждый клик пользователя стэйт отправляется на бэк. Бэк обрабатывает и отдаёт новый. Примерно так это было в WebForms. Но это моё предположение, мне интересно как на самом деле.
это уже не относится к дзайну... на каждый клик насиловать сервер или только на существенные изменения на клиенте или на сервере
(сейчас можно и события сервера без действий юзера на клиенте отображать на клиенте) это зависит от того что вам больше нравится...
конкретно, обычно (но были и другие варианты), в наших играх, например, расставлять фишки на поле можно без посылки на сервер,
и это сделано полностью дизайнером на css и немного подправлено программистом js,
и сейчас рулят не клики, а тапы и события драг-н-дроп, фишка — это объект DOM который можно переместить пальцем и дропнуть на объект DOM клетка поля,
обработчик события дропа изменит некоторые переменные — изменение переменных делал программист.
после расстановки фишек, юзер может тапнуть на кнопку играть, обработчик тапа свяжется с сервером, пошлет состояние переменных, получит результат в блоке переменных,
обработчик написанный программистом обновит данные для таблиц рекордов, очистит игровое поле, и обновит данные для холдеров фишек. Примерно так.
Различные игровые и даже весьма сложные анимации делал дизайнер на сss и немного доработал программист на js.
адаптация к разным размерам экранов сделана полностью дизайнером на css
---
так как ты знаком с дельфи то такой подход доолжен быть для тебя пнятен по идее. Та дизайнер мжет на дельфи в конструкторе форм сделать дзайн макеты
всех экранов, причем для всех разрешений и размеров экрана — дельфи сейчас это можно. Программист напишет обработчики событий кликов на кнопки и логику взаимодействия с севером.