Лучший способ использовать язык разработки на стороне сервера, но развернуть в статическом HTML - PullRequest
3 голосов
/ 20 июля 2009

У нас есть клиент, для которого мы создаем много сайтов на основе шаблонов. В идеале мы будем использовать что-то вроде kohana (http://www.kohanaphp.com/)) для обработки шаблонов и внесения изменений в сайт на одном дыхании.

К сожалению, наш клиент не может (и не будет) размещать какой-либо серверный код (и, прежде чем вы спросите, это не изменится, и размещение файлов сами по себе не вариант), поэтому любые файлы, развертываемые на них, должны быть HTML, Javascript, CSS, изображения и только Flash.

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

Полагаю, это было бы похоже на паутинку сайта, но я бы хотел что-то более надежное, потому что некоторые ресурсы страницы динамически загружаются с помощью javascript.

Спасибо

Ответы [ 6 ]

1 голос
/ 21 июля 2009

Я использую Template Toolkit (Perl) и у меня есть простой скрипт, который генерирует статические файлы из шаблонов. Это отлично подходит для ситуации, в которой вы находитесь (обычная навигация и т. Д.).

Он поставляется с командой ttree, которая обрабатывает дерево каталогов и помещает результаты в другое.

Вот файл tt.rc, который я использую:

# ignore these files (regular expressions)
ignore = \.svn
ignore = ^#
ignore = ~$
ignore = .DS_Store
ignore = \.tt$

# if these template files change, reprocess everything
depend *=tpl/wrapper,tpl/defaults,style/default.html

# just copy these files, don't process as templates
copy = \.(gif|png|pdf|jpg)$

# verbose output
verbose

# recurse into subdirectories
recurse

# setup some defaults from tpl/defaults
pre_process = tpl/defaults

# process this file instead of the real file (see below how this is used)
process     = tpl/wrapper

# process files from src/, output to html/
# extra templates in lib/ (tpl/wrapper for example).
src  = src
dest = html
lib  = lib

Пара специальных файлов, tpl/defaults - это

[%-  page = {
            title = template.title,
            style = template.style or 'default.html'
    };

    base = INCLUDE tpl/base_uri;

    # don't include any whitespace from here...
    RETURN;
-%]

А tpl/wrapper является

[%- content = PROCESS $template;    
   IF !template.name.search('.html') OR page.style == 'none';
      content;
   ELSE;
      default_style_template = "style/" _ page.style;
      PROCESS $default_style_template;
   END;
%]

Это обработает настоящий шаблон; поместите результаты в переменную content, а затем обработайте шаблон style (установите с page.style в tpl/defaults; по умолчанию defaults.html).

файл стиля lib/style/default.html просто должен иметь

[% content %]

где-то включить настоящий шаблон; до и после этого вы можете иметь стандартный нижний колонтитул и верхний колонтитул.

Подробнее о Template Toolkit можно прочитать по адресу tt2.org .

Другой вариант - использовать wget (или аналогичный) в рекурсивном режиме для «зеркального отображения» страниц, сгенерированных PHP на сервере разработки; но я бы не советовал.

1 голос
/ 21 июля 2009

Дайте WaveMaker Studio попробовать. Это частично решит вашу проблему.

WaveMaker Studio имеет своего рода шаблонную функцию и поставляется в версии с открытым исходным кодом сообщества.

НТН

0 голосов
/ 20 июля 2009

Я не знаю, будет ли это вариант, но я бы предложил CushyCms . Это онлайновая CMS, в которой вы определяете области содержимого с помощью классов CSS и можете редактировать содержимое в Интернете. Вам необходимо предоставить данные FTP, так что это может быть для вас преградой, но я подумал, что стоит упомянуть.

0 голосов
/ 20 июля 2009

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

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

0 голосов
/ 20 июля 2009

Хм ... Если сервер клиента не поддерживает PHP или ASP, я не думаю, что они пойдут на CGI, который является более небезопасным.

Ну, вы могли бы сделать свои страницы в приложении разработчика, загрузить эти страницы в браузере и затем сохранить полученный HTML. Сделайте это для всех страниц, и все готово.

Просто убедитесь, что ссылки направлены вправо.

0 голосов
/ 20 июля 2009

Рассмотрите альтернативные решения, даже если вы не думаете, что можете их использовать. Ошибочно игнорировать новые решения, потому что ваш клиент «не может обрабатывать языки на стороне сервера» (перефразировано). Иногда требование является результатом неправильных знаний. Например, действительно ли клиент не может разместить какие-либо языки на стороне сервера, потому что он не может разместить IIS или Apache - или это потому, что у них их нет и они не могут установить любое другое приложение? (Если они могут установить приложение, возможно, решение может состоять в том, чтобы просто предоставить «маленький» веб-сервер - возможно, XSP).

Я также предлагаю вам взглянуть, например, на Google "gears". Я слышал об этом неплохие вещи, хотя они могут не подходить для ваших нужд.

В противном случае вам, вероятно, лучше всего игнорировать классические серверные языки и делать все это на стороне клиента, или использовать серверные языки в качестве экспортера. (Что будет заказной работой). Я думаю, что «экспорт» сайта с использованием пользовательских сценариев, вероятно, лучший подход.

Наконец, на этот вопрос действительно нет единственного ответа - как программист, ваша задача - взвесить разные сильные стороны и разные решения и выбрать лучшее.

...