Обсудите разработку моего фреймворка

Приветствую всех веб-мастеров!

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

Начал записывать видео с объяснением как что делается. Хочется получать обратную связь от людей кто занимается веб-разработкой. На данном этапе интересуют предложения по настройке контрольной панели и дизайна.

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

1

Сообщение от pgb Сейчас не вижу смысла, так как нет заинтересованности в разработке, будут лишь новые высказывания в стиле на фига, да заче

А вы не увидите ни какой заинтересованности. Любой стартап именно так и начинается: на первых порах автор должен максимально облегчить понимание, разъяснить на конкретных примерах и задах, чем круто решение, какие конкретные проблемы других решений оно решает. В вашем же случае, такое ощущение, что дай вам волю вы и сертификацию обязательную введете, которую будет необходимо получить для ознакомление с вашим решением.

Я вот пробовал ващ обмылок с гитхаба поднять. Увидел стиль кода, там видна рука дилетанта, ну или программиста ни когда не работавшего в долгую со сложными задачами... Какого интереса мне по исходникам выяснять структуру бд?

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

1

Сообщение от voral тем что вы добавляете свои "пресеты" и "свойства".... Ну так это просто еще одни свойства и все. И ни чего более

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

ЗЫ. Да может и моя в этом есть вина не могу хорошо всё объяснить в видео. Но я же тут много что рассказал, но всё равно не доходит.

0

Сообщение от pgb Так вы же нихрена не поняли, в чём смысл то и дальнейшее рассуждение это просто понос непонимающего человека.

И что много таких кто понял?

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

Давайте поговорим за конкретику. Можем пройтись по этим пунктам

Сообщение от pgb 1. Есть узлы - это связка HTML макетов с CSS стилями к ним, которые можно вставлять в страницу, PHP класс для выполнения действий, при необходимости другие файлы; 2. Что в HTML макетах могут быть метки, в которые можно вставлять какой либо свой текст или другую разметку HTML через дескрипторы xml; 3. Что дескрипторы могут генерировать HTML теги; 4. Что через аргументы дескрипторов можно добавлять атрибуты к тегам, прописывать свойства или переменные каскадных стилей, а также вызывать методы PHP класса узлов 5. Ещё некоторые нюансы, но это уже при решении конкретных задач. Позже сделаю свой форум для тех поддержки.

годится? Или сольетесь?

0

Сообщение от voral годится? Или сольетесь?

Вот не надо мне тут всякие условия ставить. Можете пройтись по этим пунктам сами если есть такое желание.

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

0

Сообщение от pgb а вот вы о чём я говорю не понимаете и не хотите понять, с

Я постоянно пытаюсь перевести разговор на тему именно вашего решения, но вы сразу спрыгиваете на "вы ни чего не понимаете". Так давайте разберемся...

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

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

Добавлено через 2 минуты
Или же в вашем мировосприятии "обсуждение" это исключительно хвалебные оды?

1

Сообщение от voral Почему вы так боитесь перейти к обсуждению вашего решения и все время уводите разговор на мою личность? ВЫ же, по вашим заявлением, весьма опытны - значит вам не чего бояться.

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

ЗЫ. Вы хотите сразу прыгнуть на 9й этаж, вот только ноги коротки, смекаете?

0

Сообщение от pgb ЗЫ. Вы хотите сразу прыгнуть на 9й этаж, вот только ноги коротки, смекаете?

Иными словами ваше решение не годится для использования НЕ подготовленными?


Ну, а пока, вы все петляете. Попробую уточнить.

Правильно ли я понимаю. Для описания отдельных страниц сайта (а может быть и частей страниц - из вашего пример пока не очевидно с учетом команды _xml ) используются файлы размещаемые в каталоге mods/<подкаталог_очевидно_отдельной_Страницы> . С минимально обязательной структурой
На основании этого, по сути конфига, производится рендер в html. В данном конкретном случае во что то типа
Чтобы был заголовок и body
надо дописать внутрь anser

До этого момента все так?

0

pgb, voral первый кто вчиталсяв ваш код. Второго шанса может ещё год не быть.

0

Сообщение от voral Правильно ли я понимаю. Для описания отдельных страниц сайта (а может быть и частей страниц - из вашего пример пока не очевидно с учетом команды _xml ) используются файлы размещаемые в каталоге mods/<подкаталог_очевидно_отдельной_Страницы> . С минимально обязательной структурой

Почти так. Роутинг у меня настроен автоматически, не надо создавать отдельный файл и прописывать пути к вьюхам и контроллерам. В директории mods размещаются поддиректории разделов сайта site(открывается по умолчанию), остальные по урл домен.сайта/раздел/страница, между страницей и разделом могут быть крошки(домен.сайта/раздел/crumb1/crumb2/страница), если это страница магазина или форума к примеру.
Если в инструкции xml вызов другой инструкции, то открывается файл в разделе если его там нет, то в корне mods\

Сообщение от voral До этого момента все так?

Далее примерно так, зависит от того что будет прописано в инструкции.

