|
|
|
С какими техн.трудностями Вы столкнулись, создавая собств.фреймворк ?
|
|||
|---|---|---|---|
|
#18+
ViPRosВсе совсем наоборот - структура БД выводится из метаданных. Я имел ввиду разницу в подходе. У меня метаданные описывают форму (редактирования, выбора,...) представления данных и работают с уже существующими структурами СУБД В метаданных описывается перечень реквизитов разных типов (число, текст, дата, ссылка, ...), в т.ч. не сохраняемых в БД. В реквизите ссылочного типа (например, ссылка на Номенклатуру) предусмотрено свойство для описания SQL для формы выбора (объясняю упрощенно, в реале несколько сложней). Когда пользователь нажмет кнопку выбора Номенклатуры из справочника, специальный механизм считает все значения реквизитов на форме, передаст эти значения в качестве параметров в СУБД для выполнения сохраненного в свойстве SQL, результат выведется пользователю в виде формы выбора. ViPRosДа, решается. А пример можно? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2017, 15:48 |
|
||
|
С какими техн.трудностями Вы столкнулись, создавая собств.фреймворк ?
|
|||
|---|---|---|---|
|
#18+
sereginseregin Я имел ввиду разницу в подходе. У меня метаданные описывают форму (редактирования, выбора,...) представления данных и работают с уже существующими структурами СУБД редактировать тупо строку таблицы можно в любой IDE для работы с БД начиная с {phpMyAdmin в реале формы намного сложнее. как правило там есть бизнес логика и зачастую нужен определенный дизайн не просто поля ввода столбиком. И шо в таком случае будете делать со своим птичьим языком описания метаданных? Возмите как пример форму ввода приходной накладной из 1С и изобразите своим способом. Вообще не понимаю смысла создавать некое описание метаданных вместо сделать форму в стандартной IDE разработки и описать логику обычным языком програмирования. Если метаданные расчитаны на неких пользаков которые будут описывать формы - то не будут они изучиать никакие матаязыки и что то там городить. Они пригласят разраба а разрабу програмисту никакие наколенные метаданные не нужны ион и так запрограмирует. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2017, 16:10 |
|
||
|
С какими техн.трудностями Вы столкнулись, создавая собств.фреймворк ?
|
|||
|---|---|---|---|
|
#18+
sereginsereginViPRosВсе совсем наоборот - структура БД выводится из метаданных. Я имел ввиду разницу в подходе. У меня метаданные описывают форму (редактирования, выбора,...) представления данных и работают с уже существующими структурами СУБД В метаданных описывается перечень реквизитов разных типов (число, текст, дата, ссылка, ...), в т.ч. не сохраняемых в БД. В реквизите ссылочного типа (например, ссылка на Номенклатуру) предусмотрено свойство для описания SQL для формы выбора (объясняю упрощенно, в реале несколько сложней). Когда пользователь нажмет кнопку выбора Номенклатуры из справочника, специальный механизм считает все значения реквизитов на форме, передаст эти значения в качестве параметров в СУБД для выполнения сохраненного в свойстве SQL, результат выведется пользователю в виде формы выбора. ViPRosДа, решается. А пример можно? То что ты описываешь как раз называется ViewModel - ты ее описываешь, а потом через SQL биндишь в Model (так как ты не знаешь, что и как соответствует в модели (М) модели вью (VM). Все веб Фреймворки и WPF так устроены. А ВИПРОС VM->M биндит сама, так как знает все связи и мощности и т.д. и вычисляет мастер дата по связям. А недостающую информацию либо получает как скрипты валидации и фильтров, либо пользователь выбирает уже из сильно сжатого подмножества данных. Пример, надо вводить Предприятие, Цех, Работник, Количество часов, Дата Если юзер начнет вводить инфу по очереди, то ВИПРОС по введенному (который будет выбран из списка - сначала с кеша, потом с БД с уточнениями по буквам и т.д.) Предприятию предложить цеха только этого предприятия, работников только этого цеха и т.д. Но если будет выбран Работник то Предприятие и Цех будет заполнен автоматически. При этом если в каком либо типе будет Количество часов и Дата, то они автоматом заполнятся (и если информация мощная - безальтернативная и это разрешено, то эти поля нельзя редактировать), или если задан скрипт для умолчания и т.д. то они будут вычисляться и т.д. - допустим просуммируются Количество часов до Даты включительно. Возможно явное указание откуда брать Количество часов и Дата (тогда эти поля могут иметь другие имена). Вощем там много чего интересного - как VM->M делать без программирования. Иногда удобно сделать промежуточные типы (типа SQL View) в модели только в целях упрощения поиска соответствия. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2017, 16:18 |
|
||
|
С какими техн.трудностями Вы столкнулись, создавая собств.фреймворк ?
|
|||
|---|---|---|---|
|
#18+
ViPRosИногда удобно сделать промежуточные типы (типа SQL View) в модели только в целях упрощения поиска соответствия. Это как раз то что ты делаешь в СКЛ скрипте ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2017, 16:27 |
|
||
|
С какими техн.трудностями Вы столкнулись, создавая собств.фреймворк ?
|
|||
|---|---|---|---|
|
#18+
leonmbsв реале формы намного сложнее. как правило там есть бизнес логика и зачастую нужен определенный дизайн не просто поля ввода столбиком. И шо в таком случае будете делать со своим птичьим языком описания метаданных? Возмите как пример форму ввода приходной накладной из 1С и изобразите своим способом. где бизнес-логика? на форме бизнес-логика? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2017, 21:21 |
|
||
|
С какими техн.трудностями Вы столкнулись, создавая собств.фреймворк ?
|
|||
|---|---|---|---|
|
#18+
leonmbsв реале формы намного сложнее. как правило там есть бизнес логика и зачастую нужен определенный дизайн не просто поля ввода столбиком. Пример полноценной формы её реализация QML+SQL Код: javascript 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104. 105. 106. 107. 108. 109. 110. 111. 112. 113. 114. 115. 116. 117. 118. 119. 120. 121. 122. 123. 124. 125. 126. 127. 128. 129. 130. 131. 132. 133. 134. 135. 136. 137. 138. 139. 140. 141. 142. 143. 144. 145. 146. 147. 148. 149. 150. 151. 152. 153. 154. 155. 156. 157. 158. 159. 160. 161. 162. 163. 164. 165. 166. 167. 168. 169. 170. 171. 172. 173. 174. 175. 176. 177. 178. 179. 180. 181. 182. 183. 184. 185. 186. 187. 188. Здесь декларативное описание структуры реквизитов формы и вставки SQL для пересчета данных или сбора данных из базы. leonmbsВообще не понимаю смысла создавать некое описание метаданных вместо сделать форму в стандартной IDE разработки и описать логику обычным языком програмирования. Если метаданные расчитаны на неких пользаков которые будут описывать формы - то не будут они изучиать никакие матаязыки и что то там городить. Они пригласят разраба а разрабу програмисту никакие наколенные метаданные не нужны ион и так запрограмирует. В IDE работать надо с окошками (кнопками, комбобоксами, гридами, флажками) событиями, объектами, операторами. Я же работаю только с объектами (число, текст, дата, ..., таблица) и операторами (SQL вставки). На рисование окошек и обработку событий время не теряю. ViPRos аналогичное решение еще визуальным сделал. Разработчик не отвлекается на код, а глубже вникает в термины безнес-задачи. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2017, 21:22 |
|
||
|
С какими техн.трудностями Вы столкнулись, создавая собств.фреймворк ?
|
|||
|---|---|---|---|
|
#18+
leonmbsВообще не понимаю смысла создавать некое описание метаданных вместо сделать форму в стандартной IDE разработки и описать логику обычным языком програмирования. Как я и говорил, обезьяний труд ценится, ценился и будет ценится, поэтому многим можно не париться ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2017, 21:23 |
|
||
|
С какими техн.трудностями Вы столкнулись, создавая собств.фреймворк ?
|
|||
|---|---|---|---|
|
#18+
sereginsereginViPRos аналогичное решение еще визуальным сделал. Ни разу не аналогичное. Вообще ни в одном месте, ни при каком желании. Вы придумали как слепить описание формы, sql-запросы и логику в одном месте -- как раз то, что весь мир всегда пытался разделить на отдельное представление, отделить логику от способа хранения и обработки данных. На мой взгляд это очень плохое решение, крайне плохое, если только формы не выглядят как некий фасад для SQL-запросов. И то, работая с SQL вместо этих форм, можно выжать гораздо больше и работать в 10 раз эффективнее, чем написание очередного SQL для очередной формы. Это тупик. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2017, 21:27 |
|
||
|
С какими техн.трудностями Вы столкнулись, создавая собств.фреймворк ?
|
|||
|---|---|---|---|
|
#18+
sereginsereginЗдесь декларативное описание структуры реквизитов формы и вставки SQL для пересчета данных или сбора данных из базы. Очень смешно звучит слово «декларативное» на фоне захардкоженных запросов. Ну вы чо? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2017, 21:33 |
|
||
|
С какими техн.трудностями Вы столкнулись, создавая собств.фреймворк ?
|
|||
|---|---|---|---|
|
#18+
Это примерно, как «декларативный» HTML с кусками JavaScript прямо в атрибутах. Декларативнее просто уже некуда ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2017, 21:34 |
|
||
|
С какими техн.трудностями Вы столкнулись, создавая собств.фреймворк ?
|
|||
|---|---|---|---|
|
#18+
sereginsereginРазработчик не отвлекается на код, а глубже вникает в термины безнес-задачи. Попутно ни одного «термина» бизнес-задачи нет тут и с помине, даже не пахнет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2017, 21:35 |
|
||
|
С какими техн.трудностями Вы столкнулись, создавая собств.фреймворк ?
|
|||
|---|---|---|---|
|
#18+
sereginsereginВ IDE работать надо с окошками (кнопками, комбобоксами, гридами, флажками) событиями, объектами, операторами. Я же работаю только с объектами (число, текст, дата, ..., таблица) и операторами (SQL вставки). На рисование окошек и обработку событий время не теряю. Это очень странно, учитывая, что даже в древнем Delphi можно легко и «декларативно» описывать формы кодом без всякого дизайнера, а дизайнер делает ни что иное, как генерит код, который можно написать и руками. Очень много крутого софта в своё время, написано именно без дизайнеров, на генераторах форм на основе какого-то упрощённого языка описания. Но это всё не более чем попытка залить ботву майонезом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2017, 21:37 |
|
||
|
С какими техн.трудностями Вы столкнулись, создавая собств.фреймворк ?
|
|||
|---|---|---|---|
|
#18+
ViPRosИногда удобно сделать промежуточные типы (типа SQL View) в модели только в целях упрощения поиска соответствия. В современном мире, это вовсе не обязательно должна быть SQL View, это read-model, и может быть извлечена откуда угодно, например, из ElasticSearch, что будет по-быстрее и на порядки умнее, чем поиск лайками по SQL, и можно накрутить фасетный поиск, и много чего другого. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2017, 21:41 |
|
||
|
С какими техн.трудностями Вы столкнулись, создавая собств.фреймворк ?
|
|||
|---|---|---|---|
|
#18+
ViPRos ViewModel - ты ее описываешь, а потом через SQL биндишь в Model (так как ты не знаешь, что и как соответствует в модели (М) модели вью (VM). Имена часто не совпадают. Например, есть ViewModel сотрудников с параметром по цеху, есть накладная на перемещение с двумя цехами - Отправителем и Получателем. Связь для выбора сотрудника по цеху автоматически в накладной не сработает, эту связь для реквизитов "Кто (сотрудник) отправил", "Кто (сотрудник) получил" заново прописывать придется. У Вас не было ощущения, что в реальных задачах связи между таблицами хороши для генерации таблиц в БД, а для автозаполнения на формах и ограничения списка выбора эти связи заново прописывать приходится из-за разницы имен? Может я что-то не так понял. Мне кажется, описание связей для БД и Интерфейса похожи, но все таки разные, их не обязательно (возможно не стоит) сваливать в одну метамодель. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2017, 22:10 |
|
||
|
С какими техн.трудностями Вы столкнулись, создавая собств.фреймворк ?
|
|||
|---|---|---|---|
|
#18+
sereginsereginViPRos ViewModel - ты ее описываешь, а потом через SQL биндишь в Model (так как ты не знаешь, что и как соответствует в модели (М) модели вью (VM). Имена часто не совпадают. Например, есть ViewModel сотрудников с параметром по цеху, есть накладная на перемещение с двумя цехами - Отправителем и Получателем. Связь для выбора сотрудника по цеху автоматически в накладной не сработает, эту связь для реквизитов "Кто (сотрудник) отправил", "Кто (сотрудник) получил" заново прописывать придется. У Вас не было ощущения, что в реальных задачах связи между таблицами хороши для генерации таблиц в БД, а для автозаполнения на формах и ограничения списка выбора эти связи заново прописывать приходится из-за разницы имен? Может я что-то не так понял. Мне кажется, описание связей для БД и Интерфейса похожи, но все таки разные, их не обязательно (возможно не стоит) сваливать в одну метамодель. В том то и дело, что ВИПРОС знает, что Роли "Отправитель" и "Получатель" в отношении имеют тип "Цех". Важны типы, роли, контекстные роли,..., вплоть до типов свойств и наименований свойств. Еще как сработает, кроме типов имеются роли типов в отношении, контекстные зависимости и т.д. Голая связь - ничто. В ВИПРОС связь типизирована. Ну, сваливать и не надо. Типы и связи отдельно, а макротипы отдельно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2017, 22:26 |
|
||
|
С какими техн.трудностями Вы столкнулись, создавая собств.фреймворк ?
|
|||
|---|---|---|---|
|
#18+
hVosttViPRosИногда удобно сделать промежуточные типы (типа SQL View) в модели только в целях упрощения поиска соответствия. В современном мире, это вовсе не обязательно должна быть SQL View, это read-model, и может быть извлечена откуда угодно, например, из ElasticSearch, что будет по-быстрее и на порядки умнее, чем поиск лайками по SQL, и можно накрутить фасетный поиск, и много чего другого. Ну я написал - (типа SQL View) для понятности. Естественно, это некая трансформация первичной модели. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2017, 22:27 |
|
||
|
С какими техн.трудностями Вы столкнулись, создавая собств.фреймворк ?
|
|||
|---|---|---|---|
|
#18+
hVosttВы придумали как слепить описание формы, sql-запросы и логику в одном месте -- как раз то, что весь мир всегда пытался разделить на отдельное представление, отделить логику от способа хранения и обработки данных. На мой взгляд это очень плохое решение, крайне плохое, если только формы не выглядят как некий фасад для SQL-запросов. И то, работая с SQL вместо этих форм, можно выжать гораздо больше и работать в 10 раз эффективнее, чем написание очередного SQL для очередной формы. Это тупик. Не спешите с выводами. - Вся логика обработки данных в декларативном ;-) SQL. Вместо SQL можно и другой язык использовать. - Декларативный QML (XML, JSON или как у ViPRos метамодель в БД) необходим для описания структуры формы. Логики в нем нет, кроме последовательности расположения реквизитов, заполнения свойств. В большинстве IDE аналогичный подход - описание формы и скрипты. Только компоненты у меня не окошки (кнопка, бокс, ...), а реквизиты (число, текст, ссылка, ...). Скрипты у меня не события компонентов формы обрабатывают, а данные с формы получают, обрабатывают и возвращают обратно, поэтому SQL в большинстве случаев справляется. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2017, 22:40 |
|
||
|
С какими техн.трудностями Вы столкнулись, создавая собств.фреймворк ?
|
|||
|---|---|---|---|
|
#18+
sereginseregin, Есть например, контекстная зависимость типа "Имеют общего родителя" для Отправитель и Получатель. В таком случае ВИПРОС будет предлагать для Получателя только цеха того предприятия, цехом которого является Отправитель. Работник отправителя будет контекстно зависеть от "Отправитель", а Работник получателя от "Получатель". И так - По введенному Отправитель будет выбирается Работник отправителя, Получатель из того же Предприятия и Работник получателя от Получателя. Если указать Работников то Отправитель и Получатель будет автоматом заполняться. Если где то есть эквивалентное отношение, то запись скопируется из того отношения и т.д. Вощем в этих целях генерируется граф зависимостей, ноды и ребра которого имеют веса для контекстов, есть алгоритмы интерпретации и поиска информации максимальной мощности и т.д. Если в Отношении есть Цех и Работник, то ВИПРОС вычислить отношения, которые содержат ссылку на оба типа, проанализирует уникальность и другие ограничения типов в этих отношениях и идентифицирует то отношение, которое является базовым, определяющим отношением для этих двух типов. Т.е. найдет мастер дата - главную запись. ВИПРОС сама знает - что есть кто есть "справочник" (первичные отношения), а кто "движуха" отношения высших порядков. И как ближе мы к "первичке" так мощнее (корреляция) информация. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2017, 22:43 |
|
||
|
С какими техн.трудностями Вы столкнулись, создавая собств.фреймворк ?
|
|||
|---|---|---|---|
|
#18+
ViPRosВажны типы, роли, контекстные роли,..., вплоть до типов свойств и наименований свойств...роли типов в отношении, контекстные зависимости... связь типизирована....Типы и связи отдельно, а макротипы отдельно. Усе... я спать! Спасибо, что уделили внимание. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2017, 22:48 |
|
||
|
С какими техн.трудностями Вы столкнулись, создавая собств.фреймворк ?
|
|||
|---|---|---|---|
|
#18+
sereginseregin, я не хотел, сам напросился :) мне все это уже надоело порядком, все равно никто не въезжает (кроме Хвоста, кажется) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2017, 22:50 |
|
||
|
С какими техн.трудностями Вы столкнулись, создавая собств.фреймворк ?
|
|||
|---|---|---|---|
|
#18+
ViPRos...ноды и ребра которого имеют веса для контекстов, есть алгоритмы интерпретации и поиска информации максимальной мощности... Это круто... Теперь будет сниться семантическая сеть для подстановки реквизитов... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2017, 22:54 |
|
||
|
С какими техн.трудностями Вы столкнулись, создавая собств.фреймворк ?
|
|||
|---|---|---|---|
|
#18+
sereginsereginViPRos...ноды и ребра которого имеют веса для контекстов, есть алгоритмы интерпретации и поиска информации максимальной мощности... Это круто... Теперь будет сниться семантическая сеть для подстановки реквизитов... она и есть не только для подстановки реквизитов ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2017, 22:57 |
|
||
|
С какими техн.трудностями Вы столкнулись, создавая собств.фреймворк ?
|
|||
|---|---|---|---|
|
#18+
leonmbssereginseregin Я имел ввиду разницу в подходе. У меня метаданные описывают форму (редактирования, выбора,...) представления данных и работают с уже существующими структурами СУБД редактировать тупо строку таблицы можно в любой IDE для работы с БД начиная с {phpMyAdmin в реале формы намного сложнее. как правило там есть бизнес логика и зачастую нужен определенный дизайн не просто поля ввода столбиком. И шо в таком случае будете делать со своим птичьим языком описания метаданных? Возмите как пример форму ввода приходной накладной из 1С и изобразите своим способом. Вообще не понимаю смысла создавать некое описание метаданных вместо сделать форму в стандартной IDE разработки и описать логику обычным языком програмирования. Если метаданные расчитаны на неких пользаков которые будут описывать формы - то не будут они изучиать никакие матаязыки и что то там городить. Они пригласят разраба а разрабу програмисту никакие наколенные метаданные не нужны ион и так запрограмирует.А что мешает к описанию данных добавить элементы разметки? и получить форму любой сложности. Использовать метаданные правильно и потому, что они используется при создании (обновлении) структуры БД. Я, например, добавляю поле, ставлю галку [*] записать в БД, и не парюсь - при установке обновления в БД появится это поле, и индекс, если нужно. Конечно можно это делать в разных местах, но это уже сложности - добавил в структуру, забыл про форму, или наоборот, или типы разные. Или сделал поле со справочниками, а foreign key забыл. А по метаданным можно и индексы в автомате создать, и проверку целостности провести. Мы ведь тут обсуждаем платформы для быстрого создания прикладных систем, но не конечными пользователями, а программистами. Можно и на ассемблере формы клепать, а стоит ли? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2017, 23:12 |
|
||
|
С какими техн.трудностями Вы столкнулись, создавая собств.фреймворк ?
|
|||
|---|---|---|---|
|
#18+
sereginseregin- Вся логика обработки данных в декларативном ;-) SQL. Вместо SQL можно и другой язык использовать. Э.. нет, батенька. SQL это детали реализации по части хранения данных. А если модель начнёт меняться, все формы сломаются нафиг. А если завтра добавится row-level security с просмотром по иерархии зависимостей? Все «декларативные» формы можно выкидывать на помойку. А если логика в одном месте меняется и это должно оказывать влияние на десятки форм? Эти формы тоже летят в урну. Тут нет никакой декларативности, а если уж считать декларативностью SQL, то давайте и всё остальное, C#/Java/Python/etc.. тоже поверх машинных кодов вполне себе «декларативные» языки описания программы. sereginseregin- Декларативный QML (XML, JSON или как у ViPRos метамодель в БД) необходим для описания структуры формы. Логики в нем нет, кроме последовательности расположения реквизитов, заполнения свойств. У ViPRos описывается бизнес модель, в терминах исключительно бизнеса. Никакого SQL, можно посадить аналитика, который понятия не имеет, что и как там в каких базах хранится, каким образом там по таблицам разложено и вообще есть ли там какие-то таблицы знать не знает. Ему это не надо. И формы не надо программировать, настраивать и лепить горбатого, потому что в мета-данных очень много информации, достаточно, чтобы покрывать 80% бизнес-кейсов, а остальные 20% пишутся теми же аналитиками на встраиваемых скриптах, работая с бизнес-объектами высокого уровня. Декларативность это чуть более высокого уровня абстракция, чем написание программы на языке программирования. И на декларативность бизнесу положить. У него есть Заказ, у него есть Склад, есть Товар, есть Клиент. Нет у него никаких форм, формы это лишь выражение для взаимодействия пользователя с системой. Что ближе бизнесу: — сфорировать заказ — открыть форму заказа там-то там-то ? В системах подобных ВИПРОС, первично первое, а второе это лишь сервис, инструмент решения задачи, но не самоцель. У вас же самоцель это какие-то формы, что идёт вразрез с целями автоматизации и решения задач. sereginsereginВ большинстве IDE аналогичный подход - описание формы и скрипты. Только компоненты у меня не окошки (кнопка, бокс, ...), а реквизиты (число, текст, ссылка, ...). Скрипты у меня не события компонентов формы обрабатывают, а данные с формы получают, обрабатывают и возвращают обратно, поэтому SQL в большинстве случаев справляется. Абсолютно те же яйца, только в профиль. Большинство IDE дают максимальную гибкость, если уж на то пошло. У вас всё ограничено только вашими концепциями, шаг влево, шаг вправо -- давай досвидания. Подмена понятий ничего не решает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2017, 23:50 |
|
||
|
|

start [/forum/topic.php?fid=33&msg=39569729&tid=1547255]: |
0ms |
get settings: |
8ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
66ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
58ms |
get tp. blocked users: |
1ms |
| others: | 233ms |
| total: | 399ms |

| 0 / 0 |

Извините, этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
... ля, ля, ля ...