Колко уникални URL адреса могат да бъдат направени за представянето на една секция? Това е Case Study за разработката на динамичността на URL адресите на сайта на туристическа агенция Business Travel Agency.
Сайтът на Business Travel Agency предоставя възможност за преглед на различни типове екскурзии, почивки, хотели, онлайн резервации и други туристически услуги. Съдържанието на сайта се управлява от CMS приложение базирано върху платформата Elements.
За доброто SEO на сайта е от изключително голяма важност точността на url адресите спрямо съдържанието на страницата, в която се намираме. Също така е важно да запазваме контекста в който сме – ако се намираме в определена екскурзия, желателно е в URL адреса да са включени детайли за нея (тип на транспорта, програма към която е се отнася екскурзията). Това от своя страна води до увеличаване на броя на уникалните страници, което е радушно прието от всичките Search Engine-и, тоест принципът тук е колкото повече – толкова повече. От друга страна тези url адреси са добре приети и от потребителите, защото с един поглед става ясно позицията им в сайта и информацията, която се вижда всъщност за какво се отнася.
В даденото case study няма да разглеждаме технологията с която е реализиран mod_rewrite-a или други специфични технологични процеси за реализацията, а чисто концептуално ще обърнем внимание върху принципите по които сме се водили при реализирането на проекта.
Интересен момент е поставянето на една екскурзия в различен контекст, тоест секция с един и същ код в URL адреса (new-year-in-istanbul-bosfora), може да бъде поставяна в различен контекст. В един случай екскурзията ще бъде представена като автобусна, в друг като екскурзия със собствен транспорт или със самолет, но реално това е една и съща екскурзия, представяща информация според типа на транспорта, в чиито контекст бива разгледана. От друга страна всяка екскурзия е част от програма (например програма „Нова година 2009”), като всяка програма може да има няколко типа транспорт, а всяка екскурзия може да бъде към няколко програми. Стана малко сложничко, затова ще резюмирам случая. Имаме следните 3 нива: тип транспорт, програма, екскурзия, като релацията между трите е много към много. Какво се случва с URL адресите в този случай, очевидно за всяка една екскурзия, за всяка една програма, за всеки тип транспорт ще имаме URL, показващо една и съща секция, в която трябва да знаем контекстите до самото начало, за да определим точно кое съдържание да покажем, което реално е малък проблем, но за него ще стане дума по-надолу в case study-то. Какво се получава до този момент - получили сме n на брой уникални URL адреси, водещи към една и съща секция, но филтрираща съдържанието според отделните части на адреса, пример – имаме екскурзия, която има следните характеристики (схематично):
Тази екскурзия участва в две програми и се предлага с 3 типа транспорт, като цената и условията са различни за всеки тип. Тъй като сайтът може да се разглежда както по програми, така и по типове транспорт, получаваме следните контексти за преглед на нашата екскурзия:
• Тип транспорт – тръгнали сме да разглеждаме сайта по типа транспорт, видяли сме програмата Нова Година 2009, влезнали сме в прегледа й и там сме намерили нашата екскурзия. Според това от кой тип транспорт сме дошли, ще видим различна ценова информация за екскурзията:
o …bg/excursions/bus/newyear2009/new-year-in-istanbul-bosfora/
o …bg/excursions/airplane/newyear2009/new-year-in-istanbul-bosfora/
o …bg/excursions/individual-transport/newyear2009/new-year-in-istanbul-bosfora/
• През друга програма – не ни е харесала програмата Нова Година 2009 и сме влезнали през друга програма:
o …bg/excursions/airplane/newyear-turkey/new-year-in-istanbul-bosfora/
Всички посочени URL адреси съдържат приличен набор от ключови думи и са достатъчно прости, че да могат да се четат от потребителите на сайта, позитивите са ясни и няма нужда да говорим повече за тях, а ще обърнем внимание на по-сложният момент и той е за разработчиците на сайта. Разгледаният пример е с 3 нива, но той може да бъде с много повече, особено ако се поставят филтри и искаме филтрите еднозначно да влизат в URL адреса, не като GET аргументи, а като част от адреса разделени с “/”, това изключва възможността за hardcode-ване на логика вътре в темплейта на определената секция, защото тя първо ще бъде доста сложна, а от друга страна няма да бъде универсална и може да доведе до ненужно копиране на код от различните разработчици, което е особено неприятно и опасно при разработка на големи проекти. За да може да постигнем унифициране на кода и да постигнем максимално лесно ползване на контекстите в различните случай, още на етап добавяне се записват всички контексти в базата с данни. Към всяко URL реално стои всичката информация нужна за използването на контекстите в публичната част. Момента на добавянето или редакцията на запис е най-удобния момент за определяне на всички зависимости на контекстите, защото въпреки сложната логика за определяне на нужните данни тя стой на едно място и е унифицирана, написана веднъж тя може да понася само оптимизации и bug fixing в определени случай, а така написана тя може да бъде прилагана в множество проекти, защото в някаква степен всеки сайт има нужда от управление на контексти. При промяна на стойност на някой от контекстите, промяната рефлектира върху всички секции съдържащи съответните данни, което значи, че някой трябва да следи за такива събития и да fire-ва съответните събития, за да бъдат постоянно верни данните. В текущия проект за това се грижи платформата Elements, като при настъпване на някое събитие се обработват всички засегнати записи и секции и данните за тях се прегенерират и поставят в базата в таблици с релация едно към едно между таблицата със структурното дърво на сайта и таблицата с данни към тези части на сайта.
Всички примери в описанието са базирани върху реални проблеми срещнати при разработката на уеб сайта на Business Travel Agency http://businesstravel.bg/.
Вашата оценка: