Все новое-хорошо забытое старое.
Что было , то вновь будет.
Ничто не ново под луной"...

Наши друзья за кордоном - большие мастера придумывать новенькие словечки и понятия. Каждый раз после такого новенького словечка возникает какой то шум, но потом, чаще всего куда то рассасывается. Вот и FrameWork.

Каждый, кто поработал с Foxpro побольше годика и сделал более одного проекта вольно или невольно, зная или не зная, использует этот самый сруб или остов. По сути - это метод построений приложения , который позволяет ускорить их изготовление.

Вот написали Вы первый проект, долго корпели с классами , формами и прочее. Кое-что и не пригодилось, что-то прошло как НИР, ради собственного любопытства. Вот следующий проект. Каков бы он ни был, как бы ни был различен заказчик, что-то да возьмешь из предыдущей разработки. Постепенно у каждого программиста нарабатывается свой конструктор. Все это похоже на крупнопанельное или монолитно-бетонное домостроение. Ставят каркас и быстро обкладывают его плитами или кирпичом. Некоторые программисты идут дальше и пишут приложение, позволяющее автоматизировать доставание нужных деталей из конструктора.

Например, если из DataEnvironment на форму потащить поле, к нему присоединиться нужный ControlSource, если всю таблицу-появиться Grid c нужным RecordSource.

Я бы выделил три группы остовов:

Первый нам дает Microsoft с 6-ой версией. Там есть базовый проект с базовыми же классами. Там-то и найдете класс _frammewk. Если его взять для своей работы - много толку не будет. Проект слабо документирован, некоторые вещи работают дико. Например, таймер вечно что-то выделывает, что его никто не просил делать. Особенно чудно он ведет в частной сессии данных. Вечно перебивает Ваши установки. Тем не менее этот проект весьма полезен , как учебный материал, чтобы по его образцу подобрать свой конструктор.

Второй тип почти не известен в нашей стране. Это готовые, написанные на Foxpro-же, конструкторы . Их не менее 10 штук. Например, FOXEXPRESS, FOXFIRE . Есть специальные , заточенные под их западную бухгалтерию конструкторы вроде Fox Account и прочее и прочее ... Они хороши тем, что внешний вид создаваемых с ними форм очень профессионален. Основные трудности при работе с ними, как сделать что-то не по стандарту. Стоят такие конструкторы сравнимо с самим Foxpro и хорошо защищены. У нас в стране дорогие заказчики или много заказов встречаются редко. А для выполнения одного мелкого заказа их покупка, как правило, нерентабельна. Если там у них нанимают программиста на работу не с самим Foxpro, а с таким конструктором, работа, как правило, оплачивается дешевле. Считается, что программист должен освоить только работу с конструктором и работать там, как обезьяна. Некоторое исследование показывает, что на самом деле дело обстоит не совсем так. Оказывается , что программист работающий с таким конструктором вечно натыкается на какие то недоделки. Зарубежные Foxpro-сайты завалены сотнями вопросов, о том, как сделать какую нибудь пустяковую вещь в FOXFIRE , типа желательного поведения комбобокса.

Наконец, третий тип, это наши с вами самодельные заготовки. В них я бы выделил следующую основную диллему. Как далеко заходить в процессе автоматизации и детализации конструктора и насколько свободными оставить себе руки для ручной работы? Чем универсальнее конструктор - тем быстрее делаешь проект. Но тем труднее делать маленькие отклонения от стандартной методики. Действительно, если автомат уж слишком умен, он начинает жить своей жизнью и не дает просто так в нее вмешиваться. У нас в фирме было две попытки уйти от стандартного разработанного набора типовых классов к автоматизации разработки на базе этих классов. Особенно хотелось это сделать для универсальной разработки файл-сервер, клиент сервер. Ну действительно, простые клиент-серверные формы делались за несколько минут. Особое впечатление это всегда производит на начальство. У него возникает иллюзия, что всю работу они могут сделать сами, просто двигая по экрану мышью и ставя нужные кубики в нужное место. Но как только на формы, постороенные автоматом, нужно было добавить какой нибудь переключатель, вроде комбобокса или оптионгруп или какую либо мелочь, тут начиналась кровавая бойня, как скрестить коня и трепетную лань - код, сделанный автоматом и свой. Ой не всегда это выходило сделать, а если и выходило, то результирующий код был крив, как никогда и походил на попытки барона Мюнхаузена вытянуть себя за волосы на луну.

Так что, конечно - "Да здравствует автоматизация процесса разработки", но существуют еще объективные причины, за что программистам еще можно платить зарплату, и при наличии автомата. Ведь пирожок с улицы от автомата не сравнишь с домашней выпечкой. Ширпотреб должен сочетаться с ручными гобеленами.