Новините от RSS feed излизат като "????" в Joomla

В стандартна инсталация на Joomla 1.0.x (включително и локализираната версия на български от joomla-bg.com) RSS агрегаторът не работи правилно, заради проблеми с encoding-a и резултатът обикновено е следния:
Въпросителни в имената на статиите и в линковете.
След известно търсене по форумите видях, че проблемътът се състои в com_newsfeeds компонента и по-специално във файла newsfeeds.html.php, който се намира в /components/com_newsfeed/ подпапка.

Вече не си спомням от къде в Интернет намерих patch за горния проблем. Ето го и самия patch:

newsfeeds.html.php
В общи линии е това. След като се сложи файла, резултатът вече е доста по-приемлив, а именно:

Компресия на трафика по TCP/IP връзка

Почти всяко уважаващо себе си бизнес приложение в наши дни използва връзка с база данни. Ако БД е на същата машина въобще не се замисляме за трафика, който се генерира, но ако свързаността е слаба (през Интернет чрез VPN или просто директна връзка с отдалечена машина), то това може да се превърне в сериозен проблем.

Разбира се, винаги има вариант да се оптимизира приложението и да работи с по-малки обеми от данни, но това изисква допълнително време и ресурси и рядко е лесно изпълнимо.

Едно друго и лесно решение за компресия и криптиране на връзката се дава от един open-source продукт - Zebedee. Последната версия е от 2005, но това съвсем не пречи да работи точно както се очаква:) . Сред хубавите черти е и това, че работи под Windows (като application и service) и под Linux.

Нека най-общо имаме следната конфигурация:
Клиент <----> Сървър
като целта е данните, които се предават между Клиент-а и Сървър-а да са компресирани максимално.
Ще предполагаме, че на машината Сървър е стартиран Firebird server, който работи на порт 3050 (Разбира се - може да е всяко приложение, което слуша на TCP/IP port)

Инструкциите за подкарване на Zebedee се състоят в едва няколко точки:
1. Официалният сайт е : http://www.winton.org.uk/zebedee/ . От там може да се свали последната актуална версия 2.4.1 или 2.5.3
2. Инсталира се на машината клиент и машината сървър
3. На машината сървър се подсигурява порт 11965 да не е филтриран или блокиран от firewall (този порт може да се настрои при необходимост)
4. На машината сървър се стартира следното:
c:\program files\zebedee\zebedee -s -z 9
(При условие, че zebedee е инсталиран в директорията по подразбиране)
-z 9 ще осигури максимална компресия, което е достатъчно добре за всички ситуации, пък и при сегашните процесори не си заслужава да се използва по-ниска степен на компресия.
За получаване на повече статистическа информация може да се постави и параметър -v 4 и -d (за да не се detache-не от конзолата и да продължи да плюе информация)
5. На машината клиент се стартира следното:
c:\program files\zebedee\zebedee -z 9 8000:<сървър>:3050
(При условие, че zebedee е инсталиран в директорията по подразбиране)
6. Навсякъде, където досега сме се връзвали към <сървър>:3050 сега трябва да се връзваме към localhost:8000.

Горното е съвсем базов пример, колкото да се подкара и да се види, че работи. Допълнително може всички настройки да се изнесат в конфигурационен файл и да не се въвеждат на командна линия.
Другите възможности, които заслужават интерес са:
- работа като Windows service
- криптиране на връзката
- смяна на порта на тунела
- други

Ето и dump как се представя компресирането през zebedee за няколко минути работа с база данни през Интернет:
....
zebedee(2324/3028): read 53959 bytes (63560 expanded) in 1592 messages
zebedee(2324/3028): wrote 326821 bytes (1306955 expanded) in 1702 messages
....

Или в крайна сметка използването на zebedee ни позволява да намалим трафика в едната посока 4-кратно ! А това автоматично означава приложения, който са по-responsive и с по-бърз достъп до данните.

Update1: 

Стартиране на zebedee като service се прави чрез изпълнението на следната команда

zebedee -n "Zebedee Server" "-Sinstall=c:\server.zbd"

Горното ще създаде windows service с име Zebedee Server и ще прочете конфигурационния файл от c:\server.zbd - трябва да е указан пълния път до файла!

Българска локализация на setup project във MS Visual Studio 2005

Visual Studio 2005 предоставя инструменти за лесна направа на инсталации под формата на Setup/Deployment project. Сравнително лесно се правят инсталации, които са straight-forward и не изискват някаква сложна логика. Поддържат се и предварителни изисквания (prerequisites), custom actions както и ред други благини.
За съжаление няма българска локализация и още по-лошо - няма никаква локализация, която да поддържа кирилица. Проблемите, които произтичат от това са няколко:
- създадения инсталатор изглежда непрофесионално; опитваш се да предложиш продукт, а се инсталира на латиница. Тук имам предвид стандартните съобщения като ОК, Cancel надписите на бутоните
- design time се предоставя известен набор възможности за въвеждане на разни текстове като ProductName и др. За съжаление, ако се въведат на кирилица излиза warning, а run-time на същото място излизат ??????.

Има и други такива, за които всеки, на когото му се е налагало да използва може да сети и сам.

