The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Web-фреймворк Pusa, переносящий логику JavaScript-фронтэнда на сторону сервера, opennews (?), 12-Ноя-21, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


219. "Web-фреймворк Pusa, переносящий логику JavaScript-фронтэнда ..."  +1 +/
Сообщение от Анонимemail (219), 13-Ноя-21, 18:10 
видимо, кто то из пыхошколоты набрел пару лет назад на http://hrud.net
но не понял сути, и решил сделать все на пхп и для масс-веба ))
Ответить | Правка | Наверх | Cообщить модератору

220. "Web-фреймворк Pusa, переносящий логику JavaScript-фронтэнда ..."  +/
Сообщение от Анонимemail (219), 13-Ноя-21, 18:15 
да простят меня авторы "пуса" но это было первое впечатление.
приношу извинения, если кого обидел.

Ответить | Правка | Наверх | Cообщить модератору

239. "Web-фреймворк Pusa, переносящий логику JavaScript-фронтэнда ..."  +/
Сообщение от stillswamp (ok), 14-Ноя-21, 12:59 
Не обидели. IT не для обидчивых.

Сфера применения HRUD:

Где нужно применять HRUD ? Разработка АРМ, личных кабинетов, и др. приложений с web-интерфейсом, для которых необходима поддержка сложной логики поведения или взаимодействия с клиентом, поддержка «сложного состояния клиента».
Это «statefull технология», которая выгодна при организации сложных бизнес-процессов, быстрой разработки промышленных АРМ.

Сфера применения Pusa значительно шире и все перечисленное так же.

Ответить | Правка | Наверх | Cообщить модератору

252. "Web-фреймворк Pusa, переносящий логику JavaScript-фронтэнда ..."  +/
Сообщение от dplsoftemail (ok), 15-Ноя-21, 00:30 
ваш оптимизм конечно похвален, но я бы сказал что вы заявляете пока еще трудноподъемные для вашей технологии вещи.

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

допускаю, что я сейчас попросту не понимаю как вы организуете серверные скрипты, плохо понимаю, что в ваших терминах является контроллером (уж не MVC ли? но тогда где модель?...).. но если я этого не понимаю - тогда у меня вопрос: а где доки которые дают мне как архитеткору или разработчику "модель вашего приложения" ? тех 2-х рисунков что есть в текщих манах - не достаточно. примеры - можете их сделать? в описанных на рисунках терминах разложить несколько примеров простого взаимодйствия - простой, средний (см ниже лифлет) , сложный ...
В общем делайте мануалы и демки? но это спойлер - см про это в конце.

Теперь про проблемы которые я вижу:

_________________
во первых. ты часть проблем, что вытекает из простоты протокола.

Сейчас это, имхо, как proof-of-cоncept. Протокол не предполагает передачу проивольных данных между клиентом и сервером, генерацию событий программно, у клиента нет js-api, нет механизмов взаимодействия сервера с находящимся на клиенте js (например как вы хотите добалять на leaflet-карту новые объекты?). вы похоже не очень то предрасположены к тесной интеграции с js ? да есть метод вызова произвольного js - но там же стоит пометка "Рекомендуется минимизировать использование"?

Вопрос: как вы, например, собираетесь обрабатывать сдвига карты в leaflet - что бы запростиь у сервера объекты для новой области отображения? ведь у вас нет ни js-api в клиенте, ни механизма генерации событий программно, ни передачи дополниетльных, динамически генерируемых данных с событиями отсылаемыми на сервер.

Будете делать это _не_ через PUSA? тогда прогнозирую нежелание разработчиков пользовать клиент pusa на стороне клиента. Примерно так же как мы не хотели видеть JSF потому что с "его клиентом" было очень проблемно интегрироваться - вызвать метод какого-то бина на сервере, когда ты находишься в js-коде - это сплошные костыли.


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

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

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

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

