По вашим словам, так за «иллюстрацию на scheme, использующую нативное использование продолжения в форме call/cc.»
будущее? =))))
Вот интересный вопрос: «наиболее естественно поддерживает». Вот лично вам не все-равно?
Для примера: file_get_contents пыховый или нативно-сишный fopen/fread. Нет file_get_contents — напишем для него враппер.
Вопрос не в том, чтобы «переписать аналогичное». Уверен, что переписать можно что угодно на чем угодно. Просто зачем набиваться на холливары — не совсем ясно =)
А вы желаете съесть рыбку не заплатив? За все нужно платить — желаете вы этого или нет.
А на тему интерфейсов — есть программисты не идиоты — напишут через адаптер рисование графиков. Потом к новому рисовальщику нарисуют адаптер. И все шоколадно ;)
Уважаемый qmax. Хочется заметить, что для «эмуляции»- достаточно лишь идентификатора сессии.
Остальное — дело техники. OOP в PHP давно позволяет делать __sleep/__wakeup. Для нормального «восстановления» объекта достаточно написать базовый класс и указать обработчик сериализованного объекта.
Для того, чтобы писать полноценные (с точки зрения вымышленной здесь проблемы) приложения — достаточно просто чуток подумать головой и посмотреть в ман по нужной области.
И будущее, кстати, не за языками, а за технологиями. А язык — это вопрос применимости. Сейчас начнут холливарить ведь ;)
А вы используейте интерфейсы. Они не просто так придуманы. Максимум, что прийдется вам сделать после того, как Гугля закроет сервис (хаха) — написать свой класс для рисования. И код не прийдется перечесывать ;)
Кстати, да.
Родной php-файлик для проверки орфографии через Google API лежит в папочке wp-includes/js/tinymce/plugins/spellchecker/classes/
Если кого обламывает разбираться в интерфейсах — написал для себя небольшой класс. Забрать можете здесь: proxysoft.ru/files/spellchecker.zip
На JS, думаю, тоже вскоре прикрутить получится. Несложно, если на вскидку, должно быть…
По-моему, очень даже передергивает ;)
Я так понимаю, упрек на тему «шаблонизатора» — это в мою сторону камешек. Только человек не привел ответ — как был PHP шаблонизатором — так и оставил в себе все функции «шаблонизатора». Ибо встраивается в HTML и позволяет в себя «встраивать».
Никто не говорил, что str_replace лишен недостатков. Это же очевидно :)
Просто лично для меня гораздо удобнее. Для дизайнеров удобнее. Для «программистов после» меня разобраться в шаблонизаторе = прочесть один класс в 70 строк кода.
А XSLT — это маяк впереди. По примерам видел, что много чего красивого можно сделать, не выдумывая «условно_человеческую_логику» :)
Вы искренне верите, что в Смарти нельзя запутаться верастальщику? Лично знаю парочку, которая чуть не плачет и просит программистов переписать работу с шаблонами.
Воооот и нарисовывается золотая середина между нативностью и удобством. =)
В логике шаблонизатора верстальщик может запутаться, а в коде — натворить чего не так.
// по крайней мере, для меня, она нарисовалась года 2-2.5 назад. А сейчас общими усилиями к ней подходим.
Уважаемый, вот у меня вообще нет представления в коде. А сделано это благодаря «дроблению» дизайна на куски, которые в смарти через if-ы собираются. Это раз.
Во-вторых. Я лично не ратую за чистый код в шаблонах — поэтому и str_replace. Очень удобно, скажу я вам. И быстро :)
будущее? =))))
Вот интересный вопрос: «наиболее естественно поддерживает». Вот лично вам не все-равно?
Для примера: file_get_contents пыховый или нативно-сишный fopen/fread. Нет file_get_contents — напишем для него враппер.
Вопрос не в том, чтобы «переписать аналогичное». Уверен, что переписать можно что угодно на чем угодно. Просто зачем набиваться на холливары — не совсем ясно =)
А на тему интерфейсов — есть программисты не идиоты — напишут через адаптер рисование графиков. Потом к новому рисовальщику нарисуют адаптер. И все шоколадно ;)
Остальное — дело техники. OOP в PHP давно позволяет делать __sleep/__wakeup. Для нормального «восстановления» объекта достаточно написать базовый класс и указать обработчик сериализованного объекта.
Для того, чтобы писать полноценные (с точки зрения вымышленной здесь проблемы) приложения — достаточно просто чуток подумать головой и посмотреть в ман по нужной области.
И будущее, кстати, не за языками, а за технологиями. А язык — это вопрос применимости. Сейчас начнут холливарить ведь ;)
Родной php-файлик для проверки орфографии через Google API лежит в папочке wp-includes/js/tinymce/plugins/spellchecker/classes/
Если кого обламывает разбираться в интерфейсах — написал для себя небольшой класс. Забрать можете здесь: proxysoft.ru/files/spellchecker.zip
На JS, думаю, тоже вскоре прикрутить получится. Несложно, если на вскидку, должно быть…
public function getTwelveMonths($format)
{
$fromMonth = (12 + ($this->_month — 11))%12 == 0? 1: (12 + ($this->_month — 11))%12;
if ($fromMonth > 1) {
$year = $this->_year — 1;
} else {
$year = $this->_year;
}
Я так понимаю, упрек на тему «шаблонизатора» — это в мою сторону камешек. Только человек не привел ответ — как был PHP шаблонизатором — так и оставил в себе все функции «шаблонизатора». Ибо встраивается в HTML и позволяет в себя «встраивать».
Надо рассматривать плюсы и минусы каждого из типов шаблонизаторов. Тогда, более-менее, сможем составить картинку для «непосященных» =)
2. Пример с sql — выдуман. Чтоб не спрашивали «что это такое».
Просто лично для меня гораздо удобнее. Для дизайнеров удобнее. Для «программистов после» меня разобраться в шаблонизаторе = прочесть один класс в 70 строк кода.
А XSLT — это маяк впереди. По примерам видел, что много чего красивого можно сделать, не выдумывая «условно_человеческую_логику» :)
$data = $this->db->getItem('SELECT * FROM articles LIMIT 0, 1');
$data['title'] = $important? $data['title']: $HTML_Tags->b(data['title']);
$html = Template::mountVars('tmpl_name', $data);
В логике шаблонизатора верстальщик может запутаться, а в коде — натворить чего не так.
// по крайней мере, для меня, она нарисовалась года 2-2.5 назад. А сейчас общими усилиями к ней подходим.
Во-вторых. Я лично не ратую за чистый код в шаблонах — поэтому и str_replace. Очень удобно, скажу я вам. И быстро :)