- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
<?php
/**
* Project: Smarty: the PHP compiling template engine
* File: Smarty.class.php
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
* License as published by the Free Software Foundation; either
* version 2.1 of the License, or (at your option) any later version.
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* Lesser General Public License for more details.
*
* You should have received a copy of the GNU Lesser General Public
* License along with this library; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*
* For questions, help, comments, discussion, etc., please join the
* Smarty mailing list. Send a blank e-mail to
* [email protected]
*
* @link http://www.smarty.net/
* @copyright 2001-2005 New Digital Group, Inc.
* @author Monte Ohrt <monte at ohrt dot com>
* @author Andrei Zmievski <[email protected]>
* @package Smarty
* @version 2.6.26
*/
/* $Id: Smarty.class.php 3163 2009-06-17 14:39:24Z monte.ohrt $ */
/**
* DIR_SEP isn't used anymore, but third party apps might
*/
echo ".";
?>
А вот с закрывающим "?>" они рискуют. Там же конце \n может быть.
В старых пыхал был хак - этот \n удалялся. В новых его (хак) убрали?
Edit: поправил пример.
Более-менее нормальное решение - не закрывать ?> в конце файла. А ещё лучше - вовсе не связываться с PHP :).
For files that contain only PHP code, the closing tag ("?>") is never permitted. It is not required by PHP, and omitting it´ prevents the accidental injection of trailing white space into the response.
1. Самый последний тег ?> ни в коем случае нельзя писать, если файл заканчивается php-кодом.
2. Если внутри есть html-вставки, то сразу после ?> один перенос строки может быть съеден при некоторых условиях.
3. BOM у всех файлов, включенных через include/require, будет напечатан.
Последний пункт не относится к теме обсуждения, но часто является источником глюков.
3. Ы :)
- вставки кода в странице на серваке заменяются обычным html, все крайне наглядно
- параметры сами попадают в переменные
- интерполяция строк переменными
- неплохая стандартная библиотека
Наполовину спизженная из сишки.
А ВЫ писали прогу для web на c по всем правилам cgi?
Не, не пробовал. А что там сложного? Строка запроса и прочая инфа в окружении, запощенный контент - в stdin, ответ срать на stdout...
лично я писал cgi скрипты, но не на сишке, а на перле... и вполне себе рабочие гостевухи, без аджакса, есесна
Я таких костылей нигде не видел!
Эти события прилетают каждые N килобайт, и полученный фрагмент надо куда-нибудь засунуть? Вроде вполне адекватно для приема неизвестного объема данных асинхронным сервером, не вижу костыля...
Вот пример функции, обрабатывающей POST запрос:
Рискованная функция ;) Бесконечным chunked стримом можно надувать память ноды пока она не лопнет ;)
А каких-нибудь более высокоуровневых библиотек для этого там нету?
Но замечание верное - система не надежна. И избежать работы с подобными событиями можно использовав различные фреймворки, которые делают это все за тебя.
А чтобы использовать nodejs нативно, приходится иметь дело с событиями и еще (оказывается) следить за размером входных данных. И подозреваю, еще много камешков скрытых :(
По мне так это все выглядит чрезвычайно костыльно.
Для приема файлов - нет, абсолютно нормально. Ну разве что стоило бы из коробки приложить готовый обработчик для сохранения в файл.
А как там дела обстоят с multipart post'ами? Например форма + пара файлов? Самому надо разбирать заголовки mime контейнера? Простенькую формочку без файлов тоже надо обрабатывать аналогичным способом?
По умолчанию нет, но можно установить что-нибудь от сторонних дядь
P.S. Вообще, Node.js временами напоминает brainfuck: простая стандартная библиотека, возможность быстро начать программировать, но для того, чтобы заработало умножение, надо либо его реализовать, либо использовать стороннюю библиотеку.
О_о
По-моему, работа с формами и клиентскими файлами для Node - это как умножение в программировании.
Хотя, ниже Vasiliy верно исправил. Все мы помним целочисленное умножение в JS.
Fix
Да на перле то и я писал. Но там модуль CGI из коробки есть. И куки и параметры он берет на себя. Поэтому там вообще элементарно.
> без аджакса, есесна
А в чем проблема? Аякс и через cgi неплохо летает. Я даже прикручивал недавно к перловым скриптам подобный код.
В CGI одно противно - процесс каждый раз перезапускается, заново поднимает коннект к базе и т.п. На это уходит время...
коробки есть. И куки и
параметры он берет на
себя.
странно, я сам парсил и отдавал как есть.
> А в чем проблема? Аякс и
через cgi неплохо летает.
в том, что тогда о нем никто не слышал. венда 98, 5ый ослик, нетскейп навигатор вроде бы 4ый и опера, вроде бы 7ая.
я про аякс услышал позже, когда вычитал, что можно в документ скриптом добавлять еще один тег <script>
Вспомнилось
http://habrahabr.ru/post/161047/
так это Perl от PHP товарищ бы кончил гораздо раньше.
За что Вы так бедную Луну, такой язык хороший.