Исходный английский вариант звучит через «о».
Если же по аналогии, то существует созвучное слово депозитАрий.
А с ним всё просто:
депозитОрий — это место, а депозитАрий — лицо (чаще юридическое).
Поскольку нас интересует место хранения, то пишем через «о» — репозиторий.
Замечательная статья, толково! :)
Спасибо!
Можно добавить, разве что, явное сравнение размещения подзапросов во FROM (JOIN) с использованием оных внутри WHERE.
Помнится, в «Черном зеркале» ещё в первом сезоне обыгрывалось…
Пользователям было запрещено закрывать глаза при показе рекламы, а отказаться можно было, заплатив энную сумму.
Конечно фиксированая, как и во многих других микропиксельных камерах.
От дифракционной нерезкости никуда не деться — здесь уже законы оптики развернуться не дадут. Потому и приходится производителю использовать всяческие НД фильтры, вот только на ГРИПП эти фильтры никакого влияния оказывать не будут, к сожалению :-(
Уж коли речь зашла о картинках...
Давеча пытался выставить hspace картинкам. IE отображает отступ, а вот fox — только если две картинки рядом, а с текстом — ни в какую. Так и остался текст "прилепленным" к картинкам...
Работаю с xslt почти четыре года. Поначалу было сложно, но разобравшись... мощный интрумент!
Конечно, лучший шаблонизатор...
Первый опыт был с формой контракта. Пользователь заполнял поля, данные, по мере набора, в xml отправлялись на сервер, где лежали 2 шаблона (html + xslt). Трансформация подхватывала данные и расставляла их "по местам" в html-шаблон (доступ к которому имели дизайнеры, не разбиравшиеся в xslt, но этого им было и не нужно). Результирующий html возвращался пользователю в качестве preview контракта... удобно всем — и разработчикам (нас никто не трогает — изменения в форме контракта не требуют изменения кода, поменяли html-шаблон и делов) и дизайнерам (не нужно ничего кодить) и менеджменту...
Продолжением стала работа с формами InfoPath из комплекта MS Office. Там xslt используется как основополагающий инструмент построения отображения. Идея проста, как три копейки — данные (xml-файл) могут быть представлены разными видами (xslt) плюс иметь бизнес-логику в codebehind (C#, JScript) и отображаться встроенным компонентом InternetExplorer. При этом визуальный редактор позволяет накидать дизайн этих видов очень быстро...
Сейчас формы InfoPath с помощью OfficeServer адаптируются для тонких клиентов - перекочёвывают в веб. И здесь мы столкнулись с одной небольшой проблемой. Десктопное приложение поддерживает dataset'овы дифграммы, а web-версия не хочет. Так вот, спомощью xslt на сервере преобразуем получаемые от клиента данные в diffgram, и dataset их "кушает" за милую душу!
Ну и напоследок хочу сказать о производительности. Был у меня один проект... xml-слепок таблиц базы данных, собираемый из нескольких источников, список литературы, с кучей атрибутов... xml файл весил чуть больше 8 мегабайт. Требовалось выдавать пользователю постраничный вид, отсортированный и отфильтрованый по любым из атрибутов. Проблема была в том, что данные были несколько неоднородны. Решили попробовать xslt. И не прогадали — построение вида было довольно быстрым — трансформация перелопачивала весь файл за считанные секунды (особенно, когда его в кэш загнали :)... так и работает до сих пор :-)
Поскольку пишем под ASP.NET то парсером является msxml.
Кстати, в 2005 студии появилась возможность дебагать xslt прямо из C#-кода, а msxml позволяет включать в трансформацию скрипты JavaScript, C# и VB, что очень помогает для реализации, например, таких вещей, как хранение переменных. В упомянутом diffgam-преобразователе замечательно используются Generic коллекция :-)
Если же по аналогии, то существует созвучное слово депозитАрий.
А с ним всё просто:
депозитОрий — это место, а депозитАрий — лицо (чаще юридическое).
Поскольку нас интересует место хранения, то пишем через «о» — репозиторий.
Спасибо!
Можно добавить, разве что, явное сравнение размещения подзапросов во FROM (JOIN) с использованием оных внутри WHERE.
Пользователям было запрещено закрывать глаза при показе рекламы, а отказаться можно было, заплатив энную сумму.
Upd. Почему-то не отображается картинка :(
От дифракционной нерезкости никуда не деться — здесь уже законы оптики развернуться не дадут. Потому и приходится производителю использовать всяческие НД фильтры, вот только на ГРИПП эти фильтры никакого влияния оказывать не будут, к сожалению :-(
Откуда дровишки? ©
<xsl:value-of select="myfunctions:generate_options($options, $selected)/>
Ещё проще и понятнее :-)
Давеча пытался выставить hspace картинкам. IE отображает отступ, а вот fox — только если две картинки рядом, а с текстом — ни в какую. Так и остался текст "прилепленным" к картинкам...
Конечно, лучший шаблонизатор...
Первый опыт был с формой контракта. Пользователь заполнял поля, данные, по мере набора, в xml отправлялись на сервер, где лежали 2 шаблона (html + xslt). Трансформация подхватывала данные и расставляла их "по местам" в html-шаблон (доступ к которому имели дизайнеры, не разбиравшиеся в xslt, но этого им было и не нужно). Результирующий html возвращался пользователю в качестве preview контракта... удобно всем — и разработчикам (нас никто не трогает — изменения в форме контракта не требуют изменения кода, поменяли html-шаблон и делов) и дизайнерам (не нужно ничего кодить) и менеджменту...
Продолжением стала работа с формами InfoPath из комплекта MS Office. Там xslt используется как основополагающий инструмент построения отображения. Идея проста, как три копейки — данные (xml-файл) могут быть представлены разными видами (xslt) плюс иметь бизнес-логику в codebehind (C#, JScript) и отображаться встроенным компонентом InternetExplorer. При этом визуальный редактор позволяет накидать дизайн этих видов очень быстро...
Сейчас формы InfoPath с помощью OfficeServer адаптируются для тонких клиентов - перекочёвывают в веб. И здесь мы столкнулись с одной небольшой проблемой. Десктопное приложение поддерживает dataset'овы дифграммы, а web-версия не хочет. Так вот, спомощью xslt на сервере преобразуем получаемые от клиента данные в diffgram, и dataset их "кушает" за милую душу!
Ну и напоследок хочу сказать о производительности. Был у меня один проект... xml-слепок таблиц базы данных, собираемый из нескольких источников, список литературы, с кучей атрибутов... xml файл весил чуть больше 8 мегабайт. Требовалось выдавать пользователю постраничный вид, отсортированный и отфильтрованый по любым из атрибутов. Проблема была в том, что данные были несколько неоднородны. Решили попробовать xslt. И не прогадали — построение вида было довольно быстрым — трансформация перелопачивала весь файл за считанные секунды (особенно, когда его в кэш загнали :)... так и работает до сих пор :-)
Поскольку пишем под ASP.NET то парсером является msxml.
Кстати, в 2005 студии появилась возможность дебагать xslt прямо из C#-кода, а msxml позволяет включать в трансформацию скрипты JavaScript, C# и VB, что очень помогает для реализации, например, таких вещей, как хранение переменных. В упомянутом diffgam-преобразователе замечательно используются Generic коллекция :-)