webdev

На днях обнаружил интереснейшую мелочь, которая может упростить нудный процесс отладки JavaScript кода. Проблема Callstack является совершенно не информативным, используя NoPrototype стиль ООП (то есть, для описание классов/методов используются анонимные функции).

Частенько, меня интересует вопрос насколько мы готовы к использованию новых фишек HTML5. И вот совем недавно нарыл пару полезнейших сайтов: http://www.caniuse.com/ http://html5demos.com/ http://mobilehtml5.org/ Используя эти ресурсы можно подобрать те фишки, которые можно начать использовать прямо сейчас.

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

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

Большое количество статей присутствует в бескрайнем интернете об объектно-ориентированном программирование на JavaScript. Но мне как C# программисту, привыкшему к его ООП синтаксису и количеству возможностей, которые он дает, не одна из них не подходит. Почему же? Задача Что действительно нужно от ООП в JavaScript: Инкапсуляция Наследование Полиморфизм А теперь, по-порядку. NoPrototype Многие способы реализации объект-ориентированного программирования в JavaScript основаны на использовании прототипа ( например ), но ни один из них не решает поставленную мной задачу. Данный способ не будет основан на прототипах, так что с этого следует и название стиля. Но об это далее. Класс Единственное, что нам нужно, так это выработать единый стиль написания класса в JavaScript. Приведем пример класса на C#: public class Book { // конструктор public Book(string newName) { name = newName; } // приватное поле private ...

Окружение В данной статья будет рассмотрено клиент-серверное приложение. Клиента - Silverlight приложение, сервер - ASP.NET, коммуникация осуществляется WCF'ом. Но зачем нам все это... Задача Требование привычное, это повседневная форма редактирования полей сущности. Допустим сущность - Книга, с полями: Название, Автор, Категория, Язык. UI должен содержать контролы: Название - текстовое поле; Автор - выпадающий список, с перечнем всех авторов; Категория - выпадающий список, с перечнем доступных категорий; Язык - выпадающий список, с перечнем всех языков Кнопка сохранения  Вроде бы все предельно просто и понятно, какие могут быть проблемы? Проблема Что бы загрузить все данные, необходимые для нашей формы редактирования, требуется вызвать 4 удаленных серверных метода: Загрузить конкретную Книгу по ее идентификатору; Загрузить список всех Авторов, для заполнения ими выпадающего списка; Загрузить список доступных Категорий, для заполнения выпадающего списка; Загрузи...

Самый простой способ добавить gzip/deflate сжатие в WCF: Добавить метод SetupOutputCompression() в Ваш сервис: private void SetupOutputCompression() { HttpRequest request = HttpContext.Current.Request; HttpResponse response = HttpContext.Current.Response; string acceptEncoding = request.Headers["Accept-Encoding"]; if (string.IsNullOrEmpty(acceptEncoding) == false) { Stream uncompressedStream = response.Filter; acceptEncoding = acceptEncoding.ToLower(); if (acceptEncoding.Contains("gzip")) { response.Filter = new GZipStream(uncompressedStream, CompressionMode.Compress); response.AppendHeader("Content-Encoding", "gzip"); } else if (acceptEncoding.Contains("deflate") || acceptEncoding == "*") { response.Filter = new DeflateStream(uncompressedStream, CompressionMode.Compress); response.AppendHeader("Content-Encoding", "deflate"); } } }  Вызвать метод SetupOutputCompression...