All streams
Search
Write a publication
Pull to refresh
47
0
Лунев Антон @silkleo

User

Send message
Приведите список неудобств. Кроме уже упомянутых невозможности работать с хттпс и через прокси.
У меня была как раз мысль сделать «одну коробочку», в которую подаешь урл и пару параметров, или просто урл, а оно тебе что-нибудь там отвечает. Отсюда и такая архитектура.
Ответ на ваш вопрос содержится в топике. Могу даже абзац сверху отсчитать, мне не сложно.
Ответ на ваш вопрос содержится в топике. Могу даже абзац сверху отсчитать, мне не сложно.
Все что вы описали, включая короткие алиасы и тд — в планах. Я над этим думаю и постараюсь воспользоваться большей частью дельных советов, полученных в комментариях. Единственное, не могу обещать, что это произойдет быстро. Работы много.

Но в любом случае спасибо.
Спасибо за добрый совет.

Зенд фреймворк, равно как и его класс для работы с урлами, я в свое время достаточно ковырял, чтобы не испытывать никакого желания использовать этого слона на своих микропроектах. 90% его функционала мне не нужно. Также я ковырял Снуппи и еще пару схожих проектов, ссылки на которые не смог дать в топике, ибо просто потерял.

Моя цель была — сделать что-то карманное, простое и узкоспециализированное.
Вроде того. Только Снупи работает, в основном, на сокетах. Однако тот же механизм общения через хттпс он все равно реализует через Курлу.
Про последнюю возможность не знал, спасибо. Насчет остального подумаю.
А вот кстати, может подскажете, в каком виде их лучше всего будет кидать и на какие именно операции?

А то я думал на эту тему, но так что-то ни до чего структурированного не додумался. Сделал просто $Snufkin->request->error, в который кидаю курловую ошибку, если что-то вдруг не так.

Буду рад идеям/предложениям.
В принципе, некоторые параметры в конфиге можно сейчас просто не указывать, скрипт сам их подставит. Но наверное действительно будет правильней сделать конфиг по умолчанию. Спасибо за подсказку, подумаю.
Хорошо, попробую. Единственное, что не быстро — работы много.
Хм. Занятно, спасибо за наводку.
Чего я никогда не мог понять в людях, так это подобных язвительных пожеланий. Ну, да и ладно.
Создаем несколько «склеек»: main.ru.css, main.en.css, main.ua.css. Способов это сделать автоматически — вагон.

Далее остается только получить из куки (ее все равно придется использовать) или из какого-либо иного источника две буковки, обозначающие язык. И соорудить с помощью используемого шаблонизатора конструкцию <link href="/css/main.{% lang %}.css"/>.

Тот файл, который получится, будет закеширован браузером пользователя.
Я так зову браузер, встроенный по умолчанию в Андроид.
Учитывая, что на выходе получится обычный css-файл, суть вопроса мне не очень понятна.
Можно и склеивать оба файла в «main.css» по принципу: впереди идет язык по умолчанию, затем подклеивается кастомный язык. Тогда файл будет один (соответственно, будет и один запрос).
Конечно. Данный способ с моей точки зрения подходит (если вообще подходит) лишь для локализации элементов дизайна. Меню, вспомогательные ссылки.

Локализовать таким макаром контент страницы во-первых, довольно неудобно по ряду причин, а во-вторых, не имеет смысла. Дело в том, что меню на сайте на всех страницах +– одинаковое. Именно поэтому его имеет некоторый смысл кешировать через CSS-файл. Содержимое же страниц у нормального сайта уникально.
На iPhone Opera Mini свойство content поддерживает. Вряд ли на других платформах с этим браузером ситуация обстоит иначе.
Можно пример?

Information

Rating
Does not participate
Location
Москва, Москва и Московская обл., Россия
Works in
Date of birth
Registered
Activity