Робот яндекса какой регион для себя выбирает?
Это самый интересный вопрос в дизайнерском домене: почему у дизайнеров и архитекторов как правило совершенно угребищные сайты по всем критериям?
Можно сказать ну в вебе они нуль, поэтому так делают. Не катит. Эстетика одинакова что в музыке, что в литературе, что в базах данных. Выразительные средства разные, а эстетика - одна.
Короче сайт УГ в кубе, ничего не впаривает, скорее наоборот отвращает, антирекламный, антипродажный и ничего предприятию не даст кроме позора. Потому что легко сделать вывод - какой у фирмы сайт, такова она сама. Угребищный сайт == угребищная фирма.
В общем тезисы:
1. сайт предприятия это не сайт-предприятие. Это было бы забавно узнать что, скажем, Сбербанк или Металлобаза номер 88 рассчитывают увеличить квартальную прибыль за счет повышения посещаемости своих сайтов.
У сайта предприятия первично предприятие, а сайта-предприятия - сайт.
2. возня с покупкой ссылок и прочими простыми и легкими методами нагнать волну на сайт-предприятие обусловлена слабостью мозга хозяев предприятий. В коньюктуре они нуль, в пиаре нуль, в рекламе нуль, идут и покупают спам.
А вот возня с покупкой ссылок для сайта предприятия, это, как сами уже понимаете, бред в Кубе. Если предприятие не интересно, не имеет своей фичи, если о нем не говорят, не советуют, не рекомендуют и все такое - придется включать модель постоянной рекламы. То есть закладывать рекламу в ценник и крутить рекламный бюджет по всем каналам. Многие так и делают.
Мелкие 1 заголовок
Средние 3 заголовка
Крупные 10 заголовков
Дело не в количестве букв, а сколько смысла и ключей и релевантности вы повешаете на 1 урл.
Кроме того отпостить 10 раз выгоднее в плане демонстрации роботу активности сайта.
Можно передавать что угодно, в том числе и стили, генерально такая передачка называется - конфиг. Однако когда у вас есть класс из которого делается объект, этот объект сам может достать нужный ему конфиг. Дилемма pull or push решается по обстоятельствам и не нуждается в паттерне, если, конечно, вы не запутаетесь где тянуть, а где вставлять.
В литературе, особенно в русской, все старье. PHP это не Паскаль, по нему программирование изучать можно, но получится двойная работа. Сначала вы учите программировать на давным-давно устаревших кодах, потом учитесь применять навыки с новыми кодами. А вот если вы учитесь программировать на Паскале - типа латыни для программистов, то учитесь вечному вообще, абстрактно, а потом уже на любом другом языке ищите соответствующие средства и конструкции.
PHP это скрипт, а скрипт должен работать быстро и быстро. Если же делать как в рамках делают, вам придется кешировать все подряд, иначе сервер сдохнет от таких топологий, когда загружается приложение типа Фотошопа ровно для того, чтобы через несколько секунд выплюнуть кусок хтмля и умереть.
Так вот, а что касается статеек, то они уже в бд либо в хтмле, либо в формате под какой-нибудь маркдаун и собственно кроме рендера там ничего и нет важного.
Насчет как передать стили. Да вот как хотя бы $news = new CNews(); и потом где-то перед рендером $news->style='foo-bar'; чтобы __toString() уже знал какой css-класс назначить чему-то там, потому что в туСтринг передать параметры нельзя. А если без волшебства, то элементарно $news->render_list('foo-bar'); в том месте, где список должен быть именно в этом стиле, ---------- Добавлено 08.06.2015 в 09:33 ---------- Да, самая мякотка. Самая мякотка классов и их инстансей - объектов - в наследовании. В PHP можно наследоваться единовременно, то есть от одного класса. Но и этого вполне хватает для счастья. Из наследования вытекают интерфейсы. До полиморфизма вряд ли имеет смысл рыть в PHP, иначе получите тот самый самый жирный фреймвморг.
Ну то есть модель существует, в неявном виде, как метод класса. Чтобы ее не приходилось размножать под разнообразный контекст, мы разбираем запрос, или пишем класс конструктора запроса, который можно заюзать для аналогичных иерархичных отношений в БД. Самый простой конструктор для самых простых запросов состоит из методов одноименных кляузам SQL. Например
protected function select($item=null){ return 'select id, title, subttle';}protected function from($item=null){ return ' from news';}protected function where($item=null){ if($item['pid']!=0) return ' where pid='.$item['id'];}protected function order(){ $ord = new COrder(); return $ord->sql();}protected function limit(){ $this->pgn= new CPagination(); return $this->pgn->calc_limit();}protected function query($item=null){ $sql=$this->select($item) .$this->from($item) .$this->where($item) .$this->order() .$this->limit(); $this->data=$this->mysqli->query_use($sql)->fetch_all(MYSQLI_ASSOC);}
Такой класс будет выдавать листинг всего что есть в таблице News по страницам в порядке определенном параметрами в search string. Если определена категория - то по категории. Теперь под любой контекст можно унаследоваться и поменять/модифицировать методы контруктора запроса используя одну и ту же "модель" - метод query(); Например для одной статьи нам нужен еще и текст:
protected function select($item=null){ return parent::select($item).',text';}protected function where($item=null){ return ' where id='.$item['id'];}
Методы рендера в том же самом классе. Обычный паттерн методов before_render(), render(), after_render() - вызывается из __toString() в охвате try-catch на случай вывести текстом глюки.
Что это все дает. Например у нас листинг товаров куда мы хотим запихать статьи по теме выбранной категории каталога, или по тегам, или по ключевым словам. Например по ключевым словам, то есть фактически мы выведем результаты поиска в публикациях, а значит надо либо сразу расшириться до класса поиска, либо для каталога написать такой, где, собственно, поменять только метод where.
Где-то в классе каталога в фазе подготовки данных (модели) профтыкаем
$news = new CSearchNews();$news->query($item);
И теперь когда этот $news окажется в конкатенации рендера каталога, то, если там есть что показать - $news покажет через свой __toString(), а если нечего - покажет пусто.
$item = это небольшой массив который делается по запросу к классу отвечающему за урлы. Мы же должны из example.com/news/article_foo_about_bar_and_some_baz получить соответствующие данные из дерева сайта. Получаем и кладем в $item. Имя сугубо условное.
Если читатель цитирует коды с global, то случай заведомо неоперабельный. Это я по своему опыту переписки на форумах программистов давным давно знаю. ---------- Добавлено 07.06.2015 в 23:26 ---------- По делу. Класс новостей (статей) на сайте это явный виджет. Ему не нужен контроллер и модель в упор не стучит. Потому что листинг надо мочь вывести в любую врезку, а равно статью вывести в любую секцию. Например выводим листинг релевантный запросу в каталоге. Или печатаем связанную статью под листингом товаров. Ну какой там экшон и в чем разница моделей? Пишется класс со всем скарбом, можно сначала интерфейс, или абстрактный. Потом наследуемся с него под разные нужды, или тупо перечисляем все методы под разные нужды и вперде.
Это "носить вам не переносить", стопудово. Сами найдете первоисточник или поискать за вас?
Нет, надо взять старье, переделать, и залить по новым адресам с новой датой. Это если по озвученному плану.
Есть обычные нормы публикаций. Например опубликована статья от ХХ с заголовком "Кто тут?" Если через неделю выяснилось кто тут - вы ее просто дописываете и ставите дату обновления в дописке и под заголовком дописываете "последнее обновление от Ч". Если еще добавки поступают, неотъемлимые, еще убдейт и так далее.
Именно такая схема принята на любом линейном форуме, включая этот. Просто вы не знакомы в этой культурой и не замечаете.
А если вы перерабатываете статьи, меняете структуру, дописываете, удаляете, картинки-врезки-сноски и тп - такая работа дает новую статью и вы ее публикуете как новую, с новой датой и по новому адресу. По старому адресу надо сделать found на новый адрес и все.
Будет задержка с индексацией, но зто вы покажете себя культурным человеком. ---------- Добавлено 07.06.2015 в 22:35 ---------- Кстати для даты по простому без микро-тегов можно заюзать тег time и вписать в него машинно-читаемую дату, то есть обычно получаемую из бд без локального форматирования.
При чем тут культура. Например я могу отредактировать постинг после того, как после него появилось несколько ответов, или когда уже на него ответили. Технически можно, а культурно - нельзя. Так и со статьями. Кроме того новая статья всегда роботу вкуснее, поскольку демонстрирует жизнедеятельность сайта.
Никто в запросе дату писать не станет, "сегодня" подразумевается конкретно, то есть железобетонно. Остается выдать актуальный курс, предсказание и температуру.---------- Добавлено 07.06.2015 в 22:24 ----------Прочитал ТЗ еще раз и понял что вообще ничего не понял. Начитаются предисловий у тех кто начитался предисловий и тормозят на ровном месте.
По курсам вам ничего не светит, там нормально все перекрыто по любому сочетанию.
Равно как и по погоде. Более того, например гугля выдает и погоду и курс и айпи и дюймы - сам по себе, в рамочке.
Насчет астрологии это может быть, если сумеете удивить видавших видов потребителей этой бредятины.
