ltc>Один из серьезнейших недостатков подобного подхода это отсутствие "инкрементальности".
ltc>Я считаю, что можно было бы данный недостаток побороть, используя автоматический мерж. Только мержить надо не плейн-текст, а синтаксические деревья. Причем не абстрактные, а конкретные, чтобы все форматирование сохранилось.
partial class не зря же придуманы.
в winforms вроде всё неплохо решено — в автоматически генерируемые *.designer.cs лезть никакой нужды нет.
я бы к аналогу этого стремился.
Здравствуйте, L_G, Вы писали:
ltc>>Один из серьезнейших недостатков подобного подхода это отсутствие "инкрементальности".
ltc>>Я считаю, что можно было бы данный недостаток побороть, используя автоматический мерж. Только мержить надо не плейн-текст, а синтаксические деревья. Причем не абстрактные, а конкретные, чтобы все форматирование сохранилось.
L_G>partial class не зря же придуманы.
А чем бы они помогли? Вот генератор создал что-то, функционирующий набросок UI. Теперь я хочу его адаптировать по своему вкусу, что-то поправить. А потом средствами того же генератора учесть обновления в модели.
L_G>в winforms вроде всё неплохо решено — в автоматически генерируемые *.designer.cs лезть никакой нужды нет.
Не, там другое, там же практически взаимнооднозначная конвертация получается. Это просто два представления одного и того же.
Здравствуйте, ltc, Вы писали: ltc>Хм. Я, видимо, недостаточно въехал в контекст. ltc>Если формочки постоянно правятся без изменения схемы базы данных, то почем нельзя относиться к ним как к обычным данным (коими они и являются в таком случае)?
Потому что жизненный цикл учётных данных и жизненный цикл формочек отличаются. Ваш К.О. ltc>Если нам важна история данных — то не апдейтим, а инсертим, по дефолту используем последнее добавленное. В таком случае откат на любое предыдущее состояние тривиален.
Ну вот, вы уже начинаете изобретать тот тулчейн, который ведущие компании писали тридцать и более лет. Все вот эти blame, merge, branch, и прочие code review. В теории так можно сделать. Но тогда вы получите ровно то же программирование форм, вид сбоку. Зачем?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, MadHuman, Вы писали:
MH>по сути конфигурирование можно сравнить с использованием специального DSL, скрывающего муду и сложность для типовых задач.
И вот как то так получилось, что графические DSL все померли, остались только текстовые. Например XAML или HTML
MH>>по сути конфигурирование можно сравнить с использованием специального DSL, скрывающего муду и сложность для типовых задач.
НС>И вот как то так получилось, что графические DSL все померли, остались только текстовые. Например XAML или HTML
Я бы не был столь категоричен к примеру графические конструкторы сайтов бурно плодятся и развиваются, по сути в итоге рождая html на основе накликанных и сконфигурённых энд-юзером высокоуровневых блоков.
Нельзя говорить что что-то однозначно всегда лучше, панацей небывает.
И тот и иной подход имеет смысл, важно понимать когда. Вообщем как и с любой другой технологией, важно понимать рамки её применимости и бонусы и недостатки.
Здравствуйте, MadHuman, Вы писали:
НС>>И вот как то так получилось, что графические DSL все померли, остались только текстовые. Например XAML или HTML MH>Я бы не был столь категоричен к примеру графические конструкторы сайтов бурно плодятся и развиваются, по сути в итоге рождая html на основе накликанных и сконфигурённых энд-юзером высокоуровневых блоков.
Только реальное применение всех этих конструкторов ограничивается сайтами-визитками.
ltc>А чем бы они помогли? Вот генератор создал что-то, функционирующий набросок UI. Теперь я хочу его адаптировать по своему вкусу, что-то поправить. А потом средствами того же генератора учесть обновления в модели.
Например, в генерируемом коде, возможно, описываются классы и в любом случае создаются экземпляры объектов. Свойства им назначаются по-минимуму (например, координаты для контролов на форме). Твои поправки (в отдельном файле) — это только изменение их свойств (например, корректировка размеров и расположения контролов, добавление обработчиков событий), но не их создание.
ltc>Не, там другое, там же практически взаимнооднозначная конвертация получается. Это просто два представления одного и того же.
я про разделение кода формы на пару файлов — полностью генерируемый (form1.designer.cs) и редактируемый программистом (form1.cs)
Здравствуйте, Sinclair, Вы писали:
S>Фокус разработки usable софта переместился сначала в веб, потом в мобилки. На десктопе мы безнадёжно застряли в девяностых.
На самом деле 90-е были не так уж плохи в плане юзабилити...
Здравствуйте, Sinclair, Вы писали:
ltc>>Если нам важна история данных — то не апдейтим, а инсертим, по дефолту используем последнее добавленное. В таком случае откат на любое предыдущее состояние тривиален. S>Ну вот, вы уже начинаете изобретать тот тулчейн, который ведущие компании писали тридцать и более лет. Все вот эти blame, merge, branch, и прочие code review. S>В теории так можно сделать. Но тогда вы получите ровно то же программирование форм, вид сбоку. Зачем?
Я в данном треде не утверждаю, что это правильный путь. Просто отметил, что при желании вопросы с версионностью, восстановлением и т.д. технически разрешимы.
Здравствуйте, ltc, Вы писали:
ltc>Я в данном треде не утверждаю, что это правильный путь. Просто отметил, что при желании вопросы с версионностью, восстановлением и т.д. технически разрешимы.
У нас чувак делал простой список изменения MS SQL процедур, с возможностью посмотреть diff (примерно как на RSDN версии редактирования).
Здравствуйте, Shmj, Вы писали:
S>У нас чувак делал простой список изменения MS SQL процедур, с возможностью посмотреть diff (примерно как на RSDN версии редактирования).
Здравствуйте, Kolesiki, Вы писали:
Y>>В будущем огромный пласт программистов средней руки исчезнет K> Эх, мечтатели!... Вы прям как те ЛИСПеры с горящими глазами, каких-то 30 лет назад предсказывающие ровно такой же "коллапс посредственностей". А воз? Он и ныне там.
Воз уже не там. Уже большой пласт отделился, стали конфигураторами 1C, а не программистами. На рынке труда не мало такой работы.
Здравствуйте, Sinclair, Вы писали:
MH>>по сути конфигурирование можно сравнить с использованием специального DSL, скрывающего муду и сложность для типовых задач. S>Ну, так современное программирование гуя — это оно и есть. Если мы отбросим бредовые идеи "создавать ГУИ по схеме данных" и "хранить описание ГУИ в СУБД", то останется совершенно нормальное программирование на обычном современном языке.
Прорыв в автоматизации такой работы случится, ИМХО, после того как появится эффективный промежуточный уровень — схема данных для пользователя, по которому автоматически строится GUI, с кастомизацией.
И решатся проблемы синхронизации серверной и пользовательской схемы данных при изменениях. Проблемы с производительностью, когда данные проходят через этот промежуточный уровень в обе стороны.
И проблемы написания логики, то ли в БД то ли в этой пользовательской схеме.
Возможно, с новым специализированным ЯП для этого.
По сложности правильно сделать этот промежуточный уровень не меньше чем создать сам SQL Server, или больше (всякие EntityFramework это пока баловство).
Но рано или поздно, оно точно постепенно появится.
MH>>ну как же, 1с вполне нормальная платформа для учетных решений. хотя я и не являюсь их сторонником, но справедливости ради. S>1с — то же самое, вид сбоку. Для 90х — офигенная штука. С точки зрения юзабилити — твёрдые 3 с минусом.
И все таки 1C — конфигураторщики отобрали много работы у тех кто врукопашную все делает. Уже очень большая ниша когда выгоднее использовать такое решение.