Zitrix

Через JS такое можно сделать, только если браузер поддерживает File API (часть HTML-5).

Напишите ему на бумажке шпаргалку со списком команд для исполнения — пусть привыкает так, если учиться не хочет.

Книжку «с носорогом», статьи Крокфорда, блог Резига.

для изучения например developer.yahoo.com/yui/3/history/ и developer.yahoo.com/yui/history/

Да не заморачивайтесь вы.
Используйте тот, который нравится в собственных скриптах и тот, который уже используется в чужих.

Лично мне более приятен второй вариант:

argument = argument || 'value';

Жалко, что в JS нельзя сделать так (как в Ruby):

argument ||= 'value';

Хозяйственный кодекс

Вы привели два равноценных варианта. Первый — наиболее универсальный. Второй — более языкоориентированный. Выбор — кому что нравится.
Один из вариантов (сам стараюсь так делать всегда) — начальная инициализация переменных. До выполнения всех действий описываете переменные и присваиваете им значения по умолчанию. Если соотвествующие параметры заданы — значения переменных обновляются.
Если же вы не присваиваете значения аргументов определенным переменным, а напрямую обращаетесь к этим аргументам, то второй вариант записи, на мой взгляд, более красивый. А первый — более читабельный для человека, слабо знакомого с дополнительными языковыми конструкциями типа 2го варианта. плюс второй вариант может генерировать более компактный код, но вряд ли на общем фоне такая экономия что даст :)
Варианты типа 2 лично я стараюсь использовать только если аргументы в выражении достаточно коротки. Слишком громоздкая конструкция неудобочитаема. Забудешь, потом сам будешь разбираться, что же хотел этим сказать :)

Если абстрагироваться от таких «мелочей» как производительность, масштабируемость и надёжность, то Д(окументно)О(ориентированные)СУБД и О(объектно)О(ориентированные)СУБД во многих случаях позволяют разработчику отражать сущности предметной области на сущности БД без введения дополнительных сущностей :), которые приходится вводить в Р(еляционных)СУБД. Например, сколько копий переломано в спорах о том, как хранить в РСУБД объекты различных классов, унаследованных от одного базового класса (в одной таблице с кучей пустых полей, в таблицах для каждого отдельного класса, в общей таблице общие поля, ...), а тут просто храним в одной «таблице» и не думаем о таких мелочах. Отношения 1:1 и 1: М, когда сущности во второй половине отношения принадлежат одной и только одной сущности первой и не имеют смысла без неё также отображаются без дополнительных таблиц и полей для связи (вместо comments.post_id и comments.content просто храним в поле posts.comments список/массив комментов, не заботясь о целостности связей, синхронизации и т. п.). Другими словами, ДОСУБД часто облегчают жизнь разработчику, хотя иногда её усложняют (когда связи двунаправленные прежде всего, особенно M: М — для установления связи между двумя уже существующими сущностями надо производить две операции — добавление к первой ссылку на вторую, а ко второй на первую -, а не одну — добавление в таблицу связи — как в РСУБД )

blog.wordnik.com/12-months-with-mongodb
Пример практического применения

Смысл ряляционных баз когда то был лишь в том, чтобы дать ответ на _любой_ вопрос за _любой_ промежуток времени. Т.е. например есть какая-то бд в компании и надо сделать какой-нибудь отчёт.

В интернет-приложениях все несколько по иному. Чаще всего запросы к БД одинаковые за редким исключением (поиск). BigTable и прочие завязываются на этот принцип, создавая индекс на нужные запросы при изменении данных асинхронно.

Таким образом, после изменения данных сразу обновляются и индексы для нужных запросов. В SQL индексы тоже есть, но они на более низком уровне.

MongoDB строит индексы автоматически при первом запросе. Посему это очень похоже на схему lang <-> memcache <-> sql. Но на порядок быстрее, т.к. сам mongodb быстрее чем memcached (я сам сие не проверял ещё и верю с трудом, но все в один голос твердят что это так).

Второй бонус — более простая репликация. В частности, у того же mongodb концепция master-slave и шардов находится в самом сердце.

Третий бонус — map/reduce для обработки данных. Выполняются на встроенном языке (у mongodb это spidermonkey, т.е. яваскрипт).

В общем и целом изначально написанное на mongodb приложение будет теоретически быстрее чем SQL вариант. По крайней мере с быстрой реализацией, наподобие MongoDB.

Можно использовать 1 извращенный способ.
Использовать postMssage, который будет транслировать запросы localStorage на специальной странице, аля localStorage.example.com :)

Кстати, можно поиграться с попытками достучаться на прямую к localStorage ifram'a ведь, домен 2рого уровня страниц будет одинаковый. Не помню, просто, пзволят ли политики безопасности.

Для максимальной скорости загрузки вынесите всю логику рендеринга в отдельный статичный JS скрипт и сожмите его gzip-ом, а данные блока в JSON подгружайте. Статичный JS закешируется и все летать будет :-) Кроме того можно будет разместить несколько блоков на одной странице и обрабатывать их все тем же одним JS, а не грузить для каждого HTML.

ИМХО, если хорошо знаешь серверные технологии, развивайся в сторону клиентских технологий! Так что как выше уже советовали — javascript!

Думаю наиболее оптимальный вариант — начать изучать и то и другое. А дальше смотреть на то что ближе, удобнее, понятнее etc. именно вам. Ну и на востребованность на рынке.

<!DOCTYPE html>
<html>
	<head>
		<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
		<title>jQuery UI Example Page</title>
		<script type="text/javascript" src="js/jquery-1.4.2.min.js"></script>
		<script type="text/javascript" src="js/jquery-ui-1.8.4.custom.min.js"></script>
		<script type="text/javascript">
			$(function(){
				$('body').append('<div id="newblock">Новый элемент</div>');
				$('#newblock').draggable();
			});
		</script>
	</head>
	<body>
		<div>
			:)
		</div>
	</body>
</html>

Все прекрасно работает. Вы бы полнее пример привели.

На стороне сервера вы же знаете статус. Передайте его в яваскрипт.
На пхп:
echo '<script type=«text/javascript»>var status='.$status.';</script>';

Ну на самом деле разница между B и E есть, в случае E, когда метод объявляется прямо в конструкторе он будет иметь доступ к приватным переменным и методам, это так называемые привилегированные методы, а вот в примере B нет возможности работать с приватными данными.
Вот о чем я говорю:

var MyClass = function() {
  // Приватные атрибуты
  var _a, _b;
  // Приватный метод
  function _myPrivate(isbn) {
  } 
  // публичный привилегированный метод
  this.MyPublicPlus = function() {

  };
}

// публичный непривилегированный метод.
MyClass.prototype = {
  MyPublic: function() {
  }
};


Метод MyPublicPlus будет иметь доступ к _a, _b и _myPrivate(), а MyPublic нет…

UserEcho — saas сервис обратной связи, помимо сбора и комментирования отзывов, юзеры могут голосовать и приоритезировать их.