Какво може да се направи?
Накратко начина, по-който може да се кирилизира инсталатора не е лесен и изисква известни усилия, но в крайна сметка се постига желания резултат.

Като начало се инсталира Windows SDK Components for Windows Installer Developers от http://msdn2.microsoft.com/en-us/library/aa370834.aspx
От тук използваме инструмента Orca, който най-общо може да редактира ресурсните таблици на MSI файл, както и няколко скрипта в подпапка Samples\Scripts

- Генерираме setup project-a от Visual Studio 2005. Обикновено той се състои от setup.exe и някакъв msi файл
- С помощта на Orca отваряме msi файла. Тук в зависимост от сложността на инсталацията може да се наложи да се експортират доста таблици от меню Tables->Export tables, но за по-прости setup проекти нужните таблици са:
Property.idt - обща информация за проекта като ProductName и други такива
Control.idt - текстовете по контролите и диалозите
RadioBut.idt - текстове на радио бутоните
- Превеждаме тези таблици както намерим за добре
- Кодовата таблица на msi setup файла, трябва да се промени на 1251, за да работи правилно с кирилица
WiLangId.vbs .msi codepage 1251
- Обратно импортиране на преведените таблици обратно в msi файла
WiImport.vbs .msi <път до idt файловете> Property.idt
WiImport.vbs .msi <път до idt файловете> Control.idt
WiImport.vbs .msi <път до idt файловете> RadioBut.idt
.....

Вече е всичко готово и MSI файлът е локализиран успешно!

Както може да се види обаче, процесът е доста дълъг и неприятен. Да се следва тази процедура при всеки build е крайно досадно и скучно.
Може да се ускори значитено като се поставят някои команди в Post-Build Property-to на самия проект, а именно първо се добавят следните файлове към проекта
- WiLangId.vbs, WiImport.vbs (те се намират в Windows SDK Components for Windows Installer Developers пакета в подпапка Samples\Scripts)
- всички idt файлове, които са нужни за проекта
- в Post-Build Property се добавят тези редове:
cscript "$(ProjectDir)WiLangId.vbs" "$(BuiltOuputPath)" codepage 1251
cscript "$(ProjectDir)WiImport.vbs" "$(BuiltOuputPath)" "$(ProjectDir)" Property.idt
cscript "$(ProjectDir)WiImport.vbs" "$(BuiltOuputPath)" "$(ProjectDir)" Control.idt
cscript "$(ProjectDir)WiImport.vbs" "$(BuiltOuputPath)" "$(ProjectDir)" RadioBut.idt


И това е всичко.
Вече след всеки build автоматично проектът ще се кирилизира, ресурсните таблици ще се импортират обратно в него и се получава един красив български setup project!

Както обикновено се случва - всеки метод има някои недостатъци. Най-общо това са:
- ако се промени нещо по интерфейса (добави се нов стандартен диалог към проекта например) е нужно ресурсните таблици да се прегенерират и да се merge-нат към вече преведените
- при промяна design time на properties те не се отразяват, защото... се замазват от преведените ресурсни таблици. Решение за това е промените да се правят и в Proprty.idt

Като заключение ми се струва, че Microsoft не са обмислили setup projects (за момента, може би в VS 2008 ще е различно) и освен проблемите с локализацията има и доста недъзи по самия процес на направа на проекта....
Е имат и доста добри неща - най-вече добрата интеграция с Visual Studio :))

Как да направим Delphi 6 приложение, което да използва .NET Web Service

Започваме с реализацията на уеб метода на .NET във Visual Studio 2005. За да е съвсем ясно, за пример използвам един доста прост метод, който има за цел да направи log-in и връща като резултат дали потребителят има права.

[WebMethod(EnableSession = true)]
public bool LogIn(string aUserName, string aPassword)
{
bool IsAuthenticated;
// проверка дали дадения потребител се оторизира
....
return IsAuthenticated;
}

Предполагаме, че web service-a вече е качен на IIS/Cassini и е достъпен като http://localhost/test/Service.asmx


В Delphi 6 има wizard, който генерира прокси клас за работа с уеб услуги и той е достъпен от:
File->New->Other->Web Services

Стартира се WSDL Import Wizard-a и в началото се налага да се въведе WSDL кода, който за голяма радост се генерира автоматично от .NET чрез извикване на (за текущия пример):
http://localhost/test/Service.asmx?wsdl

Общо взето тук следва единствено натискане на Finish бутона и в крайна сметка получаваме един хубаво генериран proxy клас за работа с web service-a!

Вече може да поставим THTTPRIO компонентата за работа с web services и да се започне същинската работа.

Едно съвсем просто приложение би изглеждало така:


като настройките на THTTPRIO да показани тук:

И тук идва една малка изненада, тъй като .NET Web Services очакват параметрите си по различен начин отколкото е стандартния за Delphi, поради което е нужно да се добави следния ред в автогенерирания код на прокси класа:

initialization
...
InvRegistry.RegisterInvokeOptions(TypeInfo(ServiceSoap),ioDocument);
...

Вече няма проблеми с извикванията на .NET web service-a от Delphi код и се връща правилния резултат!