нет не отключил, спасибо за совет...
страшно за расширяемость в дальнейшем А это уже от конечной реализации зависит. Несколько дочерних классов от modResource вполне уживаются в одной таблице, хотя и поведение конечных объектов может местами сильно отличаться.
CMPGenerator крутая штука когда связей минимум, он связи вроде не генерирует Да, связи не генерирует, приходится вручную прописывать. Но не вижу особой разницы между ручным прописыванием в XML и в уже конечный мап-файл. Хотя каждому свое. Все-таки да, перед глазами все видеть - хорошая штука. Было бы круто накидать визуальный редактор схем, типа как в редакторе phpMyAdmin, автоматизация тут просматривается :) Недвига... О да, там связей и параметров хватает... Я вон http://www.aska-realty.ru/ программировал, насмотрелся. Давно убедился - крупные проекты только вручную все, и только хардкод. Там одними готовыми решениями не обойтись.
Да, модели у вас разные, но вы тогда пытаетесь совместить несовместимое. У вас разные объекты, но пытаетесь вы их наследовать от одного класса, еще и таблицы разные используете... Я бы все-таки создал общую таблицу со всеми уникальными полями и рулил свойством class_key различные типы объектов. c 1 общей таблицей , страшно за расширяемость в дальнейшем
Понятно почему не сохранялся код. Теги вырезаются методом strip_tags(), только разрешенные проходят, то есть используется метод "что не разрешено - то запрещено". Теги из вашего XML-а не были в списке разрешенных. Добавил. Потом механизм поменяем на принцип "что не запрещено - то разрешено". мелочи такие а мозг затрахивают)) CMPGenerator крутая штука когда связей минимум, он связи вроде не генерирует, XML тоже неплох когда нужно видеть все и сразу в одном файле, потом просто распарсить схему, вот сейчас более 500 строк схемы в том числе конструктор планировок(зем уч-> строение(тип стен,материал крыши) -> помещения внутри(кв/м,тип ремонта,пол,потолок)/снаружи(балкон,терраса,виранда,мансарда) -> оборудование/комфорт ) и все поля типов ссылаются на одну таблицу с терминами и типами, там даже ссылка планируется на wiki описание, эксперементирую с компонентом недвижимости, там опись объектов(недвижимости) дикая , можно было конечно просто в поле description/content задать описание квартиры/зем.участка и т.д, делаю ориентируясь на автоматику , чтобы и выборка по критериям была мощной , а критериев уже не мало
Понятно почему не сохранялся код. Теги вырезаются методом strip_tags(), только разрешенные проходят, то есть используется метод "что не разрешено - то запрещено". Теги из вашего XML-а не были в списке разрешенных. Добавил. Потом механизм поменяем на принцип "что не запрещено - то разрешено". Кстати, советую вообще XML-описание модели не использовать. Создаете таблицы в базе данных и генерите модель пакетом CMPGenerator. Гораздо рульней получается. Да, модели у вас разные, но вы тогда пытаетесь совместить несовместимое. У вас разные объекты, но пытаетесь вы их наследовать от одного класса, еще и таблицы разные используете... Я бы все-таки создал общую таблицу со всеми уникальными полями и рулил свойством class_key различные типы объектов.
Спасибо за ответы, Пример кода тут скорее видно зачем разные таблици, просто опись полей разная , вот в чем дело, а таким путем ходим только потому что хотим централизованную таблицу, все же возможные вариации полей не всунеш в один gxBox, на деле полей более 30 только у центрального класса , у производных от 15 полей, все это дело должно иметь одну уникальную строку
Выложите код на http://gist.github.com/
А зачем вам разные таблицы? И наследовать надо последовательно, а не два разных класса от одного родителя.