И пока вы сидите на php - вы не сможете организовать без костылей хранение состояния клиента на севере в памяти (хотя возможно мои знания про php устарели и вы знаете как это сделать изящно... но я вот думаю что нет таких вариантов с пхп ).


_________________
И если вы создавали Pusa как спооб избавиться от JS - и это, имхо, "не прокатит".

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

_________________
И ВАЖНО: поймите вашу нишу. сейчас вы заявляете о слишком большой области, что бы верить вам наслово - это как с новыми языками - создатели всегда начинают свои поделия пихать куда ни попадя. Вот примерно как вы озвучили "непоймикакую" широкую нишу применения.

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

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

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

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

И проблема даже не потому что "у нас уже есть куча ангулярщиков". Заявленное в полном виде (перенос всей логики на сервер) можно будет сделать только через полный аналог rdp- или x- клиента в браузере, и как следствие - полностью перестроить логику приложения на сервере. И придумать кучу компонент под себя (напрмер карты?). А у вас еще и в добавок - нет модели страницы клиента на сервере...

+ массовый веб не поймет увеличения нагрузки на сервер при потенциально неограниченном числе клиентов. Попытки вынести на клиента бОльшую часть логики - и появление тяжелых js-клиентов (реакт-ангулярных) - вот это всё ужасное-и-противное что вы тоже наблюдаете - не от простой же это жизни появилось? Нет. а с целью как раз _разгрузить_ сервер. А вы предлагаете его как раз наоборот - нагрузить. И массовый веб вас спросит - "а зачем?!". и как я понимаю по комментам - уже спрашивает.

А корпоративный сектор "тяжелых" приложений для вас - с php - практически закрыт.
не с php соваться в "тяжелый интерпрайз". ну вот серьезно.
(*) и да предвижу вопросы - сразу скажу : вконтактик - это не "тяжелое интерпрайз приложение". это "одностраничник с _примитивной_ бизнес логикой в 3 клика".

И.... вот как-то для начала так.
Надеюсь я вас не сильно "приложил" ?

Если сможете выдержать - "добро пожаловать в коллектив" ))

_________________

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

Но почему бы не начать с того, что бы сделать ... демки ?  Демки и примеры. Несколько кейсов которые показывают чем ваше решение облегчает разработку приложений.

Потому что вы - создатель. У вас есть идея. А я - токсичный комментатор который не понимает как использовать то что вы предлагаете.
Покажите вашу идею! воплотите! я же пока могу только гадать и вспоминать мои шишки.

_________________
Не знаю что предложить... - давайте скажем ... для начала
1) карту, с отображением только объектов, которые только в отображаемой области. с динамическйо подгрузкой данных с сервера через pusa;
2) выполнение на сервере какого-то длительного расчета с отображением прогресс-бара;

