Метод с Хешбенгом реализован много раз, полно примеров. И до сих пор работает хорошо.
Пререндер, который вы рекомендуете - поисковики не видят что ты делаешь внутри сайта.
Если вы действительно что то можете сказать по делу - как именно сделать одностраничники видимыми поисковикам - я с удовольствием тоже почитаю.
1. Пришел к тебе запрос (может с внешнего сервиса, с браузера или, может, от части твоей же собственной программы, неважно). Была вызвана какая-то функциюядля обработки, та вызвала еще, та еще, та еще.
2. И где-то там в глубине нужно принять решение - что ответить на запрос. Или, возможно, пора уже отказаться и оборвать (по таймауту например), или тебя снаружи не захотели столько ждать и связь оборвали и тебе не нужно обрабатывать.
3. В контекст складывается вся информация, которая нужна для обработки, для принятия решения. Иногда - там же обрывается соединение. Но прежде всего контекст - это куча информации.
4. Как правило эту информацию может в контекст положить самая первая, верхняя функция - обязательно. Вложенные функции - могут дополнять контекст.
5. Где-то в самом низу, в самой глубоко вложенной функции тебе как на блюдечке в контексте лежит куча информации для принятия решения.
6. Можно это делать и просто прокидыванием переменных внутрь. Но с каждым уровнем число переменным может возростать.
7. Контекст - не то чтобы заведомо удобнее, но всяко-разно универсальнее. Хотя для простых случаев я бы обошелся без него. С ним все таки не очень удобно. Например, типичным для контекстов является сохранение значений в map[string]interface{}, что лишает тебя возможности проверки типов на этапе компиляции. Так что в простых случаях можно обойтись без этого, вместо контекста использовать переменные вполне определенные и вполне определенных типов - будет надежнее работать. Но в сложных случаях этих переменных будет слишком много, они могут быть разных типов, не все из них будут всегда использоваться, поэтому вариант map[string]interface{} и используется зачастую.
7. В случае с /x/net/context - это используются интерфейсы, что делает его вроде менее очевидным, но более типобезопасным. В статье https://habrahabr.ru/post/269299/ описано немного какие есть альтернативные представления контекстов. Все они - проще для понимания, более тривиальны, подобны обычному map[string]interface{}. Но этот контекст хоть и более мозгодробительный, но более надежный, так как часть ошибок вылавливает компилятор.
8. Типичное использование в веб-приложениях к примеру (можно и не только в веб-приложениях, но это я к примеру) - изначально кладем туда данные запроса, лучше слегка обработанные. "/api/v1/labuda/123" - например RESTful API - получение labuda #123 - кладем в контекст объект Labuda{}, на следующем уровня в контекст вкладывается объект DatabaseConnection, а в самом низу извлекаем данные пользуясь DatabaseConnection и кладем их в Labuda{}, результат так же через контекст возвращается наверх.
maxt888:
> Там есть проблема, что в большом проекте всего не учтешь, а доплачивать потом заказчик откажется.
Нет такой проблемы.
Большие проекты слишком большие. Их делают с многоэтапной оплатой. Откажись на последнем этапе - много не потеряешь....
Да и кто тебе сказал, что отказываются. Торгуются - да. Но не отказываются. Если это большой и сложный проект, то заказчик понимает, что кто попало в курс дела быстро не войдет. И если ты ведешь себя адекватно - то вполне можно сторговаться.
Лендинго не занимаюсь.
Но:
каждый раз когда вижу работу которая мне интересна - просто предлагаю свою цену. Она может быть и в 3 раза выше цены исходной и в 10. Где-то в 5% случаев - заказ мой.
copal:
> а разве это не будет относится к новостному сайту, за которые сегодня нужно отчислять как за сми?)
Нет. К новостному сайту это не относится.
СМИ имеют несколько больше прав на оформление новостных материалов чужими медиа-материалами. В этом случае они используют в своем материале чужой материал.
Но если вы именно цитируйте, то ваши возможности ничуть не меньше чему СМИ.
antobra:
Различайте ситуацию, когда вы делайте чужие медиа-материалы основым содержимым своего сайта.
А когда вы делаете основным содержимым ссылки на чужие медиа-материалы.
antobra:
> Гугл-фото копирует изображения на свои серверы и показывает их в результатах
1. Есть ограничения на разрешение, есть прямые ссылки на источник.
2. Никто в здравом уме и твердой памяти не будет возражать против того, чтобы их сайт был проиндексирован Гуглом или Яндексом.
antobra:
Фотографы-стокеры, зарабатывающие продажей фото, напротив, будут возражать против размещения их фотографий.
Не будут возражать при размещении статьи типа "я нашел прекрасного фотографа водопадов, вот его 3 водопада, остальные 103 вы можете найти на сайте - и ссылка на сайт, где это продается".
antobra:
Производители ничуть не возражают против размещения реклманых материалов своей продукции. Ведь именно для этого рекламные материалы и создавались.
У многих производителей даже есть специальные разделы на сайтах - с набором рекламных брошюр, которые могут распечатать себе любые желающие магазины продающие их товар, обоев для рабочего стола и т.п.
А я о том, что:
Метод с Хешбенгом реализован много раз, полно примеров. И до сих пор работает хорошо.
Пререндер, который вы рекомендуете - поисковики не видят что ты делаешь внутри сайта.
Если вы действительно что то можете сказать по делу - как именно сделать одностраничники видимыми поисковикам - я с удовольствием тоже почитаю.