Я вижу будущее web-разработки — оно прекрасно!
всё из одного места будет разворачивать интерпретатор, например:
newUser{#div1}, showUsers{#singleUser}, getUserInfo{.userInfo}{
name[[A-zА-я]{7}], age[3], salary[\d{4,7}]
}
в заданные блоки шаблонов в соответствующих экшенах добавляются атомы строки из вновьсоздаваемой таблицы, поля которой заданы.
Синтаксис конечно будет сложный, но зато всё в одном месте, не надо будет растраиваться-раздваиваться.
Думал, ну откуда берется столько .... в айти? Или может, троллит?
Открыл профайл автора:
Хочу получать свой кусочек IT-пирога
PHP+JS+вёрстка.
фрилансю, 6 лет трудился преподавателем в Академии ШАГ. Сейчас мне 36
Всё сразу встало на свои места )
Чтобы было больше ада, в этот пост надо добавить ссылку на Emmet
Это прошлое, как раз, от этого и пришли к разделению MVC, как к более поддерживаемому и single responsibility паттерну, новички или не очень опытные разработчики могут писать запросы в базу прямо из view, там же логику — но это очень ужасная вещь с точки зрения исправления ошибок и развития проекта.
так все уже изобретено github.com/...heckout/pages/success.php
На DOU выражение «у этого человека семь пятниц на неделе» имеет свой особый смысл...
Я вижу будущее web-разработки — оно прекрасно!
Ясно. Осталось постоять с колокольчиком под софтсервом :)
Как на этом «будущем» слепить хотя бы ToDo list? А что по сложнее? Еще и связи через #id? С этого максимум вышел бы какой то очередной табличный процесор или шаблонизатор. Возможно даже ucoz. Каким боком это можно позиционировать как будущее веба хз.
Будет ли такой язык программирования, который вберёт в себя MVC? Т.е. не надо будет думать отдельно про клиентскую часть, и отдельно про серверную.
Будет ли такой язык программирования, который вберёт в себя MVC?
К счастью нет. Даже если бы это было возможно, будем плодить ЯП на каждый архитектурный шаблон?
Т.е. не надо будет думать отдельно про клиентскую часть, и отдельно про серверную.
Как можно тут думать отдельно? То, что сгрузите код в один файл, вместо двух, ничего не по меняет. Все ровно будет два слоя, о которых нужно будет думать, а думать будет легче, когда мухи и котлеты отдельно. И это если не касаться вопросов поддержки кода и коммерческой разработки с разделением ролей. Можно, конечно, попытаться решить некоторые частные задачи, типа автоматизации валидации/синхронизации данных моделей по обе стороны, но это и так уже решалось не одним велосипедом и никак не «языком программирования». Если тут и возможна хоть какая то практическая реализация, то она будет для решения частных задач, и потеряет всякую гибкость, это будет уровень скриптования в cms...
MVC не надо обьединять его надо выкинуть из веба кик наиболее неудобную парадигму. Что касается вышенаписаного то это полная чушь. Попытки декларативного вывода данных предпринимаются давно но ничем хорошим жто не заканчивается. Максимум для построения отчетов. Да и то свмых простых
А что вместо MVC?
Если есть вдохновение, нужно как можно быстрее пробовать сделать рабочий прототип, иначе эти все обсуждения просто «пар», пустая трата энергии. Потом уже можно обсуждать реализацию идеи, пытаясь примерить ее для текущих или будущих задач.
Я никогда не писал интерпретаторов, нужен сильный программист.
Чувак, то что ты написал называется язык предметной области. И если есть конкретная идея, ты бы изложил понятно
Автор, а вы случайно не знакомы с dou.ua/users/mihail-kuzmin ?
Я много с кем не знаком.
Почему вы спрашиваете? Не помню чтобы я был с ним знаком.
Скажем так, ваши идеи похожи.
Ссылку на гитхаб в студию
Это в будущем, если Web не постигнет судьба Александрийской библиотеки.
Всякие там YII, Laravel и прочие думаю всё таки соединяться с Vue, Angular в автоматизированном конструировании сайта. Очень уж неприятно разрывать соображалку на бэк и фронт, пусть умный интерпретатор сам это делает.
«Мы ознакомились с вашим коммерческим предложением, и хотели бы купить партию того, что вы курили когда его писали...»
А ничего, что раньше бек и фронт и был соединен? Только не Vue, Angular были интегрированы в фреймворк, а jquery с библиотекой jqueryui и bootstrap. В Yii1 были экстеншны, чтобы настраивать jquery из-под пыховских конфигов и можно было пыхой рендерить готовые стилизованные элементы. Тоже самое и с bootstrap, например, было в SonataAdminBundle для symfony 2, где js бутстрапа можно было кастомизировать (и можно, наверное, до сих пор, бандл все еще поддерживается).
Но время рассудило иначе. Пару лет назад из стандартной поставки symfony убрали assetic bundle, который давал расширенное управление ассетами (css, js, images) как раз для сценария, когда бек и фронт объединены и html, css, js, images приходят целиком из пыховского бекенда. Но они это убрали, судя по всему, из-за большой популярности js фреймворков, которые сами рулят ассетами.
Так что всё новое — хорошо забытое старое. :)
Автор, если ты принимаешь какие-то препараты, поговори завтра со своим психиатром об этой идее. У тебя очень сильные сайд эфекты и нужно скорректировать дозировку или подобрать другой препарат.
До сих пор нету во фреймворках типов полей photo, comment, name и т.д.
Зачем в фреймворках какие то поля и чем это лучше композиции и компонентов? Фреймворк это не cms. Хотите блок комментариев? Пишите компонент, который их реализует, и используйте в проектах, передавайте ему какой то link на его api- неужели написать что то типа
<comments-block link="/discussion/1234"></comments-block>хуже чем какое то теоретическое месиво еще на одном
Не надо ходить по страницам, кликать мышкой, можно сразу для десятка сайтов такую команду выполнить. Далее можно в продвинутом режиме редактировать получившийся промежуточный код — прописывать бизнес логику. Далее такие команды интерпретатору loveWeb могут быть намного более изощрённые. Этот интерпретатор может генерить код для разных фреймворков, под разные языки.
пусть этот супер-интерпретатор называется loveWeb (logo: зелёное сердце в центре паутины).
Например я хочу сделать возможность добавления и показа на сайте фоток с комментариями.
вписываю интерпретатору loveWeb
addPhoto, showPhotos
{photo photo, comment comment[\w{1,255}]}
и сразу готов экшн с добавлением фотки и комментария в таблицу, готов экш показа всех фоток.
Автор видит будущее в xslt-трансформациях, похоже, и его видимо от этого поющит
либо рождение meteor :)
либо веб-метеоризм...простите
В одном месте прописывается инструкция для интерпретатора, далее интерпретатор сам заносит/редактирует данные в базе, заполняет/редактирует шаблоны. Программисту не надо бегать по шаблонам, контроллерам, моделям.
автор, а почему ж тогда нам с вами не опустится до машинного кода?
Имхо ваши рассуждения —> бред сидой кобылы, очень мало связанные с реальностью.
Модульность приложения — основа его легкочитаемости, и адекватной и быстрой работы разработчика с ним. Ваш паста код умер ещё до развала союза, смиритесь
Alexey Romanov
Dmytro Kolesnykov
Timur Chanturia
Владислав Фурдак
Eugene Varava
Vitalii Maklai
Dmitriy Mozgovoy
Dmitriy Mozgovoy
Леонид Мартынюк
Podoprigora Alexandr
Владимир Кожаев
Artem Mikhmel
Andrew Miroshnichenko
Andrew Miroshnichenko
Oleksii Kraievyi
Konstantin Strukov
Artem Frolov
Artyom Krivokrisenko
Anton Katrus
Valentyn Ponomarenko
Mykola Gurov
Vyacheslav
Vlad Stelmahovsky
Хонько Олександр
35 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарів