Здравствуйте.
Представляю js фрамворк для критики.
login: admin,
password: admin
https://storageservice.pharmproekt.am/
https://pharmproekt.am/?language=en
Какие были цели при создании фреймверка? Сложно давать конструктивную критику не зная целей и ограничений.
А Вы посмотрели гриди, вошли по логин, парол? Сложно давать конструктивную критику не видя основную картинку.
Да, я зашел и покликал элементам и ссылкам
не по ссилкам а по грид кликнули? проходили по контекс меню над грид, над калонки?
прокручивали строки?
Да. Я покликал по элементам грида и по контроллам над гридом. Контекстное меню не пробовал, сейчас кликнул и увидел.
На основу фрамворка заложен такой архитектура кода, что теортически можно разработать любой сложности веб проект с крепким фундаментом. Почеркиваю, когда гаварю любой сложности, не алгоритмичецких задач а по конструктировании каркасни архитектури кода проекта. То есть можно создат компоненти и из этих другие, с изяшним АПИ - не ползоватески а иммено програмни интерфеисом. Уви это показат не буду, исходние коди. Вы можете мисленно начертат эскиз дла создания таково грида с одним из фрамворков Вам знакомо, и оценит сложност разработки такого. А с этим фрамворком, это не сложно.
Кое что представляю. В этом проекте, бакенд разработка толко веб сервис дла получениа данних от база данних, с ajax/json формат. То есть ни каких php, aspx, толко html, css, js, asmx. Страница рендериуетса не бакенд а с js скриптом. Да, знаю скажите, что если отключат движок js броузера, то саит не будет работат. Но плюс то что с этим вес рендеровани наложится на бриузера, и на сервера наложена толко нагрузка отправлениа чисто динамических данних от база данних. если привични подход бакенд это смешивание статическои развортки и динамических данних и отправка к клиенту. то с этим фрамворком, статическая част перенесен на фронтенд джаваскрипт код. трафик/бандвид интернета уменшается, на счет броузера.
Во-первых давай на “ты”, если это достаточно удобно для тебя.
Цели не понятны. Ты дал ответ на вопрос “как” но не на вопрос “для чего”. Чтобы было проще понять о чем я, ответ на вопрос “для чего” может быть “для того чтобы я создавал сайты на заказ быстрее, используя собственную CMS” или “хочу научиться решать задачи подобного класса”.
Если тебе столько лет как ты выглядишь на фотке, то это отличное достижение. Мало кто может в твоем возрасте похвастаться такой штукой.
Решаемый класс задач называется общим словом CMS/framework. То что ты сделал это нечто среднее между визуализацией базы данных, CMS и framework-ом (где CMS это более дружественная система для тех кто не понимает устройства данных). Поиск по словам “Database GUI tools” даст список подобных.
Вообще, это стремление сделать универсальное решение присуще много кому, мне в том числе, но реальность такова что универсальных решений, особенно для такой распространенной задачи как CMS просто нет. Все что есть универсальным и все что можно изобрести и внедрить - изобретено и внедрено. Настоящее приближение к универсальности это всегда отталкивание от того что уже распространено и что людям знакомо. Тогда им будет проще увидеть ценность твоего решения и начать им пользоваться.
Следующее важное это то что люди “любят” глазами. Люди, даже программисты, выбирут менее функциональное но более “вылезанное” решение если им дать выбор. Если хочешь чтобы твоей поделкой пользовались ей нужно придать вылизанный вид. Самое оптимальное, если не хочется утонуть в изучении дизайнов-графических редакторов, взять существующую дизайн систему (bootstrap, material design, и все что поиск выдат на альтернативы этим системам). Или вообще готовый дизайн с уже набранными компонентами (типа того что делает компания primefaces, Sakai - PrimeNG), которые и сработают под мобильники-планшеты и на десктопе. Правда, тебе придется интегрироваться с ними, и их ограничения станут частью ограничений твоей системы. Зато ты сможешь сфокусироваться на логике и данных, не переживая о качестве дизайна.
Контекстное меню лучше всего сделать явной кнопкой потому что люди не привыкли проверять “а работает ли контекстное меню на конкретно этом элементе”.
Для класса задач твоего типа есть сложный в целом не решенный вопрос с реляционными данными. Как их создавать, как их моделировать, как показывать и реализовывать Когда у тебя есть пользователь, ему принадлежит пост (с 1-к-1 отношением), к посту привязаные комментарии (1-ко-многим). И вот пользователя удаляют, и нужно чтобы система смогла “удалить” (иногда это просто дополнительный флаг) его посты и комментарии.
Еще одна проблема с данными - миграция. Миграция как схемы базы (было 2 таблицы по 3 поля в каждой, для новой версии программы нужно уже 4 таблицы, при том поля из одной из первых двух перенести в эти новые) так и данных (мигрировать существующие данные в ). Многие (например prisma orm )даже выбирают не решать эту задачу а фокусироваться только на описании модели базы.
Если речь про задачи “любого уровня”, то тебе придется столкнуться с задачей коммуникации клиент-сервера. Тут есть много вариантов, кроме классического HTTP REST. Например, имеет смысл посмотреть в сторону RPC (remote procedure call). Или еще вариант - реализовать graphql на клиенте и сервере, использовать готовые компоненты для клиента (а там уже есть и реактивность и кешируемость и интеграция с популярными фронтенд фреймверками). Тогда у тебя вся модель будет описана в graphql и не нужно будет заморачиваться с путями для HTTP-хендлеров. Но, как я говорил, интеграция каждого подобного компонента стоит и сил и архитектуры. Но обычно они решают больше задач чем приносят проблем.
И последнее психологическое, основывающееся на личном опыте. Ты будешь любить, понимать и видеть возможности своей поделки. Но другие люди этого не будут видеть. Пока они не увидят конкретной демонстрации (плюс помни про любовь глазами), или пока они не услышат в твоих словах решение своей проблемы (именно как они понимают ее, а не как ты это понимаешь), они не повернутся в сторону твоего творения.
В любом случае опыт создания такой вещи - отличный опыт. С ним тебе будет проще и создавать-поделировать новые системы, и понимать-интегрироваться с ними.
Самый лучший следующий шаг (если хочется вырасти и готов слушать кого-то из интернета) это посмотреть как эти же самые задачи что решал ты решили другие люди (найти альтернативы с открытым исходным кодом).
И да, сессия не позволяет несколько пользователей с одним и тем же логин-паролем. Возможно это имеет смысл с точки зрения администрирования, но для показа демки это создает лишние преграды.
Я не против на ты
Лопата уже создана для копания почвы. Зачем нужен трактор? По этой логикой ты мне объясняеш. То ест если уже есть фрамворк для создания проектов, другово излично? Странная логика. Да мое не перви фрамворк, а если этот фрамворк более лехко делает разработка проектов, чем осталние? Допустим на реакт полноценни грид виджет создали 10 програмист на 6 мессяц, а я один на 3 месяца это ни что? Или может на этом фрамворке ест уникалние решение, что код делает более компактное, гипкое, бистрее? Потом тогда почему так много фрамворков? На этом пункте все, скоро перейду к остальным пунктам.
Да, это самое тонкое место. Чтобы полностью понять ценность моего фреймворка, необходимо привести примеры, а это именно то, чего хотят разработчики, открытые исходные коди. Но именно здесь моя интеллектуальная собственность, которую я не хочу раскрывать. Надеюсь, что вы сможете хоть в какой-то степени оценить и понять представленный интеллектуальный продукт, попытав сделать что-то подобное с теми возможностями, которые есть в вашем распоряжении на данный момент. Например: если вам представили CPU процессор, то чтобы понять и оценить сложност этого продукта, ты можеш узнать это, попробовав сделать его самостоятельно. Или чтобы понять сложность, тебе должно узнать весь процесс технологи изготовления? Я могу привести много подобных примеров. На алглоязычном форуме я привел пример автомобиля, за рулем которого можно сесть вадить, но не нужно открывать капот и смотреть чертежи, чтобы понять, какие функции у автомобиля. Увы, я могу дать открытые коды толко на одну кампанию, которая заинтересуется, потому что здес принцип - если я даю одному, то даю всем. Именно он будет покупать и быть полноправным владельцем авторских прав, а также будет готовить проекты и развивать библиотеку виджетов. Короче говоря, тот, кто сможет понять ценность этого фрамворка без приобретения интеллектуальной собственности, станет ее владельцем.
Я скажу почему я решил написать свой фрамворк, вместо того, чтобы использовать одно из фрамворк так много вариантов.
Вот иммено, с моим фрамворком я могу свободно реализовать решения любой глубины. Короче говоря, свобода реализаци с моим фреймворком намного больше, чем свобода использовать другой фреймворк.
Ты там много чего написал, много из них мне не знакомие, Как ты сказал если магу с этим маи прикладние задачи решат почему мне другие? Толко вапрос в том, катори из них эфективнее? Вот тут я не буду спорит с табой, потому что то малое что знаю об других фрамворков посмотрев примерние коди, мне виднее хорошие сторони моего фрамворка.
Да, я интересовался в интернете других решени прокручиваемих гридов и если ты заметил 2 из них линки постаавил в саите, но скажу радикално не похожие решение с моим. То ест это не создание нового велисопеда.