Kohana рамка
В този пост искам да продължа с обсъждането и решаването на проблеми извън линия Kohana. Проблемът е посочено в първото позоваване на решението на незабавен общността (използвайте обратни повиквания) във втория, т.е. в самия код. Тя работи за Kohana 3.2, до 3.3 нужда да редактирате, което нямах нищо против да не е необходимо. Аз проекта 3.2. )
В момента аз съм разработване на проект за Kohana. Този проект не е малка роля, изпълнявана от задачите, изпълнявани от Cron. Дори и без никакъв опит в работата с Cron и Kohana, си мислех, че скриптовете могат да бъдат наречени директно, но проверяват контролера Kohana :: $ is_cli да се определи CLI за повикване. Но както се оказа, има модул с версия 3.0, която се е развила и 3.3 стана част от неизпълнение на доставката Kohana.
Проблемът е, че Kohana 3.3 Направихме някои промени своята автоматично зареждане, което несъмнено е по-удобно. Сега не е нужно да се напише клас само с капитал първо писмо и не е задължително да се обадите на файлове и папки в малки букви. Сега е възможно да се напише така Kohana_CLI. Class_InvalidTask и все пак толкова InvalidTask.php.
За prikrutka модул Любимеца на първо исках да използвам версия 3.2 на който се зарежда в стомашно-чревния тракт на модула Zeelot3k тагове. Но имаше по-ранна рана на 3.1. Той използва Баш скрипт, за да се обадя index.php с параметри, докато в 3.3 фаворит просто обвивка за модула. Изложени решението за 3.2 да ми не работи, поне аз не бях в състояние да стартирате вашата задача.
Първо изброяване лице.
sustems - някои системи.
предпочитания - някои настройки, съкращение за поз
за поз има различни видове, като например създаване на кеша (кеш) и tamauta (изчакване). По този начин за поз може да записва в една таблица с полета номер, стойност, вид, или в два различни маси - prefcache preftimeout и с една и съща структура. Продължавай.
Полета на маса система - ID, име. Изработено в много-към-много през prefs_systems маса с полета: id_system, id_pref, тип (може да бъде взето тук в случай на отделни маси и prefcache preftimeout.
И това е защо за поз таблицата две, искам всеки да направи своя най ORM, т.е. там е основен ORM_Pref простира ORM и от наследени ORM_Prefcache и ORM_Preftimeot. Всеки работи от масата си, и общите настройки на базовия клас.
В този случай, във всяка предписана комуникация ORM $ _has_many. В случай на ORM PREF всички очевидно един рекордни връзки $ _has_many до ORM_System. Това описание е получено такова строителство ORM_System а (досещате, докато писане).