OberonCore https://forum.oberoncore.ru/ |
|
Обсуждение проекта PureBuilder https://forum.oberoncore.ru/viewtopic.php?f=93&t=3133 |
Страница 3 из 7 |
Автор: | Валерий Лаптев [ Вторник, 11 Январь, 2011 13:47 ] |
Заголовок сообщения: | Re: Обсуждение проекта PureBuilder |
Драконограф писал(а): Валерий Лаптев писал(а): Кстати, мы рассматриваем Дракон в качестве основного кандидата для изображения алгоритмов при обучении начинающих. Даже в программе дисциплины явно написали. При развитии обучающей среды ОБЯЗАТЕЛЬНО включим что-нить на тему дракона в нее. А как Вы относитесь к табличному представлению структуры - типа структурограмм?Пока - никак не отношусь. Просто не знаю подробностей. А по дракону начал просматривать книжки. И судя по просмотренному и прочитанному - весьма полезный инструмент для начинающих. Кроме того, я тут уже как-то отмечал, что существует разница в восприятии алгоритмов мужчинами и женщинами. Женщинам явно удобнее графический вариант (использовались блок-схемы), а пацанам - текстовый. Кроме того, два представления одновременно часто помогают обнаруживать ошибки. |
Автор: | Владислав Жаринов [ Вторник, 11 Январь, 2011 15:07 ] |
Заголовок сообщения: | Re: Обсуждение проекта PureBuilder |
Валерий Лаптев писал(а): ... Полностью согласен - и результаты эксперимента, упомянутого в п. Непрофессиональная визуализация этого примера, подтверждают - девушки разобрались с техноязыком (насколько возможно было в последний момент перед сдачей ) - а вот с псевдокодом, откуда надо было переводить, не так просто оказалось...А по дракону начал просматривать книжки. И суди по просмотренному и прочитанному - всеьма полезный инструмент для начинающих. Кроме того, я тут уже как-то отмечал, что существует разница в восприятии алгоритмов мужчинами и женщинами. Женщинам явно удобнее графический вариант (использовались блок-схемы), а пацанам - текстовый. Кроме того, два представления одновременно часто помогают обнаруживать ошибки. Чтобы был не только для начинающих - конечно совершенствовать надо. Исключения, инварианты, полный параллелизм... как вот тут и даже лучше (с учётом возможной ИТ-профессиональной критики ). Не говоря уже о цикле Дейкстры... |
Автор: | Сергей Прохоренко [ Вторник, 11 Январь, 2011 16:19 ] |
Заголовок сообщения: | Re: Ещё раз о целях и средствах :) |
Драконограф писал(а): какими средствами предлагается укладывать нелинейные структуры на плоскости документа без пересечений? 1) Структурное программирование, т.е. вложенные друг в друга блоки 2) Многоветочные конструкции, похожие на Дракон, но только "линейные" 3) Отбражение разных частей программы (модулей, процедур) на разных вкладках, т.е., по сути, разбиение программы на страницы/слайды 4) Средства автоматического преобразования выделенного кода в инлайновую процедуру, размещаемую на отдельной вкладке |
Автор: | Сергей Прохоренко [ Вторник, 11 Январь, 2011 16:35 ] |
Заголовок сообщения: | Re: Обсуждение проекта PureBuilder |
Драконограф писал(а): ...некоторые парадигмы, наверное, плохо сочетаемы (если не взаимоисключающие) - а некоторые, напротив, хорошо объединяются (где-то однорангово, где-то иерархически). Думаю, что применение той или иной парадигмы должно диктоваться стоящей задачей. При этом вряд ли кто будет интересоваться, сочетаются ли парадигмы друг с другом. Лишь бы не было противоречий в используемом инструментарии. |
Автор: | Сергей Прохоренко [ Вторник, 11 Январь, 2011 16:51 ] |
Заголовок сообщения: | Re: Обсуждение проекта PureBuilder |
Galkov писал(а): Но с какой такой радости, генерируя семантическое дерево (почему не ДАГ?) программы, мы считаем наиболее удобным способом вводить его в "линейном виде с нужными отступами" Кто не дает вводить дерево - именно как дерево ??? Ну типа: узел дерева IF - от него отходят две ветки. Которые в свою очередь... ну Вы в курсе. Представьте себе "инопланетянина", в достаточной степени познавшего Человеческую культуру, и попробуйте ему втолковать Величие Текста с Отступами Если Ваш инопланетянин уже достаточно помучился с многократным нахождением приемлемого варианта расположения блоков на плоскости блок-схемы, с избежанием пересечений линий связей, с вылезанием блок-схемы за видимую область экрана, с впихиванием кода (кое-где прихОдится) и комментариев в границы блока, с разбеганием связанных блоков в противоположные углы экрана, с рябящей в глазах паутиной линий связей, то он уже знает чем текст с отступами удобнее графа для изображения алгоритма. Разумеется, существуют случаи, когда графы удобны, и они применяются в PureBuilder. |
Автор: | Сергей Прохоренко [ Вторник, 11 Январь, 2011 16:54 ] |
Заголовок сообщения: | Re: Обсуждение проекта PureBuilder |
Драконограф писал(а): ...всё равно есть вопросы к логике и физике модели как таковым ... - обеспечение ссылки на разные описания одного и того же по имени. Поясните, что имеется в виду? |
Автор: | Galkov [ Вторник, 11 Январь, 2011 17:09 ] |
Заголовок сообщения: | Re: Обсуждение проекта PureBuilder |
Сергей Прохоренко писал(а): Если Ваш инопланетянин уже достаточно помучился с многократным нахождением приемлемого варианта расположения блоков на плоскости блок-схемы, с избежанием пересечений линий связей, с вылезанием блок-схемы за видимую область экрана, с впихиванием кода (кое-где прихОдится) и комментариев в границы блока, с разбеганием связанных блоков в противоположные углы экрана, с рябящей в глазах паутиной линий связей, то он уже знает чем текст с отступами удобнее графа для изображения алгоритма. 1) Помучился. 2) Еще не понимает. Представьте себе обыкновенную электронику. А тех, кто там работает - "инопланетянами". Так вот, эти "инопланетяне" давно уже намучались "с многократным нахождением приемлемого варианта расположения блоков на плоскости блок-схемы" Наработали свои приемы "расположения"... И фиг ты их заставишь работать в тексте. Лично я пытался их убедить - не получается И ведь что занимательно - нет у них никакого "комбинаторного взрыва", и неиссякаемого потока ошибок, от которых "падают ракеты" Последнее - не аргумент, конечно же... А один из факторов, почему мне не удалось переубедить "инопланетян". Тех, кто рисует "непонятные схемы" - они просто увольняют нафиг с работы, и все Тем более, что "рисовать схемы" они начали еще в до-ИТ-шные времена: у них схема изначально назначалась человеку, а не тупому компьютеру... Т.е., определенная культура наработана уже. Давно, как бы. |
Автор: | Geniepro [ Вторник, 11 Январь, 2011 18:49 ] |
Заголовок сообщения: | Re: Обсуждение проекта PureBuilder |
Galkov писал(а): Представьте себе обыкновенную электронику. А тех, кто там работает - "инопланетянами". Так вот, эти "инопланетяне" давно уже намучались "с многократным нахождением приемлемого варианта расположения блоков на плоскости блок-схемы" Наработали свои приемы "расположения"... И фиг ты их заставишь работать в тексте. Лично я пытался их убедить - не получается Обыкновенная бытовая электроника (ну там детекторный приёмник или даже телевизор) -- возможно. Однако при разработке процессоров и прочих БИСов используют текстовые языки типа VHDL и Verilog. Почему? |
Автор: | Galkov [ Среда, 12 Январь, 2011 06:06 ] |
Заголовок сообщения: | Re: Обсуждение проекта PureBuilder |
Geniepro писал(а): Обыкновенная бытовая электроника (ну там детекторный приёмник или даже телевизор) -- возможно. Возможно даже и компьютер, и космическая станция, и системы наведения ракет.Кстати говоря, аналоговую технику тоже никто не отменял, и чего-то я не припомню удачных попыток упаковать это в БИСы. Но разве в этом дело ??? Дело в том, что если бы мы С НУЛЯ обсуждали чего лучше: текст или схема - это один разговор. Но на самом-то деле все инженеры пользуются "картинкой" уже очень много лет (и не только в электронике). Не специально, чтобы досадить IT-шникам, а просто так сложилось исторически. Без злого умысла. Причем рисовали эти "картинки" еще на кульмане, и тушью на кальке - прикиньте масштаб "мучений с многократным нахождением...". Это говорит о том, что цели, достигаемые "картинкой" (в отличие от текста), много важнее этих как бы "мучений". Последнее, правда - лично моя мысль... В принципе, я никого ни за что не агитирую Ну разве что призываю немного поразмыслить над фактами. Есть парадигма "картинок" - у нее есть результаты после многих лет использования этой парадигмы. Не было бы этих многих лет - не было бы и разговора, наверное. И есть текстовая парадигма - у нее тоже есть уже некоторые как бы результаты. Нет, я не буду делать громкие выводы о причинно-следственных связях Но слов из песни-то не выкинешь... Мне просто интересен этот вопрос. Скажем аргументация "скорописи" - мне известна. Ну типа: я напишу "Hello Word" ровно за 8 секунд, а мышью Вы будете долбиться аж целых двадцать. Известна, и не убеждает. У нас ведь здесь другой случай. Вот я и спросил за аргументацию в этом другом случае... Пока поймал аргумент: нарисовать правильно и понятно - это ТРУД. Согласен - ТРУД. И есть целая область (инженерия), где этим трудом постоянно занимаются. Значительную часть времени. За зарплату. Гипотеза для обсуждения: если этим трудом сознательно не заниматься - "ракеты будут продолжать падать" Geniepro писал(а): Однако при разработке процессоров и прочих БИСов используют текстовые языки типа VHDL и Verilog. Почему? Вообще-то, при разработке "процессоров и прочих БИСов" используют и графические языки - электронные схемы, грубо говоря.Но мне совершенно понятна и причина использования текста. Она ровно такая же, как и у меня, когда я использую ассемблер для AVR вместо ЯВУ. Неадекватность "искусственного интеллекта" при отображении замысла Автора в реальное железо. Был бы ЯВУ, который не режет ресурсы моего железа в несколько раз - и не знал бы я, что такое ассемблер. Ровно так же и в БИСах - есть, наверное, куда использовать ресурсы камня, иначе как на тупость ИИ. Ведь у железячников реальная конкуренция, а не как в софте. Мне пока так кажется... |
Автор: | Владислав Жаринов [ Среда, 12 Январь, 2011 06:06 ] |
Заголовок сообщения: | Re: Обсуждение проекта PureBuilder |
Geniepro писал(а): Galkov писал(а): Представьте себе обыкновенную электронику. А тех, кто там работает - "инопланетянами". Так вот, эти "инопланетяне" давно уже намучались "с многократным нахождением приемлемого варианта расположения блоков на плоскости блок-схемы" Наработали свои приемы "расположения"... И фиг ты их заставишь работать в тексте. Лично я пытался их убедить - не получается Обыкновенная бытовая электроника (ну там детекторный приёмник или даже телевизор) -- возможно. Однако при разработке процессоров и прочих БИСов используют текстовые языки типа VHDL и Verilog. Почему? |
Автор: | Владислав Жаринов [ Среда, 12 Январь, 2011 06:12 ] |
Заголовок сообщения: | Re: Обсуждение проекта PureBuilder |
Сергей Прохоренко писал(а): Драконограф писал(а): ...всё равно есть вопросы к логике и физике модели как таковым ... - обеспечение ссылки на разные описания одного и того же по имени. Поясните, что имеется в виду? |
Автор: | Владислав Жаринов [ Среда, 12 Январь, 2011 06:17 ] |
Заголовок сообщения: | Re: Обсуждение проекта PureBuilder |
Galkov писал(а): Geniepro писал(а): Обыкновенная бытовая электроника (ну там детекторный приёмник или даже телевизор) -- возможно. Возможно даже и компьютер, и космическая станция, и системы наведения ракет.Кстати говоря, аналоговую технику тоже никто не отменял, и чего-то я не припомню удачных попыток упаковать это в БИСы. Но разве в этом дело ??? Дело в том, что если бы мы С НУЛЯ обсуждали чего лучше: текст или схема - это один разговор. Но на самом-то деле все инженеры пользуются "картинкой" уже очень много лет (и не только в электронике). Не специально, чтобы досадить IT-шникам, а просто так сложилось исторически. Без злого умысла. Причем рисовали эти "картинки" еще на кульмане, и тушью на кальке - прикиньте масштаб "мучений с многократным нахождением...". Это говорит о том, что цели, достигаемые "картинкой" (в отличие от текста), много важнее этих как бы "мучений". Последнее, правда - лично моя мысль... В принципе, я никого ни за что не агитирую Ну разве что призываю немного поразмыслить над фактами. Есть парадигма "картинок" - у нее есть результаты после многих лет использования этой парадигмы. Не было бы этих многих лет - не было бы и разговора, наверное. И есть текстовая парадигма - у нее тоже есть уже некоторые как бы результаты. Нет, я не буду делать громкие выводы о причинно-следственных связях Но слов из песни-то не выкинешь... Мне просто интересен этот вопрос. Скажем аргументация "скорописи" - мне известна. Ну типа: я напишу "Hello Word" ровно за 8 секунд, а мышью Вы будете долбиться аж целых двадцать. Известна, и не убеждает. У нас ведь здесь другой случай. Вот я и спросил за аргументацию в этом другом случае... Пока поймал аргумент: нарисовать правильно и понятно - это ТРУД. Согласен - ТРУД. И есть целая область (инженерия), где этим трудом постоянно занимаются. Значительную часть времени. За зарплату. Гипотеза для обсуждения: если этим трудом сознательно не заниматься - "ракеты будут продолжать падать" |
Автор: | Владислав Жаринов [ Среда, 12 Январь, 2011 07:05 ] |
Заголовок сообщения: | Re: Ещё раз о целях и средствах :) |
Сергей Прохоренко писал(а): Драконограф писал(а): какими средствами предлагается укладывать нелинейные структуры на плоскости документа без пересечений? 1) Структурное программирование, т.е. вложенные друг в друга блоки 2) Многоветочные конструкции, похожие на Дракон, но только "линейные" 3) Отбражение разных частей программы (модулей, процедур) на разных вкладках, т.е., по сути, разбиение программы на страницы/слайды 4) Средства автоматического преобразования выделенного кода в инлайновую процедуру, размещаемую на отдельной вкладке 1) Вкладываем то, что имеет один вход и один выход. Так? Или имеется в виду также "областная декомпозиция", описанная в начале этого подпункта? А её как перевести в лиоформу? Если графы (в частности, графит-схемы) Вас не устраивают - не следует ли ввести как альтернативное табличное представление с заменой маршрутной лексики табличной сеткой (структурограмм, развивающих источники в этом сообщении с учётом высказанной там критики)? 2) Что значит линейные в кавычках? А если без кавычек - тогда как обходимся без "выкладки в линию", показанной применительно к шампур-граф-схемам здесь для ветвлений и здесь для циклов (и ещё чуть выше для LOOP-EXIT-END) - т.е. без goto и/или заменителей? Или не обходимся? 3) Разбиение - значит, фрагментарное восприятие. Как собираем - т.е. где "схемы соединений и подключений" содержимого (модулей, процедур)? 4) Имеется в виду то, что в шампур-методе называется подстановкой (см. определение здесь)? И наконец, снова вопрос, составляющий вторую часть исходного поста - как сформировать целостное описание задачи, не сводимое только к программной (программно-строгой) формализации процессов? Вопрос уже решался автоматизированно в разных формах - так, у Агафонова выдвигается концепция ПТО (см. выдержку из этого сообщения), реализованная как редактор "базы знаний ПТО"; рядом в сообщении лежит выдержка из Дубейковского о том, как приспособить IDEF0 в качестве схематизирующего представления НТ-документов; Михайлов в упомянутой здесь книге ставит и реализует в 1С задачу ведения "картотеки предметной области" с возможностью формировать "отчётные документы", искать по образцу и т.п. (п. Помощник писателя в Гл.2; в эту и другие выдержки из книги не вошло; реализации программы были выложены в веб по адресам, указанным в книге - в частности, здесь: http://citycat.ru/iq/ti/). Ну и схематизирующие граф-языки (ГРАФ Гуленкова, ГНОМ Паронджанова). Исходя из графит-метода, предложил и свой язык лист-силуэтов - обоснование см. в этом сообщении. Как видим, дело актуальное. Каковы Ваши предложения? |
Автор: | Сергей Прохоренко [ Среда, 12 Январь, 2011 22:53 ] |
Заголовок сообщения: | Re: Ещё раз о целях и средствах :) |
Прежде всего, по поводу дискуссии о БИСах. Мне тоже нравится смотреть на хорошо сделанные (кем-то другим) графы. Но кто рисовать-то будет? Непроизводительно это и неэффективно с экономической точки зрения. Как учебный пример, чтобы разобраться со сложным местом в алгоритме - пойдет (причем это можно сделать маркером на доске). Отладить одно маленькое критическое приложение "для ракеты" - ну тоже можно. Но как промышленный инструмент - слишком трудоемко и сложно (одних правил построения сколько!, да их еще надо уметь применить). Но я всё равно за графику. Только она должна стать менее трудоемкой и не требующей творческих способностей. Для этого ей придется перестать быть двумерной, вытянуться в вертикальном направлении и стать более автоматизированной. Драконограф писал(а): Сергей Прохоренко писал(а): Драконограф писал(а): какими средствами предлагается укладывать нелинейные структуры на плоскости документа без пересечений? 1) Структурное программирование, т.е. вложенные друг в друга блоки 2) Многоветочные конструкции, похожие на Дракон, но только "линейные" 3) Отбражение разных частей программы (модулей, процедур) на разных вкладках, т.е., по сути, разбиение программы на страницы/слайды 4) Средства автоматического преобразования выделенного кода в инлайновую процедуру, размещаемую на отдельной вкладке 1) Вкладываем то, что имеет один вход и один выход. Так? Да. Драконограф писал(а): Если графы (в частности, графит-схемы) Вас не устраивают - не следует ли ввести как альтернативное табличное представление с заменой маршрутной лексики табличной сеткой (структурограмм, развивающих источники в этом сообщении с учётом высказанной там критики)? Посмотрел. Таблицы - не лучшая форма для наглядного изображения алгоритмов с циклами и ветвлениями. Вот использовать таблицы для объявления и спецификации переменных - другое дело! Драконограф писал(а): 2) ...как обходимся без "выкладки в линию", ... т.е. без goto и/или заменителей? Или не обходимся? Обходимся без goto. Использование brake, continue и т.п. - дискуссионный вопрос (что важнее: скорость или надежность программы?). В принципе, без них можно обходиться. Драконограф писал(а): 3) Разбиение - значит, фрагментарное восприятие. Как собираем - т.е. где "схемы соединений и подключений" содержимого (модулей, процедур)? Восприятие в любом случае фрагментами - голова ведь не ризиновая. А интеграция этих кусочков в единое целое должна происходит на вкладках "модуль" и "проект". Кстати, там как раз должно использоваться изображение в форме графа. Реализация соответствующего интерфейса довольно сложна - ведь проблемы графов никуда не деваются, но форма графа здесь очень хороша для восприятия человеком. Однако изобразить в форме графа только крупноблочную структурную схему гораздо проще и дешевле, чем весь алгоритм. Драконограф писал(а): 4) Имеется в виду то, что в шампур-методе называется подстановкой (см. определение здесь)? Да, только автоматически - парой щелчков мышью. |
Автор: | Илья Ермаков [ Среда, 12 Январь, 2011 23:27 ] |
Заголовок сообщения: | Re: Обсуждение проекта PureBuilder |
Сергей Прохоренко писал(а): Для этого ей придется перестать быть двумерной, вытянуться в вертикальном направлении и стать более автоматизированной. Так это - текст В каком-то... будущем, широком смысле слова, как линейная последовательность объектов. Прообраз "будущего широкого смысла" - составной документ... Видимо... Мне кажется, что цепляние за диалогово-оконно-пиктограммное представление для Ваших идей - цепляние за прошлое. Правда, и как сделать в новой парадигме, представить трудно, ввиду только начала "новой парадигмы". Возможно, именно потом, в результате развития двух веток - семантического редактора на традиционном интерфейсе и простого текста-как-интерфейса, сформулируется новый вид - какой-то метатекст, что ли.. |
Автор: | Илья Ермаков [ Среда, 12 Январь, 2011 23:28 ] |
Заголовок сообщения: | Re: Ещё раз о целях и средствах :) |
Сергей Прохоренко писал(а): Обходимся без goto. Использование brake, continue и т.п. - дискуссионный вопрос (что важнее: скорость или надежность программы?). В принципе, без них можно обходиться. Тут у Вас не совсем верное противопоставление. Скорости программе break и continue не добавляют. Для редких случаев нужен общий LOOP-EXIT, а простой break нужен только тем, что не умеет циклы писать... |
Автор: | Валерий Лаптев [ Четверг, 13 Январь, 2011 02:06 ] |
Заголовок сообщения: | Re: Ещё раз о целях и средствах :) |
Илья Ермаков писал(а): Сергей Прохоренко писал(а): Обходимся без goto. Использование brake, continue и т.п. - дискуссионный вопрос (что важнее: скорость или надежность программы?). В принципе, без них можно обходиться. Тут у Вас не совсем верное противопоставление. Скорости программе break и continue не добавляют. Для редких случаев нужен общий LOOP-EXIT, а простой break нужен только тем, что не умеет циклы писать... Совершенно согласен. Сколько раз, пися циклы на С/С++ попадал в ситуацию, что хочется поставить break или continue. Это для меня сигнал - надо поискать более простую организацию цикла - чтобы не было подобных переходов. И такая более простая схема всегда нахОдится... |
Автор: | Владислав Жаринов [ Четверг, 13 Январь, 2011 08:11 ] |
Заголовок сообщения: | Re: Ещё раз о целях и средствах :) |
Сергей Прохоренко в viewtopic.php?p=57512#p57512 писал(а): Драконограф писал(а): По пунктам: ... ... Об остальном см. следующее сообщение. |
Автор: | Владислав Жаринов [ Четверг, 13 Январь, 2011 08:48 ] |
Заголовок сообщения: | Re: Обсуждение проекта PureBuilder |
Илья Ермаков писал(а): Сергей Прохоренко писал(а): Для этого ей придется перестать быть двумерной, вытянуться в вертикальном направлении и стать более автоматизированной. Так это - текст В каком-то... будущем, широком смысле слова, как линейная последовательность объектов. Прообраз "будущего широкого смысла" - составной документ... Видимо... Тогда как двойственность формы представления описаний - текстовая и "графитная" - снимает эти вопросы участники (и даже один и тот же участник) процесса формализации попременно пользуются этими представлениями. И насчёт составления документов - нужен язык структурирования самого проекта (как документа среды, несущего тот самый "широкий смысл" - т.е. полный "паспорт задачи/предметки", как говорилось в этом сообщении) - о чём говорил во второй части этого сообщения. |
Автор: | Владислав Жаринов [ Четверг, 13 Январь, 2011 09:00 ] |
Заголовок сообщения: | О позициях создателей средств формализации |
Сергей Прохоренко писал(а): Прежде всего, по поводу дискуссии о БИСах. Мне тоже нравится смотреть на хорошо сделанные (кем-то другим) графы. Но кто рисовать-то будет? Непроизводительно это и неэффективно с экономической точки зрения. Как учебный пример, чтобы разобраться со сложным местом в алгоритме - пойдет (причем это можно сделать маркером на доске). Отладить одно маленькое критическое приложение "для ракеты" - ну тоже можно. Но как промышленный инструмент - слишком трудоемко и сложно (одних правил построения сколько!, да их еще надо уметь применить). В том-то и штука - о чём говорилось в этом посте - в формализации некорректно говорить об отдельных процессах творения и отчуждения - это части двуединого процесса. Просто у кого-то он протекает преимущественно на базе текстового представления - и ему кажется естественным реализовать поддержку именно такого процесса. Но если реализация не "утилитарная" - то он фактически предписывает каждому её пользователю работать также - т.е. согласно ИП-концепции "скрытого диалога" говорит ему "через время, через расстоянья": "- Слышь, мужик, вот так делать надо... Почему? А потому, что мне так удобнее эти дела править! Dixi." Но я всё равно за графику. Только она должна стать менее трудоемкой и не требующей творческих способностей. Для этого ей придется перестать быть двумерной, вытянуться в вертикальном направлении и стать более автоматизированной. Чтобы не уподобляться субъекту, стиль мышления которого я продемонстрировал этой прямой речью , я и предлагаю поддерживать в среде два представления каждой структуры отчуждённого знания. И тогда один человек-сочинитель выстраивает в форме текста (и по правилам текстования структур), а другой в "графитной" форме (и по правилам графитизации) - кому как удобнее. А предметная (машинно-информатизованная) форма (в БД проектов), ессно, одна и та же - просто "вьюшки" от неё строятся разные. И так же поступают читатели - выбирают для конкретных проектов/проектных сущностей (выделяемых правилами языка представления сущностей данной категории) одну или другую форму просмотра. |
Страница 3 из 7 | Часовой пояс: UTC + 3 часа |
Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/ |