0

Сообщение от pgb плюс моего подхода с XML для начала

имхо уже отмирает потихоньку, json удобнее и понятнее особенно для front и js.
например настройка в одном крупном backend фреймворке совсем отказались от xml, а система сборке где используется xml для описания проектов тоже считается устаревшей

0

Сообщение от alecss131 имхо уже отмирает потихоньку, json удобнее и понятнее особенно для front и js. например настройка в одном крупном backend фреймворке совсем отказались от xml, а система сборке где используется xml для описания проектов тоже считается устаревшей

Я уже на это не раз отвечал и вам отвечу.

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

0

Роутинг пока не буду обсуждать. Пока по началу. Итак, на данном этапе имеем:
1. Ушли от необходимости знать о структуре DOCTYPE+html+head+body, но имеем обязательные OWNI и answer
2. При этом пользователь все же должен знать html. т.к. после знака подчеркивания необходимо писать именно html тег
т.е.
3. При этом структуру html знать важно. Т.к. если человек не впишет <body_body/> то на выходе получится не валидный html, т.к. ваше решение это не контролирует
Итак результаты на данном этапе
1. Некоторое послабление в необходимости знания html структуры, но замена своей структурой
2. Теряем подсказки/линтеры в IDE. что достаточно полезно для не специалиста, тем более не особо желающего стать профи.

Смотрим, что в других решениях.
symfony - это фреймворк. Там где я его использую, вообще не генерирутеся на php ни какого html, т.к. я фронт выделил на react и симфа только как бек. Но, чтоб приблизить, сравнение. Берем тот шаблонизатор, который в доке рекомендуется и идет "по умолчанию" twig

для написания того же самого
При этом, если необходимо можем и base.html.twig гибко изменить, без необходимости изучения php. В вашем решении я могу изменить базовую конструкцию страницы?

Битрикс это CMS типовая страница
Тут уже, по сути смесь php и html. Тут уже надо понимать, что тут именно php используется в качестве шаблонизатора. Но, вот данную страницу пользователь создает просто нажатием кнопки "создать страницу", заполнив поле Заголовок и отредактировав контент (в данном примере "page content")

Так же если есть необходимость у нас в полном управлении основной костяк страницы.

Т.е. пока (не углубляясь уже в другие задачи) для не подготовленного пользователя предпочтительнее именно Битрикс (а точнее класс инструмента CMS).

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

симфа - html + twig
omni - html + omni
bitrix - html + php

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

По объему справочной информации omni отстает по объективным причинам (пока нет ни какого сообщества и это пока в разработке)

На этом этапе все так? Есть разногласия?

Сообщение от pgb Для программирования я не спорю xml не удобен есть более быстрые json,yaml. Но у меня же задача не программистская, а указательная, почти как шаблон, но чтобы набирать визуально было привычно и удобно как практически в HTML в котором любой школьник уже может что-то сделать.

Тут я бы не был столь уверен на вашем месте. Я внедрял много разного ПО (начиная с Win3.11 и win9x вместо DOS) и на прямую работал с пользователям - то что вам кажется и думается, могут быть две большие разницы. Реальную же картину может показать что то типа А/Б тестирования. Посмотрите, кстати, на ту же симфу для декларативного описания можно использовать либо yaml либо xml.

0

Сообщение от voral 1. Ушли от необходимости знать о структуре DOCTYPE+html+head+body, но имеем обязательные OWNI и answer

Не от чего мы не ушли. Макеты страницы как писались на HTML так и пишутся, подключить любой макет можно указав узел.="макет", пользователю который будет писать инструкцию страницы надо только это знать. Разработчики могут как обычно делать макеты в HTML+CSS

Сообщение от voral 2. При этом пользователь все же должен знать html. т.к. после знака подчеркивания необходимо писать именно html тег

Это не обязательное условие, для новичков будут подготовлены готовые конструкции скопировал и вставил как в бутстрап. Более продвинутые кто знают HTML, CSS могут прописывать теги и стили прямо в инструкции или делать свои макеты. В будущем может сделаю и визуальный редактор как в конструкторах.

Сообщение от voral 3. При этом структуру html знать важно. Т.к. если человек не впишет <body_body/> то на выходе получится не валидный html, т.к. ваше решение это не контролирует

Если в инструкции xml будет ошибка, то страница не сгенерируется и выдаст ошибку, с указанием в каком файле и какой строке ошибка.

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

0

1. ок
2. ну так надо же знать и что копировать, ну +- ок. надо смотреть дальше на, на данном этапе, как минимум он должен знать что есть обязательный тег body или body_body.
3. Я говорю не ошибке xml, а ошибке html. Это важно, хоть браузер и прожует почти все что угодно, но для существования сайта это важно

Сообщение от pgb Пока вы не поймёте назначение использования мною xml вы так будете только ссылаться на существующие инструменты, но они намного хуже, если вы не вникните как с помощью xml движок генерирует страницу. Я вам уже сказал не ищите минусы, попробуйте поискать плюсы, тогда до вас может и дойдёт.

