Эх, а я с такой радостью, помнится, зарегистрировался на «Фрилансим». Думал тогда:
Фу на фл.ру! Какой это, наф, фриланс, когда за возможность получить заказ (а ведь не факт ещё, что получишь) я должен платить деньги? Вперёд на идеологически правильный сервис!
Угу, порадовался, называется. Рановато. Ладно, не беда, ещё одной ценной идеей по освобождению сети интернет от излишней корысти стало больше. Будем, что называется, думать и делать свободную от подписок площадку. В топку платный фриланс, напоминающий кадровые агентства, где я должен платить деньги, чтобы найти работу! А ведь так всё хорошо начиналось: оплата каждого заказа заказчиком, для фрилансеров платны только моментальная рассылка новых заказов и выделение из толпы. Жаль…
З.Ы. А дизайн ничего так. Может быть, требует некоторой доработки напильником, но я особо не заметил в огнелисе на стационарном ПК.
Если есть свой сервер с жёстким диском гигабайт эдак на двести, тогда накукуй Вам вообще дропбокс? Только позвольте немного статистики: количество людей, имеющих своё стабильноевеб-хранилище, весьма невелико — не думаю, что больше пары процентов во всё мире (и это по самым оптимистичным оценкам).
Раздать можно и через ЯД, и через старый ДБ, и через новый ДБ… Да через что угодно. Если нужно, чтобы человек тупо мог скачать файл, тогда принципиально мало разницы, через что отдавать. Подумаешь, скачает после предварительной пары-тройки капчей капчи. Эка неприятность-то. Вышеприведённая неприятность коснётся в основном гиков вроде меня, использующих дроп-бокс, как дополнительное файло-хранилище для медиа-контента сайта, когда нужна действительно прямая ссылка.
В принципе и в теории сейчас можно использовать «народ». Та же пара гигабайт (см. пункт про FTP, где говорится о непредсказуемости поведения FTP при превышении этой нормы). Главное, в этом случае ничего нам не грозит при большой посещаемости. У нас сайт — и не волнует. Что ж поделать, если он посещается хорошо? Однако, налицо неудобство присущее практически любому FTP-хранилищу — ручная синхронизация. Я вот, например, работаю с музыкой и программирую. Есть вот такая задачка: придумать простое решение, позволяющее синхронизировать локальное хранилище с хранилищем для ссылок на сайте. Решите её при помощи «народа» :)
Не, на самом деле Х.З… Я не обратил внимания. Однако, опять таки же стоит подумать над тем, что не у всех пользователей браузеры держат HTML 5. Ну, есть стопудово дятлы, не обновляющие своё ПО.
Спамилке на основе полнофункционального браузерного движка достаточно будет лишь дождаться выполнения javascript'а. В любом случае такая спамилка отправит форму не тупым POST/GET-запросом, а программным нажатием на кнопку.
Забавная вещица. С демкой поигрался — любопытно. Правда, nitro80 правильно говорит — не у всех может быть установлен flash. Хотя таких пользователей сейчас по сути, так сказать, подавляющее меньшинство.
В своё время написал ещё одно любопытное решение на основе скрытых полей и сессий — habrahabr.ru/post/150492/. Правда в итоге его посчитали неэффективным.
Простите, будет грубо, зато правда. Ваши изречения напоминают точку зрения ортодоксального программиста-процедурника. Вот ему обязательно надо запихнуть каждый чих в begin-end или фигурные скобки — кому как милее; написать программу уровня Hello-World на .NET Framework, притом последней версии. А ч0, это же удобно! Его не заботит тот факт, что каждый лищний ret — это лишние такты процессора. Ему важнее «кошерность» кода. Да, я из тех, кто знает цену ассемблерным вставкам в программах, написанных на языках высокого уровня.
Да, я в своём решении обращался напрямую к БД. Зато меньше процессорного времени тратится при таком подходе. Ладно у меня на сайте с посещаемостью порядка 10 человек в квартал. А на проектах с высокой степенью нагрузки? Особенно если на дешёвом хостинге/оборудовании. Там каждый процессорный такт на счету. А теперь просто представьте себе, что каждая страница выполняет код с обращением к xPDO, получением через него объектов, переключением контекстов вместо простой прямой инициализации нужного контекста, полученного прямым запросом к БД через резидентно выполняемый на сервере процессор MySQL.
Не, а ч0, давайте использовать возможности современных серверов на полную катушку! Авось не заблокируют за CPU Overload на хостинге.
Не стану с Вами спорить. Давайте проще — напишите свою статью об этом. А то захожу я на «хабрахабр», ищу что-то подобное, да не нахожу. И приведите, пожалуйста, в своей статье рабочее решение, позволяющее управлять мультидоменным и мультиязычным сайтом.
Это вариант с языками. Его можно реализовать и без контекстов. Банально к каждому материалу добавляем доп.поле заголовка и доп.поле контента. Ну, это я пока что эмпирически сказал :)
Боже мой, ну Вы и наворотили! О, о
Смысл прямого обращения к БД очень прост — экономия ресурсов. Представьте себе Ваш код, который отрабатывает на каждой странице. Я может быть чего-то не знаю об xPDO, но, ИМХО, Ваш код будет в разы дольше выполняться.
Любопытная и полезная штука. Только, мне кажется, поздновато её опубликовали. Уходит век веб-графики, уходит. Например, я пару лет назад пользовался IconSearch для поиска иконок. Теперь я использую комбинацию символьных шрифтов и CSS (директиву font-face в частности). Кнопки уже можно сделать на чистом CSS3. Единственное, что не скоро отойдёт в разряд архаизмов — это медиа-плееры.
Угу, порадовался, называется. Рановато. Ладно, не беда, ещё одной ценной идеей по освобождению сети интернет от излишней корысти стало больше. Будем, что называется, думать и делать свободную от подписок площадку. В топку платный фриланс, напоминающий кадровые агентства, где я должен платить деньги, чтобы найти работу! А ведь так всё хорошо начиналось: оплата каждого заказа заказчиком, для фрилансеров платны только моментальная рассылка новых заказов и выделение из толпы. Жаль…
З.Ы. А дизайн ничего так. Может быть, требует некоторой доработки напильником, но я особо не заметил в огнелисе на стационарном ПК.
Раздать можно и через ЯД, и через старый ДБ, и через новый ДБ… Да через что угодно. Если нужно, чтобы человек тупо мог скачать файл, тогда принципиально мало разницы, через что отдавать. Подумаешь, скачает после предварительной
пары-тройки капчейкапчи. Эка неприятность-то. Вышеприведённая неприятность коснётся в основном гиков вроде меня, использующих дроп-бокс, как дополнительное файло-хранилище для медиа-контента сайта, когда нужна действительно прямая ссылка.В принципе и в теории сейчас можно использовать «народ». Та же пара гигабайт (см. пункт про FTP, где говорится о непредсказуемости поведения FTP при превышении этой нормы). Главное, в этом случае ничего нам не грозит при большой посещаемости. У нас сайт — и не волнует. Что ж поделать, если он посещается хорошо? Однако, налицо неудобство присущее практически любому FTP-хранилищу — ручная синхронизация. Я вот, например, работаю с музыкой и программирую. Есть вот такая задачка: придумать простое решение, позволяющее синхронизировать локальное хранилище с хранилищем для ссылок на сайте. Решите её при помощи «народа» :)
.оО( Интересно, если бы каждое такое пожелание сбывалось, насколько я бы был удачлив?.. )
Да, я в своём решении обращался напрямую к БД. Зато меньше процессорного времени тратится при таком подходе. Ладно у меня на сайте с посещаемостью порядка 10 человек в квартал. А на проектах с высокой степенью нагрузки? Особенно если на дешёвом хостинге/оборудовании. Там каждый процессорный такт на счету. А теперь просто представьте себе, что каждая страница выполняет код с обращением к xPDO, получением через него объектов, переключением контекстов вместо простой прямой инициализации нужного контекста, полученного прямым запросом к БД через резидентно выполняемый на сервере процессор MySQL.
Не, а ч0, давайте использовать возможности современных серверов на полную катушку! Авось не заблокируют за CPU Overload на хостинге.
Смысл прямого обращения к БД очень прост — экономия ресурсов. Представьте себе Ваш код, который отрабатывает на каждой странице. Я может быть чего-то не знаю об xPDO, но, ИМХО, Ваш код будет в разы дольше выполняться.