Sep 01

Не спится. Сижу пишу scaffolding для Zend Framework. Возникла проблема - для того, чтобы реализовать полноценное редактирование/удаление записей в таблице нужно добавить к стандартному классу Zend_Db_Table_Row одну public-функцию. Вот теперь сижу и думаю - насколько “правильно” будет просто открыть файл с этим классом и дописать функцию по сравнению с порождением подклассов.

С точки зрения проектировщика - этого делать не стоит. лучше породить подкласс. Но в данном случае прийдется порождать подкласс не только от Zend_Db_Table_Row, но и от Zend_Db_Table, а может и еще чего-то. Чего делать ну вообще не хочется - там кода писать абсолютно тупого - ну просто дофига (возможно я преувеличиваю немного, но все же…).

Чтобы вы делали в моем случае?

Да… Все больше и больше понимаю “недоразвитость” PHP. Если уж делать язык динамически типизированным и объектно-ориентированным - почему нельзя было сделать это нормально? Примеры “нормальных” языков в этом плане привести несложно - Python, Ruby, JavaScript.

В питоне такое “добавление” метода к классу решалось бы так:

def some_name(self):
    ...
Class.new_func = some_name

В JavaScript и того легче:

Class.new_func = function() {...}

А в PHP… Эх…

written by fxposter \\ tags: , , ,


25 Responses to ““Динамический” PHP”

  1. 1. DM Says:

    Я бы отнаследовал и добавил в него. Ведь рано или поздно ZF будет обновляться, и тогда все эти изменения в ядре вылезут боком. Да и как пример тушка ZF может совместно использоваться для кучи (несвоих?) проектов, и тогда такое поведение чревато.

  2. 2. DM Says:

    ЗЫ: сейчас посмотреть не могу, но скорее всего у Zend_Db_Table_Row есть интерфейс и/или абстрактный класс, от которого он наследует.

  3. 3. FX Poster Says:

    Тут прикол в том, что Zend_Db_Table возвращает ВО ВСЕХ ФУНКЦИЯХ, которые что-то выбирают именно Zend_Db_Table_Row. Т.е. прийдется переписывать все эти функции.

    Насчет выльется боком. Нужно добавить public-функцию getPrimaryKey. Там уже есть одна такая, только protected. Можно изменить ее на public, но суть вопроса остается – менять чуть-чуть в ядре, или дофига, но не касаясь ядра.

  4. 4. Sam Says:

    Лучше не касаясь…

    p.s. я слез с CakePHP и опять пытаюсь сесть на Zend. Знакомство с CakePHP пошло на пользу, но из-за его поддержки php4 и отсутсвия внятных доков работать невозможно…

  5. 5. FX Poster Says:

    Хех… А я предупреждал! :)

  6. 6. Sam Says:

    Ну, ковыряние Cake-а пошло на пользу. Буду расширять функционал Zend-а.

  7. 7. FX Poster Says:

    Ну давай, только писать о своих наработках не забывай ;)

  8. 8. SM Says:

    Это очень легко, на самом деле :)
    Просто расширьте класс Zend_Db_Table_Row своим и в классах Тейбл указать его :)
    Вот пример из конфига

    class Bugs extends Zend_Db_Table_Abstract
    {
        protected $_name = ‘bugs’;
        protected $_rowClass = ‘MyLoggingRow’;
    }
    
    class Products extends Zend_Db_Table_Abstract
    {
        protected $_name = ‘products’;
        protected $_rowClass = ‘MyLoggingRow’;
    }

    Или переопределить для всей БД если используется Zend_Db_Table::setRowClass
    В общем это очень просто ;)

  9. 9. FX Poster Says:
    1. В доках нигде такой фигни я не нашел. Потом уже, когда полез копаться в коды – обнаружил.
    2. Ты забыл о Zend_Db_Table_Rowset, который Zend_Db_Table_Row тоже юзает. И вот так потом вылазят в программах баги.
  10. 10. Sam Says:

    Есть в доках. Читай внимательней.
    Вообще Rowset не обязательно расширять.

  11. 11. FX Poster Says:

    Ммм. Если мы будем что-то fetch’ить не по id, то нам нужно будет с Rowset’ом работать, который нам будет подсовывать Zend_Db_Table_Row.
    Про доки – я-то нашел, откуда это. Но вот почему-то не помню такого, когда писал этот пост. Хотя может просто просмотрел.

  12. 12. Sam Says:

    Нет. Не будет. Будет подсовывать ровно то, что укажем в расширении Zend_Db_Table_Abstract.

  13. 13. FX Poster Says:

    С какой это стати? Не передается _rowClass от Table’а в Rowset.

    Проверить сейчас, правда, не могу.

  14. 14. Sam Says:

    Проверь ;)

    
    class Posts extends Zend_Db_Table_Abstract {
    	protected $name = 'posts';
    	protected $rowClass = 'Post';
    	protected $_primary = 'post_id';
    }
  15. 15. FX Poster Says:

    Мне таблицы влом делать щас. Как только сделаю – сразу проверю. В кодах передачи от Table к Rowset _rowClass’а я не увидел.

  16. 16. Andrey P Says:

    еще раз убеждаюсь что Zend Framework – это грабли…

  17. 17. FX Poster Says:

    Ну значит я не видел в PHP граблей красивее :)

  18. 18. Andrey P Says:

    symfony? LIMB?

  19. 19. FX Poster Says:

    Не знаю, что такое LIMB. Но по качеству кода ZF гораздо лучше той же симфонии.

  20. 20. Andrey P Says:

    limb-project.com
    А как вы измеряли качество кода?

  21. 21. FX Poster Says:

    Нашел уже. :)

    Для начала – не нужно мне “выкать”. Давай на “ты”.

    Качественный код, на самом деле, видно издалека, даже не вдаваясь в подробности реализации – оцени, например, Zend_Controller как проектировщик. Я лучше еще не видел.

  22. 22. Andrey P Says:

    ИМХО. Front Controller я сделал бы через FilterChain….. да и Router в контроллере не по мне…
    ЗЫ. Не буду спорить что Symfony круче ZFW, но она мне понравилась больше из расмотренных мною 4 FW’ов

  23. 23. FX Poster Says:

    Смотря для чего.

  24. 24. Andrey P Says:

    Framework – для меня нужен для быстрой разработки приложений и последующей развёртки на сервере.
    ZFW как библиотека ну уж очень тормазнутая она получается…

  25. 25. FX Poster Says:

    Я юзал для работы с POP3 – очень даже удобно.

Leave a Reply