Я как раз таки пытаюсь последовательно найти плюсы, но не на "общих словах" из серии "когда корабли бороздят просторы", а на вполне конкретных примерах выполняющих одни и те же действия.

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

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

На данном этапе и исключительно для той задачи (формирование "костяка" отдельной страницы) все так?
Нет проблем в других инструментах которые решает ваш инструмент?

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

1. Неподготовленный совсем
- Symfony + twig.(любой бекенд фреймворк) - должен изучить как минимум twig, куда положить файл, представление о минимальной структуре не обязательно, html полезно если захочется минимальных каких то "оформлений"
- Битрикс (любая CMS) - навыка работы в Word достаточно.
- Ваш - нужно знать синтаксис ваш, html полезно если захочется минимальных каких то "оформлений"

2 Уже знающий html
- Symfony + twig.(любой бекенд фреймворк) - должен изучить как минимум twig, куда положить файл, представление о минимальной структуре не обязательно
- Битрикс (любая CMS) - навыка работы в Word достаточно.
- Ваш - нужно знать синтаксис ваш

3. Продвинутый
- всем пунктам докидываем php, html

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

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

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

Добавлено через 2 минуты
Далее, готов из минусов убрать все что касается, что у вашего решения нет ни документации ни сообщества готового помочь пользователю "если что"......

0

Сообщение от voral Нет проблем в других инструментах которые решает ваш инструмент?

Как работает обычный шаблонизатор? Есть HTML разметка\макет в котором есть метки например в твиге {metka}. Шаблонизатор ищет эти метки если есть в них условие, интерпретирует выполняет, затем вставляет вместо этой метки сгенерированную разметку. Правильно? Правильно. Так вот чтобы это всё выполнить нужно в большом макете побайтно проверить соответствие началу метки, концу метки, вытащить от туда текст, потом при вставке опять же найти эти метки, можно конечно запоминать позицию, но всё же в большинстве случает используется str_replace. Короче это очень много лишних телодвижений..
Мой движок решает эту проблему. При открытии xml документа на машинном уровне создаётся объект, по которому движок без всякого парсинга и поиска меток находит команды, получив мини макет, в котором быстрее найти и заменить метку чем в большом, то есть всё происходит в разы быстрее. Так же такой подход решает и массу других проблем которые есть в существующих инструментах, например стилизации, работы с базой данных, диском\файлами и тд.

0

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

2.

Сообщение от pgb но всё же в большинстве случает используется str_replace

Отвечу бегло, чтоб просто мнение озвучить. Но вот обсуждение предлагаю либо отложить, либо переключиться с обсуждения "с позиции пользователя" на обсуждение "с позиции разработчика" или даже, точнее, с позиции архитектуры и реализации вашего решения
Ну условно... Но прям не во всех. тут зависит от реализцаии и от квалификации. В вашем случае пасер точно так же есть ведь оно же не само волшебным образом начинает работать. Как я понимаю, вы просто взяли и используете существующий в PHP парсер XML. Что ж это быстрее в общем случае, но вот интерпретировать все равно будет ваш код. А не "встроенный". Разве встроенный парсер понимает что делать с "vif"?

0

Сообщение от voral нужно знать синтаксис ваш

Это не такая уж и проблема всего навсего пара принципов и с десяток команд движка в отличие от многостраничных документаций в других фреймворках. Да у меня тоже будет документация, но там будет в основном не о том какие команды придуманные разработчиками фреймворка, а о том как прописывать указания для получения чего-то на странице или записи данных в файл\базу. Для профи тоже многого знать не нужно будет, как создать свой php класс, который мог бы вызывать движок и всё , остальное пусть пишут что хотят, ну и по JS как подключить модуль и несколько функций, самое основное, без кучи ненужного, что может никогда и не пригодится.

0

Ну тут не важно проблема или нет. Важно, что надо что то "новое для конкретного себя". Ведь пара принципов или их десяток, это всего лишь вопрос в широте возможностей инструментов. Чем больше будет появляться возможностей, тем больше будет появляться.

Ну так все таки. Есть в том резюме которое я подвел под шагом "создание новой страницы" (пока без какго то существенного наполнения) то с чем вы совершенно не согласны?

На мой взгляд, если вообще коротко: для совсем не подготовленного - вариант CMS самый простой (просто нажать кнопку "создать страницу" и ввести ее название в поле), для остальных категорий пользователей варианты +/- равны.

Все так?

0

Сообщение от voral 1 Погодите мы сейчас пока обсуждаем именно взаимодействие с пользователем, а не внутреннюю реализацию.

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

Сообщение от voral Что ж это быстрее в общем случае, но вот интерпретировать все равно будет ваш код. А не "встроенный". Разве встроенный парсер понимает что делать с "vif"?

Да есть несколько команд движка и их не много, для логики, ещё неймспасе есть(сделал для авторизации и показа нужного контента от прав пользователя), правда вот думаю убрать их сделать только при обработке одного answer, а не во всём документе.

0

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

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

?

0