<strong>
и <em>
добавляют дополнительное семантическое значение к Вашему документу. Это именно так происходит, что они также дают полужирный и курсивный стиль Вашему тексту.
Вы могли, конечно, переопределить их моделирование с CSS.
<b>
и <i>
, с другой стороны, только применяют моделирование шрифта и больше не должен использоваться. (Поскольку Вы, как предполагается, форматируете с CSS, и если бы текст был на самом деле важен тогда, то Вы, вероятно, сделали бы его "сильным" или "подчеркнутым" так или иначе!)
Hope, которая имеет смысл.
Я бы порекомендовал вам взглянуть на Capistrano , чтобы узнать о проблемах с развертыванием. Я использовал его для развертывания систем PHP, и он будет делать все, что вы описываете (с небольшим скриптом в вашем рецепте развертывания).
Я не храню никаких файлов конфигурации в моем удаленном репозитории - когда я проверяю в dev, я можно добавить их один раз, а затем проигнорировать, чтобы случайно не проверить их. Когда дело доходит до развертывания, мой рецепт развертывания cap настроен так, что он будет записывать файлы настроек в развернутую версию. Таким образом, мне никогда не придется беспокоиться о развертывании и упущении чего-либо критически важного.
Cap также заботится о любых загруженных активах (символизируя каталоги, чтобы они оставались на месте при каждом развертывании), а также автоматически создает резервные копии всех файлов ресурсов и база данных при развертывании в Amazon S3. Довольно здорово, а?
Я сохраняю файлы настроек и .haccess в SVN с переименованными именами файлов, например settings.php.example и .htaccess.example. Таким образом, когда я создаю новую версию, мне не нужно беспокоиться о перезаписи.
У меня есть задача Phing под названием config, которая спрашивает меня, для какой среды я хотел бы настроить код. Задача принимает несколько возможных значений: local, development, staging, production и т. Д.
Как только я сообщаю ей среду, она считывает соответствующий файл .properties (т.е. local.properties, production.properties и т. д.)
Следующий шаг будет для вас ключевым: сохраните ШАБЛОНЫ вашей конфигурации и файлов htaccess, затем запустите для них задачу filterChain replaceTokens, чтобы их токены были заменены значениями из файл свойств.
Создайте эти файлы:
common / build / templates / settings.tpl
define('H_PATH','##H_PATH##');
define('ENVIRONMENT', '##ENVIRONMENT##');
build / templates / htaccess.tpl
http://##H_PATH##
build / properties / local.properties
site.H_PATH = localmyapp.com
site.ENVIRONMENT = local
build / properties / production.properties
site.H_PATH = myapp.com
site.ENVIRONMENT = production
common / build / build.xml
<target name="config">
<input propertyname="env" validargs="local,production">Enter environment name:</input>
<property file="build/properties/${environment}.properties" />
<copy file="build/templates/settings.tpl"
tofile="config/settings.php" overwrite="true">
<filterchain>
<replacetokens begintoken="##" endtoken="##">
<token key="H_PATH" value="${site.H_PATH}" />
<token key="ENVIRONMENT" value="${site.ENVIRONMENT}" />
</replacetokens>
</filterchain>
</copy>
<copy file="build/templates/htaccess.tpl"
tofile="public/.htaccess" overwrite="true">
<filterchain>
<replacetokens begintoken="##" endtoken="##">
<token key="H_PATH" value="${site.H_PATH}" />
</replacetokens>
</filterchain>
</copy>
<echo msg="Configured settings.php and .htaccess for ${environment}" />
</target>
Теперь, когда вы хотите настроить сайт для локального запуска, просто введите:
phing config
, затем введите:
local
и нажмите return. Вот и все! Одним из огромных преимуществ этого является то, что вам больше не нужны ЛЮБЫЕ операторы if / else в вашем коде. Кроме того, он не зависит от переменных $ _SERVER, поэтому отлично работает в командной строке.