Смешивание Zend и старого процедурного кода - PullRequest
Новая
       13

Смешивание Zend и старого процедурного кода

1 голос
/ 09 июня 2009

У нас есть действительно старая унаследованная кодовая база, которая использует глобальные переменные, как будто они выходят из моды - почти вся межстраничная связь осуществляется через глобальные и сеансовые сеансы или и то, и другое. Это может быть изменено в качестве крайней меры, но в идеале я не хочу касаться его, так как все, к чему я прикасаюсь, может вызвать больше ошибок: -p.

В любом случае, мы включаем в приложение новый «модуль», который был полностью написан на Zend и действительно хорош и модульный. Моя цель - заставить Zend работать в качестве основы, а старый унаследованный код работать как своего рода модуль / контроллер в Zend, и когда у него есть контроль, просто выполняйте его в обычном режиме и делайте что хотите.

У меня есть 2 вопроса:

  • Мне нужно, чтобы Zend увидел, что я использую устаревшие URL (login.php, show.php и т. Д.), И передаю выполнение определенному контроллеру;

  • Я встраиваю целое приложение в функцию другого, и это нарушает поведение переменных по умолчанию, появляющихся в глобальной области видимости как глобальные, то есть теперь они являются просто локальными переменными этого метода и поэтому не могут можно увидеть без предварительного указания, что они глобальные.

Если есть другой способ сделать это, я буду рад это услышать: -p

Приветствия
Chris

Ответы [ 3 ]

2 голосов
/ 09 июня 2009

Для первого выпуска, я думаю, вы можете использовать класс Zend_Router.

Но, тем не менее, я не считаю хорошей идеей перенести процедурное приложение на концепцию ZF, которая является объектно-ориентированной.

Я бы либо переписал приложение, либо просто использовал отдельные классы в качестве свободных компонентов, что также рекомендуется создателями ZF.

1 голос
/ 10 мая 2012

Для устаревших кодовых баз я рекомендую использовать ваши APACHE правила перезаписи . Обычно Zend Framework переписывает в соответствии с: 

  <Location />
        RewriteEngine On
        RewriteCond %{REQUEST_FILENAME} -s [OR]
        RewriteCond %{REQUEST_FILENAME} -l [OR]
        RewriteCond %{REQUEST_FILENAME} -d
        RewriteRule ^.*$ - [NC,L]
        RewriteRule ^.*$ /index.php [NC,L]
    </Location>

Вместо этого замените «index.php» на что-то, что в данный момент не используется, например, «ZendFramework.php». Поместите обычное содержимое (Определите APPLICATION_ENV, APPLICATION_PATH, начальную загрузку и т. Д.) В этот файл ZendFramework.php.

Теперь ваш сервер будет по-прежнему обслуживать весь существующий унаследованный код, как и раньше, но вы перенаправляете несуществующие пути (такие как / module / controller / action) в Zend. В зависимости от вашей унаследованной кодовой базы у вас могут быть некоторые коллизии в путях, вам придется иметь дело с этим, когда вы называете свои модули / контроллеры / актыоны и пользовательские маршруты. Со временем вы можете переместить устаревший код в модули ZendFramework. 

        RewriteRule ^.*$ /ZendFramework.php [NC,L]
0 голосов
/ 10 июня 2009

Оказывается, я был слишком амбициозен;

Я понял, что новый «модуль» был в основном просто JavaScript и небольшим PHP-контроллером (CRUD), подкрепленным массой ZF, и все, что я действительно хотел, чтобы портировать, это интерфейс JS - никого на самом деле не волнует, как обратно конец реализован.

Я решил просто трансплантировать интерфейс JS и просто предоставить интерфейсы, аналогичные описанным ранее, и теперь не нужно беспокоиться о Zend и просто кодировать некоторые альтернативные функции в устаревшем приложении.

Yay.

Странно, я понял это, когда кладу сахар в свою чашку, когда готовлю чашку чая; Вместо того, чтобы переместить ложку в чашку (из сахарной банки и разлить ее повсюду (т. Е. Много кода для переписывания)), переместите их обе над чашкой и удалите сахарную банку снизу - вы получите тот же результат с меньшими затратами беспорядок, сахар был JS, а Jar был большой структурой ZF: -p

...