Множество раз я пытался писать, следуя патерну, но результат всегда доводил меня до безумия.
Ожидаемо. Паттерн MVC в вебе, как я уже писал тут в своей публикации — как на корове седло. HMVC и прочие изощрения только доказывают несостоятельность MVC паттерна (имеется ввиду паттерн в вебе а не вообще).
Нет ничего естественнее для веба чем компонентный подход. Хотя бы потому что пользователь видит интерфейс и взаимодействует с элементами интерфейса а не с контроллерами. Если человек нажал кнопку то должно отработать событие связанное с кнопкой а не абстрактный экшен.
Пользы от делфи тут не намного больше. Java по кравней мере кросплатформенная и к ей проще прикрутить какой нибудь скриптовый язык в виде DSL.
Но это по любому не спасает «отца русской демократии»
Никакой бухгалтер не станет осваивать язык програмирования. Последняя версия 1С где я видел чтобы бухгалтер редактировал что то была 1С 2.0.
Попытка повторения 1С на делфи или яве заранее обречена на провал. Плюсов 1с не достигаем зато добавляем минусов в виде приложения которое еще и перекомпиливать приходится. То есть если для 1С требовался приходящий програмист то здесь придется держать штатного. Но в таком случае зачем построитель форм? Достаточнго было бы какого нибудь декларативного дизайна.
Впрочем, как раз готовлю статью про то как следует писать приложения-альтернативы 1С.
.
Я лично использую сабж в офисе для того чтобы любопытные сотрудники когда меня нет не влезли куда не просят — например в почтовый ящик. Думаю большинство использует примерно также. Это к тому что критичное с технической точки зрения проблема не является критичной де факто для большинства случаев. Кто хранит реально важные конфиденциальные данные хранит их там где TrueCrypt уже без надобности.
Еще раз. Здесь обсуждается концепция. А вы мне расказываете о неких готовых решениях гридов и прочее.
У майкрософта сотни програмистов. Они понаписали компонентов. Я написал то что успел написать.
Как наличие того или иного компонента написаного в пределах концепции влияет на саму идею? Завтра напишут компонент с фильтрами и сортировками на перле для CGI и что это докажет?
Я вам показал простой грид где чистый HTML код и код который для Razor где вообще никакого HTML а непонятная верстальщику абракадабра где ему надо еще догадаться как добавить атрибут в тег. А вы продолжаете доказывать что верстальщику там проще.
В MVC програмиста волнует какой там будет заголовок а в моем решении нет. И не должно волновать — програмисту незачем заглядывать в PSD файл созданный дизайнером чтобы прописать заголовки в модели для грида. Вы считаете что должен? Тогда в чем смысл разделения кода от представления?
Вообще спор уже бессмысленный. Я не ставлю задачу когото переубедить.
. пишите как вам по кайфу.
Мне понравилась идея я ее реализовал попинал, понял что это есть хорошо и изложил это на бомаге. Удачи.
.
.
Относится-относится. Вы декларируете, что в вашем решении верстальщик имеет дело с обычным html-кодом. Вот я и хочу на это посмотреть.
я вм уже сто раз показал — это все чистый HTML
С того, что люди ошибаются.
А в MVC человек не может прописать не тоо название в атриуте модели?
Для asp.net mvc, конечно же, есть компоненты, поддерживающие инлайн-редактирование в гридах.
Это, как и вышеуказаное, не относится к сути обсуждаемого архитектурного решения. Надо будет сяду и напишу такой компонент для своего фреймворка. С фильтрами блекджеком и юными пррамистками. Пока инлайн редактирование нафиг не нужно было ги в одном проекте…
А в вашем коде название прописано отдельно, привязка к данным — отдельно. Ничего не стоит перепутать.
С чего бы оно путалось? Табличные данные выводят сколько существует HTML — первый раз слышу о проблеме перепутывания заголовков и данных.
… и если ни один не работает, я не знаю — ошибка в самих линках или в бизнес-логике.
ошибка в бизнес логике. В самих линках это когда вы дергаете экген а контроллер не реагирует. и ка тут поможет югит тестинг.
А еще бывают, внезапно, совместно используемые бизнес-объекты.
и какие проблемы?
Я семь лет писал на WebForms, потом пять лет на MVC — и после WebForms писать на MVC было намного проще.
а я сделал чтобы было ее проще.
Есть фундаментальная разница между «я явно вызвал слой представления и передал ему данные»
это словоблудие. я не вызываю никакой слой представления.
Я передаю данные компоненту. Там может быть мильен всякизх слоев а может быть ни одного.
компонент например может ответить аяксом.
Суть компонентов чтобы программист не пудрил себе и другим мозги всякими слоями.
Во-первых, если вы не можете что-то понять и применить, это еще не делает его дебильным
Именно потому что применяю и вижу что оно дебильное.
я трачу намного больше времени чем в WebForms. хотя бы для реализации персистентности.
Во-вторых, в MVC прекрасно можно использовать компоненты, так что «вместо» здесь неприменимо.
там где компоненты MVC нечего делать.
У меня есть компонент — он реагирует на клиентское событие серверным обработчиком. Шо тут делать MVC?
Ну запихните MVC в WebForms или наоборот если не понимаете о чем речь.
как и в .NET MVC соответстующая ссылка в заголовок.
Фильтрация?
каким боком тут фильтрация?
Раскраска зеброй?
CSS3 — 21-ый век за окном
Пейджинг?
есть компонент который прописывается одной строкой кода.
На клиенте просто Все остальное автоматически — генерация страницы, обработка событий и вынимание сооьвеььсвующей порции данных из источникак данных для грида.
а что в MVC есть инлайн редактирование?
Впрочем, здесь я могу автоматически вывести таблицу в любыми инпутами и все они автоматически же отправятся на сервер.
(отдельно большое вам спасибо за необходимость дважды определять колонку — сначала в заголовке, а потом в теле)
Почему дважды? заголовок это верстка — там ничего не надо определять.
Кроме того для чисто текстовых жанных есть еще один компонент который автоматически
рендерит сортировку и пагинацию
А чтобы есть командой, надо побить на кусочки. А кусочки, в свою очередь, хочется тестировать вне зависимости друг от друга.
они и так независимы. тестируете реакцию одного линка потом другого.
Почему? Юнит-тесту не нужная сетевая карта для работы.
Никакому не нужна если на локале. Всем нужно если нет.
Во-первых, не DTO, а ViewModel. А во-вторых — меняет. В asp.net MVC я не обращаюсь к представлению, я возвращаю данные, которые использует представление. Inversion of
control.
Это именно DTO как бы вы его не называли. Присваиваете данные некоей структуре и отправляете ее менять представление. Как шаблонизатор использует данную структуру сути дела не меняет. Там Inversion of
control у меня DOM модель.
asp.net MVC решает их лучше.
с точки зрения фаната MVC — да.
На работе я програмирую и на WebForms и на MVC — мое решение лучше этого. Все относительно. По крайней мере я могу сравнивать на практике свсе три подхода а просто теоретизировать.
А язык определяет код, который на нем написан. Появился новый язык — изменился код.
смотря что писать. 2+2=4 ybrfr yt vtyztncz jn yfdjhjxtyjcnb zpsrf/
то все ваше предложение сводится к asp.net WebForms с другим шаблонизатором и viewstate в сессии.
viewstate там ни причем.
мое предложение сводится к использованию компонентного подхода вместо дебильного MVC.
Нет, потому что сложность проекта больше, чем может съесть один человек.
ну так ешьте командой.
То я этого в юнит-тесте не увижу никогда, и слава б-гу.
вы ввобше ничего не увидите и ваш юнит тест будет нае намного полезнее комлексного. Отсюда вопрос а на фига он.
Прямое обращение к представлению.
обращение к компоненту. Или по вашему промежуточная структура в виде модели (а точнее не модели а DTO) в MVC меняет суть дела и вы там не обращаетесь к представлению?
считайте что компонент такой же промежуточный слой.
А смысл, если я могу взять работающий и решающий мои задачи asp.net MVC?
WebForms тоже решал ваши задачи. Более того старый добрый CGI тоже.
C#, например. И посмотрите, какой путь он проделал: дженерики, лямбды, LINQ, динамики.
я имел ввиду код а не язык. Если вы имеете ввиду что все эти шняги нужно юзать то я не против.
В данном случае я не хотел чтобы код сильно отличался от PHP прототипа. Меньше писать коментов, проще искать ошибки, и все такое. Потому просто переложил с учетом другого синтаксиса.
Да и какая разница как я там написал. Речь о сути идеи и ломке стереотипов. забудьте вы мой код как страшный сон.
В этот момент у верстальщика взрывается мозг: он делал верстку с учетом двух дивов, а он стал один.
пока ни разу не взорвался
верстальщик вообще то когда верстает имеет представление что он верстает и как оно работает.
а как по вашему работает интерфейс на каком нибудь ангуляре где виимость блока прибиндена к тем же радиокнопкам?
И снова плач верстальщика: он написал одно, а в аут ушло другое.
какое другое? Ушли данные а не изменилась верстка. Да текст в поле может оказаться разной длины но я не вижу как бывает по другому при других технологиях.
в данной реализации да
можно было бы конечно выставлять display:none но зачем гонять лишнее.
если у компонента стоит что он невидим шаблонизатор его просто проигнорирует.
В противном случае будет вызван метод render()
и компонент изменит соответствующий ему фронтэнд тэг.
а может все таки персистентный хранилищем — ну там я знаю… сервером Бд например.
Ожидаемо. Паттерн MVC в вебе, как я уже писал тут в своей публикации — как на корове седло. HMVC и прочие изощрения только доказывают несостоятельность MVC паттерна (имеется ввиду паттерн в вебе а не вообще).
Нет ничего естественнее для веба чем компонентный подход. Хотя бы потому что пользователь видит интерфейс и взаимодействует с элементами интерфейса а не с контроллерами. Если человек нажал кнопку то должно отработать событие связанное с кнопкой а не абстрактный экшен.
Но это по любому не спасает «отца русской демократии»
Попытка повторения 1С на делфи или яве заранее обречена на провал. Плюсов 1с не достигаем зато добавляем минусов в виде приложения которое еще и перекомпиливать приходится. То есть если для 1С требовался приходящий програмист то здесь придется держать штатного. Но в таком случае зачем построитель форм? Достаточнго было бы какого нибудь декларативного дизайна.
Впрочем, как раз готовлю статью про то как следует писать приложения-альтернативы 1С.
.
у мускула как раз нет оконных функций
вообще Entity подразумевают уникальный ключ. Если и он совпадает то это таки одна сущность. По крайней мере одна бизнес-сущность.
Еще раз. Здесь обсуждается концепция. А вы мне расказываете о неких готовых решениях гридов и прочее.
У майкрософта сотни програмистов. Они понаписали компонентов. Я написал то что успел написать.
Как наличие того или иного компонента написаного в пределах концепции влияет на саму идею? Завтра напишут компонент с фильтрами и сортировками на перле для CGI и что это докажет?
Я вам показал простой грид где чистый HTML код и код который для Razor где вообще никакого HTML а непонятная верстальщику абракадабра где ему надо еще догадаться как добавить атрибут в тег. А вы продолжаете доказывать что верстальщику там проще.
В MVC програмиста волнует какой там будет заголовок а в моем решении нет. И не должно волновать — програмисту незачем заглядывать в PSD файл созданный дизайнером чтобы прописать заголовки в модели для грида. Вы считаете что должен? Тогда в чем смысл разделения кода от представления?
Вообще спор уже бессмысленный. Я не ставлю задачу когото переубедить.
. пишите как вам по кайфу.
Мне понравилась идея я ее реализовал попинал, понял что это есть хорошо и изложил это на бомаге. Удачи.
.
.
я вм уже сто раз показал — это все чистый HTML
А в MVC человек не может прописать не тоо название в атриуте модели?
видно. куда оно денется
там вообще никак. Но это один из способов имплементации.
можно запрограмировать. Где это встроено в MVC?
древний пример для PHP версии
zippy.com.ua/index.php?p=/Pages/Examples/Example10
Это, как и вышеуказаное, не относится к сути обсуждаемого архитектурного решения. Надо будет сяду и напишу такой компонент для своего фреймворка. С фильтрами блекджеком и юными пррамистками. Пока инлайн редактирование нафиг не нужно было ги в одном проекте…
С чего бы оно путалось? Табличные данные выводят сколько существует HTML — первый раз слышу о проблеме перепутывания заголовков и данных.
ошибка в бизнес логике. В самих линках это когда вы дергаете экген а контроллер не реагирует. и ка тут поможет югит тестинг.
и какие проблемы?
а я сделал чтобы было ее проще.
это словоблудие. я не вызываю никакой слой представления.
Я передаю данные компоненту. Там может быть мильен всякизх слоев а может быть ни одного.
компонент например может ответить аяксом.
Суть компонентов чтобы программист не пудрил себе и другим мозги всякими слоями.
Именно потому что применяю и вижу что оно дебильное.
я трачу намного больше времени чем в WebForms. хотя бы для реализации персистентности.
там где компоненты MVC нечего делать.
У меня есть компонент — он реагирует на клиентское событие серверным обработчиком. Шо тут делать MVC?
Ну запихните MVC в WebForms или наоборот если не понимаете о чем речь.
.
как и в .NET MVC соответстующая ссылка в заголовок.
каким боком тут фильтрация?
CSS3 — 21-ый век за окном
есть компонент который прописывается одной строкой кода.
На клиенте просто Все остальное автоматически — генерация страницы, обработка событий и вынимание сооьвеььсвующей порции данных из источникак данных для грида.
пример из PHP
$detailt = $this->add(new DataView('detail', new DocDataSource(), $this, 'doclistOnRow'));
$this->add(new Paginator('pag', $detailt));
. Это компоненты, сынок.
а что в MVC есть инлайн редактирование?
Впрочем, здесь я могу автоматически вывести таблицу в любыми инпутами и все они автоматически же отправятся на сервер.
Почему дважды? заголовок это верстка — там ничего не надо определять.
Кроме того для чисто текстовых жанных есть еще один компонент который автоматически
рендерит сортировку и пагинацию
не пойму как тут отформатировать
Ед.изм.
Кол.
Цена
они и так независимы. тестируете реакцию одного линка потом другого.
Никакому не нужна если на локале. Всем нужно если нет.
Это именно DTO как бы вы его не называли. Присваиваете данные некоей структуре и отправляете ее менять представление. Как шаблонизатор использует данную структуру сути дела не меняет. Там Inversion of
control у меня DOM модель.
с точки зрения фаната MVC — да.
На работе я програмирую и на WebForms и на MVC — мое решение лучше этого. Все относительно. По крайней мере я могу сравнивать на практике свсе три подхода а просто теоретизировать.
смотря что писать. 2+2=4 ybrfr yt vtyztncz jn yfdjhjxtyjcnb zpsrf/
viewstate там ни причем.
мое предложение сводится к использованию компонентного подхода вместо дебильного MVC.
Он должен быть знаком с поведением контента который он верстает.
Верстальщака интесует не фундаментальность а то что он видит.
Видит HTML тэг или неведомую конструкцию.
ну так ешьте командой.
вы ввобше ничего не увидите и ваш юнит тест будет нае намного полезнее комлексного. Отсюда вопрос а на фига он.
обращение к компоненту. Или по вашему промежуточная структура в виде модели (а точнее не модели а DTO) в MVC меняет суть дела и вы там не обращаетесь к представлению?
считайте что компонент такой же промежуточный слой.
WebForms тоже решал ваши задачи. Более того старый добрый CGI тоже.
я имел ввиду код а не язык. Если вы имеете ввиду что все эти шняги нужно юзать то я не против.
В данном случае я не хотел чтобы код сильно отличался от PHP прототипа. Меньше писать коментов, проще искать ошибки, и все такое. Потому просто переложил с учетом другого синтаксиса.
Да и какая разница как я там написал. Речь о сути идеи и ломке стереотипов. забудьте вы мой код как страшный сон.
пока ни разу не взорвался
верстальщик вообще то когда верстает имеет представление что он верстает и как оно работает.
а как по вашему работает интерфейс на каком нибудь ангуляре где виимость блока прибиндена к тем же радиокнопкам?
какое другое? Ушли данные а не изменилась верстка. Да текст в поле может оказаться разной длины но я не вижу как бывает по другому при других технологиях.
можно было бы конечно выставлять display:none но зачем гонять лишнее.
если у компонента стоит что он невидим шаблонизатор его просто проигнорирует.
В противном случае будет вызван метод render()
и компонент изменит соответствующий ему фронтэнд тэг.