Распространение небольшого PHP-приложения - PullRequest
7 голосов
/ 12 ноября 2008

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

Вкратце: это простой инструмент, который позволяет людям загружать файлы после входа в систему с паролем.

Итак, мои вопросы:

1) Как мне обращаться со значениями конфигурации? Я не использую базу данных, поэтому файл конфигурации кажется подходящим. Я знаю, что другие php-приложения (например, Wordpress) используют определения, но они носят глобальный характер, и существует вероятность того, что имена будут конфликтовать. (Глобальные переменные также имеют ту же проблему, очевидно.) Я посмотрел на механизм файлов ini, встроенный в PHP. Это позволяет только комментарии вверху - так что вы не можете легко аннотировать каждый параметр - и вы не можете проверить синтаксис с "php -f". Другие варианты?

2) Как обращаться с шаблонами? Приложение должно откачать форму. Возможно с сообщением об ошибке. (например, «Извините, неверный пароль.») У меня есть переменная класса с формой HTML, но я также могу использовать внешний файл шаблона (указанный в конфигурации). Я делаю простой поиск и замену - например, % SCRIPT% к имени скрипта,% STATUS% для хранения сообщения об ошибке. Это немного похоже на изобретение колеса, но использование системы шаблонов, такой как Smarty, является излишним. (Плюс у них уже может быть система шаблонов.) Другие варианты?

3) i18n - есть только 3 строки сообщений, и gettext, похоже, не установлен повсеместно. Это такая плохая идея, просто сделать эти три параметра строки в файле конфигурации?

4) Как лучше интегрироваться с другими фреймворками? Мое приложение - один класс. Итак, я подумал, что могу просто включить скрипт php, который показывает, как вызывается класс. Это было бы отправной точкой для людей, которые должны были интегрировать ее в другую среду, но также было бы хорошо для тех, кто не заинтересован в настройке. Разумные

5) Параметры GET / POST - это плохая форма для того, чтобы класс смотрел на $ _GET и $ _POST? Должны ли все значения передаваться в мой класс во время строительства?

Спасибо.

Ответы [ 3 ]

7 голосов
/ 12 ноября 2008

Конфигурация

Вы можете использовать php-файл следующим образом:

<?php
return array(
  'option1' =&gt; 'foobar',
  'option2' =&gt; 123,
  //and so on...
  );
?>

А в основном классе просто используйте:

$config = (array) include 'path/to/config/file';

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

1011 * Шаблонирование * Для такого простого применения описанного вами метода должно быть достаточно. Помните, что вы всегда можете расширить ваш класс и перегрузить ваш метод вывода своим собственным. I10N

Как уже упоминалось ранее, для 3-х переменных что-либо большее, чем их сохранение в качестве конфигурации, просто излишне.

Интеграция

Прокомментируйте каждый публичный метод (или даже лучше, также защищенный и приватный) с пояснениями, что они делают и какие параметры необходимы. Если вы объедините это с примером, этого будет достаточно для большинства пользователей.

ПОЛУЧИТЕ против ПОЧТЫ

Ваш класс использует пароли, и вы даже думаете об их отправке через GET? ;) Подумайте об истории браузера, заголовках рефереров и т. Д. Там будут видны пароли ваших пользователей.

2 голосов
/ 13 ноября 2008

В дополнение к доброму совету Кшиштофа:

  • Использовать <?php только
  • Если вы используете функции, которые можно отключить, используйте function_exists(), чтобы убедиться, что они доступны. @missing_function() заставляет PHP молча умирать без каких-либо ошибок.
  • Вы не можете полагаться на вещи, которые можно отключить / изменить с помощью php.ini. Используйте ini_get() для адаптации к различным настройкам.
  • Если включено magic_quotes, удаляйте косые черты только из вашей копии ввода - не изменяйте глобальные массивы! Безопасность некоторых неработающих кодов может зависеть от наличия этих слешей.
  • Ожидайте, что пользователи будут бездумно копировать и вставлять код из вашей документации / веб-сайта.
2 голосов
/ 12 ноября 2008
  1. Может ли config быть локальной для экземпляров классов? Или вы могли бы создать небольшой класс, который вы могли бы создать экземпляр для запроса значений конфигурации? Кроме того, добавление любых глобальных переменных к имени вашего приложения должно как-то остановить конфликты.

  2. Если ваши шаблоны действительно просты, просто напишите короткий шаблонатор. Это будет проще, чем пытаться отразить проблемы, которые возникают у людей при использовании сторонних шаблонов. Это также может упростить вопросы лицензирования. Если вы начнете беспокоиться о том, что у них уже есть, вы никогда ничего не выпустите. Слишком много комбинаций.

  3. Для 3 строк? Да, делайте это так же, как вы работаете с конфигом.

  4. Хорошие комментарии повсюду с введением, объясняющим, как вы используете класс.

  5. Я так не думаю. Если это вас беспокоит, вы можете использовать аргументы по умолчанию, чтобы сначала использовать заданные аргументы, а затем искать значения GET / POST, если они не предоставлены (хотя это может быть угрозой безопасности)

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

Одним из примеров является то, что ярлыки не включены на некоторых хостах (вы должны использовать <?php ... ?> и <?php echo "..."?> вместо <? ... ?> или <?= "..." ?>), что может быть королевской PITA.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...