Там другие хитрости могут быть, связанные с изменением структуры кластеров сайта. Прочтите статью, посмотрите, что Вам говорит панель вебмастера. Если удастся сохранить старую структуру для разделов верхнего уровня, бояться, ИМХО, нечего.
andrew2008, а Вы начните, сами все увидите :)
Сохранение урлов - как правило, не проблема. Вы программист, в конце концов, там дел на полчаса будет. 1 - сделать на входе поиск по базе урлов, 2 - подкрутить формирование ссылок. Кстати говоря, может Вам и вовсе не стоит париться с сохранением урлов - сделайте 301 редирект, будет вполне достаточно (тогда не надо возиться с формирование ссылок).
Ну мы-то тем более не уверены, ибо это зависит исключительно от прямизны Ваших рук. В общем случае можно сделать что угодно и на чем угодно. Вставка адсенса не выглядит такой уж грозной задачей :)
В целом, разумеется, использование готовой системы предпочтительнее. Что-то свое имеет смысл делать, если есть понимание, чего именно не хватает в других системах, и есть готовность потратить на разработку хотя бы несколько месяцев (а чтоб вышло что-то достойное - несколько лет). Иначе получаются уродцы. Лень разбираться в чужом коде - плохая мотивация для начала проекта по разработке :)
Приблизительно вот так (скрин, 100кб).
Т.е. после каждого осмысленного действия (~= перед перекуром) исполнитель записывает, что было сделано и сколько времени отняло. Далее, есть вполне очевидная статистика, которая умеет такие записи суммировать - по проектам / исполнителям, и группировать по периодам (неделя / месяц).
Система работает, если в конторе соблюдены некоторые условия:
- сотрудники готовы, что будет видна РЕАЛЬНАЯ ситуация с производительностью, т.е. система не используется для раздачи люлей, иначе будут писать цифры от балды;
- система отображает реальное положение дел, т.е. манагер не забывает снимать неактуальные задачи, принимать (предварительно протестировав) готовые, ставить новые;
- подобран "баланс", как именно дробить проекты на задачи, у нас: разработка - несколько крупных (проектирование, верстка, кодинг, наполнение), поддержка - много мелких.
- данные реально используются, и народ не забывает их вносить.
После окончания внутрикорпоративного холивара Firefox vs. Opera предполагается сделать расширеньице-тулбарчик.
Все это хозяйство находится в состоянии внутреннего инструмента, но никак не продукта (доков нет, код не чищенный, все объяснения - на пальцах). Так что, еще раз говорю, продавать вряд ли будем, по крайней мере сейчас.
Хорошо хоть не елдать...
1. Объяснить нормально, в чем проблема. Нифига не понятно.
2. Если я правильно понимаю, ваш кусок кода вообще не должен работать на 2 и более проходах: вставляемое значение id берется из ключа массива, соотв. во 2й проход не будет уникальным. Если id у вас задан как primary key, должна появляться ошибка. Если нет - у вас будут записи с дублирующимися идентификаторами. Поставьте на поле id autoincrement и вообще уберите его из INSERT-запроса.
3. Капслок не прощают!
Ставлю $5. Мало?
Тогда выслушаю Ваши пояснения насчет функциональности скрипта ;)
Ayavryk, есть еще одна проблема - "сборка" XSLT-шаблона. Ну, можно отдавать на клиент вообще весь шаблон, какой есть, но иногда это сильно дофига. import/include - не знаю, будет ли он по HTTP работать, не пробовал. Кроме того, если проводить не одну трансформацию, а шаблонизировать отдельно вывод каждого модуля (плюсы - легкость кэширования, собственно "модульность", независимость частей приложения), преобразование на клиенте тоже все путает.
Операции, которые грузят SQL, боюсь, на клиент не перекинуть (грузят ведь потому что данных много). Формирование дерева по уже готовой выборки - да, можно делать на клиенте. Конкретно с комментариями - подозреваю, эффективней всего будет строить дерево тупо на пыхе, и отдавать XSLT уже готовое дерево, а не "плоский" список. Но да, не так красиво :)
А что, если не секрет, день сегодняшний?
Фигасе, я думал этот рынок несколько моложе... :)
Пока слабореализуемо. В gecko не работает disable-output-escaping, у других - другие проблемы. Кроме того, неизвестно, как XML-документы будут индексироваться поисковиками (видимо, никак). Были примеры, когда исходное дерево "подгонялось" под xhtml, но это, ИМХО, извращение.
TecHMeaT, мы пользовались UMI, в целом съедобная система, хотя есть у них достаточно спорные и странные решения, и XSLT пока явно "на вторых ролях" по сравнению с их собственным шаблонизатором.
Ну ну...
Не вижу повода для дискуссии. Ссылку на заветный бложек вы воткнули (искренне надеюсь, что тутошним обитателям он не интересен), тему можно закрывать.
К слову, "программист" и человек, который "хорошо разбирается в Интернет-технологиях" ("имеет хорошее представление") - немного разные люди :)
А между тем пример занятный.
Кто найдет донора? :)
Я вот нарыл несколько запросов, по которым находится msn.com НПС и еще 5-10 документов, из которых ни один не является донором. Т.е. в "видимом" индексе Яндекса доноров нет. Запросы публиковать не буду, не при дамах :(