и всё это - на технологии вашего протокола и вашего клиента.
Без много-сот-строчного js-кода и "классических ajaх-запросов" вне вашего клиента.
Всё общение с сервером - только через ваш клиент (ведь перестройка UI - в вашей идеологии - только через него и производится?(троллинг)

Еще покажите как будет вести себя ваше приложение когда будут открыты 2 вкладки в одном браузере - и на ниж будут "нажиматься разные кнопки".

И уже потом можно будет разговаривать более предметно.

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

справитесь?

Ответить | Правка | Наверх | Cообщить модератору

253. "Web-фреймворк Pusa, переносящий логику JavaScript-фронтэнда ..."  +/
Сообщение от stillswamp (ok), 15-Ноя-21, 09:57 
Благодарю за длинный ответ. Отвечу кратко по существу.

1. Pusa - результат работы в архитектурно сложной структуре с 2001 года.
2. Мы реализуем Pusa свои деньги, с благодарностью принимаем советы, но очередность их исполнения выбираем сами.
3. Мы осознаем, что PHP не самый шустрое средство. Он выбран из за простоты и стройности. Реализация Pusa на GO или иных средствах НЕ проблематична, если у кого либо повится таковое желание.

По кейзам:

0 - leaflet - в Концепте Pusa явно указана необходимость JS при работе с mousemove. Если у вас есть реализация без mousemove - изложите и будет предложена реализация без доп скриптов. У нас ЕСТЬ реализация leaflet и минималистичный (благодаря Pusa) JS скрипт, но выложен в рамках Pusa он не будет, так как потребует публикации серверной части, которая не будет опубликована по agpl3.

1 - прошу уточнить задачу. что понимается по понятием Карта. Если выше означенный leaflet то см п 0.

2 - ожидание клиентом ответа более 1 секунды с выводом индикаторов считаю недопустимым - это плохо. при оперативной работе повесить пользователю индикатор с временем ожидания 2 минуты - очень плохо. Блокирует работу. Тяжелые результаты отправляются почтой или телеграмом содержащей ссылку на результат который отображаться в реалтайме. Индикатор загрузки более 1 секунды - ПЛОХО.

3 - прошу уточнить задачу ИЛИ откройте две вкладки браузера и кликните меню на сайте pusa.

Итого прошу уточнить постановку пунктов 1 и 3.

Ответить | Правка | Наверх | Cообщить модератору

255. "Web-фреймворк Pusa, переносящий логику JavaScript-фронтэнда ..."  +/
Сообщение от dplsoft (ok), 15-Ноя-21, 12:48 
пока отвечу кратко, потом с вашего позволения дополню.

и так. пока про leaflet :

вот смотрите : вы, по сути, предлагаете "какой-то-фреймворк". мне в частности, разным посетителям форума вообще (иначе зачем вы это публиковали?). говорите что он классный и на нем можно делать много разных штук и он крутой потому что "полшел нафиг этот js".

я поддерживаю, мне интересно... но возникает вопрос:

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

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

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


еще наверное дополню: мне надо видеть гео-координаты отображаемой сейчас на карте области. т.е. вот я сдвинул область отображения - обновились геокоординаты.

как мне такое сделатт на pusa и как, чем ваш фреймворк будет мне полен, как он облегчит мне решение такой задачи ?


Ответить | Правка | Наверх | Cообщить модератору

257. "Web-фреймворк Pusa, переносящий логику JavaScript-фронтэнда ..."  +/
Сообщение от stillswamp (ok), 15-Ноя-21, 20:40 
1. Вы предлагаете выполнить полноценную работу. Работа = денги.
2. Постановка крайне предварительна и требует уточнения:
- кто провайдер карты (api)?
- если API провайдера подразумевает JS то, есть ли у него событие завершения драгдропа?
- представьте api для получения информации о камерах.

:)

Ответить | Правка | Наверх | Cообщить модератору

261. "Web-фреймворк Pusa, переносящий логику JavaScript-фронтэнда ..."  +/
Сообщение от dplsoft (ok), 15-Ноя-21, 22:53 
> 1. Вы предлагаете выполнить полноценную работу. Работа = денги.

нет, я прошу вас сделать демонстрационный кейс, туториал,
пример того, как интегрировать pusa и js-компоненты на веб-странице.

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

сложность туториала должна быть не сильно сложнее хелловордов на https://leafletjs.com/examples.html

________________________
> 2. Постановка крайне предварительна и требует уточнения:
> - кто провайдер карты (api)?

эээээ.... ну вроде ж как говрили не раз: leaflet... конкретная подложка - как в хелловордах лифлета. там кажется osm...

________________________
> - если API провайдера подразумевает JS то, есть ли у него событие
> завершения драгдропа?

всё необходимое можно найти на https://leafletjs.com/examples/quick-start/

и не драгндроп, а событие moveend, вы мышкой перетаскиваете карту меняя центр точки просмотра. обработчик подключаете через

map.on('moveend', function(e) {
    alert(e.latlng); // e is an event object (MouseEvent in this case)
});

________________________

> - представьте api для получения информации о камерах.

это не важно. рандомно сгенерируйте 100-200 маркеров в квадрате над городом Москва, например.

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

т.е. да, можно отображать даже не камеры, а просто маркеры - тут важно не что мы передаем,
а сам факт передачи по программно генерируемому событию, через pusa,
и обновление координат области карты на странице.

примечание: для простоты область координат можно свести к прямоугольнику на геоиде от левого верхнего угла отображаемой области к правому нижнему (это ответ на вопрос касательно проекции и точности поиска объектов).

Ответить | Правка | Наверх | Cообщить модератору

263. "Web-фреймворк Pusa, переносящий логику JavaScript-фронтэнда ..."  +/
Сообщение от stillswamp (ok), 15-Ноя-21, 23:59 
При наличии события оно может быть направлено на Back, и будет возвращен результат, который ДОЛЖЕН быть обработан так или иначе сторонним скриптом.

Итого: я не вижу существенных проблем в реализации. Если у вас есть таковая потребность, вы можете сделать это самостоятельно (исходники доступны) или подождать когда мы сочтем возможным прислушаться к вашим советам.

ОСНОВНОЕ: если вы намерены использовать сторонние скрипты JS то их ПРИДЕТСЯ загрузить и сделать порт между ними и ответом Pusa. Это явно указано в концепции. ;)

Ответить | Правка | Наверх | Cообщить модератору

268. "Web-фреймворк Pusa, переносящий логику JavaScript-фронтэнда ..."  +/
Сообщение от dplsoft (ok), 16-Ноя-21, 01:51 
>> При наличии события оно может быть направлено на Back, и будет возвращен результат,
>> который ДОЛЖЕН быть обработан так или иначе сторонним скриптом.

а у вас есть примеры того как это делать? потому что ничего похожего в тех трех примерах на https://pusa.catlair.net/?section=Examples я не вижу .


>> Итого: я не вижу существенных проблем в реализации. Если у вас есть таковая потребность,
>> вы можете сделать это самостоятельно (исходники доступны) или подождать когда мы
>> сочтем возможным прислушаться к вашим советам.

"Неет, мужик, ты так слона не продашь"(с) ))

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

Нет, я не требую бегать вокруг меня и делать всё что я прошу. Меня устроил бы ответ "ну... мы постараемся на неделе выкроить время. но не обещаем.". Я ж вам денег не плачу. А вот посыл "разбирайся если тебе надо"... вы знаете - (пока) не надо. Пока все эти задачи прекрасно решаются и уже известными технологиями

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

Меня "напугали" ваши слова 2 поста назад "Вы предлагаете выполнить полноценную работу.".
Т.е. если "встроить карту на страницу с отображением маркеров" - на вашем фреймворке - это "полноценная работа" - то извините.

Мне нужно сокращение затрат и времени, а не "полноценная работа" для создания "прототипа типовой задачи".


Будет интересно услышать о вас снова, когда/если вы доберетесь до расширенных примеров, расширите перечень кейсов в разделе examples и покажете как интегрироваться с js.

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

Удачи.

Ответить | Правка | Наверх | Cообщить модератору

271. "Web-фреймворк Pusa, переносящий логику JavaScript-фронтэнда ..."  +/
Сообщение от stillswamp (ok), 16-Ноя-21, 09:28 
Благодарю за внимание проекту.

Добавлен пример динамической загрузки контента без использования JS на основе события scroll. Аналогичным образом вы можете реализовать необходимый вам функционал для ваших задач.

Примеры - https://dev.pusa.catlair.net/?section=Examples
Гит - https://gitlab.com/catlair/pusa/-/blob/main/site/pusa/php/pu...

Слона мы не продаем. Мы отдаем его даром - и пусть никто не уйдет обиженным. :)

Ответить | Правка | Наверх | Cообщить модератору

240. "Web-фреймворк Pusa, переносящий логику JavaScript-фронтэнда ..."  +/
Сообщение от stillswamp (ok), 14-Ноя-21, 13:00 
-
Ответить | Правка | К родителю #220 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру