Блогът на Ладжър

Владислав Косев,
Development Manager

Скоро имах разговор с човек, който се интересуваше от нашата платформа Елементс и беше чел описанието, публикувано тук. Тъй като въпросите бяха много интересни и явно имаше какво се дообяснява, се възползвам от възможността да публикувам част от обясненията тук.

---

Елементс е силно специализирана платформа, т.е. по това се различава от другите платформи - не можеш да си направиш някакви PHP скриптове и просто за забодеш платформата отдолу. За Java не съм много компетентен да говоря, защото не я познавам, но ADO-то е само data access, Elements e цялостно от data access-а, през интерфейса, та бизнес логка - всичко, все едно комбинацията .NET - Windows Forms - всички такива приложения изглеждат еднакво (игнорирам факта, че можеш да си пишеш твои контроли и да къстъмизираш тук-таме).

В Елементс няма нищо „общоупотребявно”, всичко е писано специално за целта, целия код е наш. Всичко е обектно-ориентирано написано - с класове.

Значи нещата са горе-долу на 3 слоя, що се касае обектите - data access, business logic, и UI. Първите два са заедно, в т.н. бизнес обекти, второто е в отделни класове за всеки интерфейс (примерно UI.Client.List.php за списъка на обекта Клиенти). Под тях имаш Core класовете на платформата (все едно .NET). Отделно има UI част към платформата с разни интерфейсни контроли (разбирай все едно Windows Forms), върху които стъпват всички интерфейсни класове на обектите - списъци, форми, и т.н.

“Колко е трудно да се пише XML-а, как изглежда генерирания код и дали лесно се променя и къстъмизира?”

Гледай сега, ти като започваш ново приложение (или нов обект, все тая), ти си правиш XML-а, описваши си вътре всичко - характеристиките, формата, списъка, свързаните обекти, всичко. Посто само го генерираш - той си прави таблиците, генерира си кода, регистрира се където трявба, всичко. Генерирания код не е предвиден да се коригира, защото като прегенерираш и го губиш. За целта обекта е „разслоен” на 3 слоя - един генериран (C__Client), един за базов код (C_Client) и един за къстъм код (CClient), които се наследяват взаимно. Базов и къстм код се отнасят за приложения, които ползваш с малки модификации на различни места - в базовия ти стои общото меду приложенията, в къстъм кода ти стои това, което е характерно само за дадено приложение. Трите класа не са задължителни, можеш да караш само с генерирания код - реално след генериране имаш готов обект за ползване - има си списък, има си форма, има си методи Add, Edit, Delete, може да си има статуси, всичко си му работи. Това, което прави, е да тъпче таблицата с данни. Можеш да си генерираш един куп неща, които редовно се ползват и се различават от просто „тъпчене” - autocomplete на полета едно от друго, свързване на полета (напрмиер полето Държава филтрира полето Град) и всякакви такива благинки. Оттам нататък, ако ти трявба къстъм код - например някакви нестандартни функционалности (например копче „Плати”, което прави плащане и сменя статус), просто си ги пишеш в бейс или къстм класа. Ако ти потрябва ново поле, просто си го добавяш в XML-а и прегенерираш. Т.е. XML-а не е за one time use, ти непрекъснато си прегенерираш и си го ъпдейтваш. Не можеш да започнеш от съществуваща база, при генерирането тя се съзадава при определени изисквания (ти реално можеш, но трябва да знаеш точно къде какво да сложиш и как да го именоваш). Като ти потрявба някакво къстъм query, просто си пишеш SQL. Генерирания код ти оправя главно Add/Edit/Delete/List операциите, за другото се оправяш сам.

„Как се прави version control на custom applications разработени през интерфейса на платформата?”

Ами за те са си файлове. Значи има експериментална функционалност за side by side версии на едно приложение, но оттам нататък сте си вие.

„Какво ще правите след като Adobe пенсионират SVG viewera догодина?”

Ами или Flash или Silverlight.

“Има ли обособен ORM, или има само CRUD за вашите си обекти?”

Относно ORM - доколкото схванах от четене по темата, това са обекти, които репрезентират релационна база данни. Нашето не е точно CRUD. Да, имаш перфектен съпорт на операциите с базата (CRUD), но към всеки обект имаш TypeDescriptor, от който можеш да получиш всичката информация, която съдържа обекта - какви полета има, какви са му релациите и с кого, как точно се филтрират тези релации (например обекта Client има връзка с Order, но с цел да покажеш списъка на поръчки към даден клиент по някакъв универсален начин, трябва някой да ти provide-не филтъра как се образува - в този случай: Order.ClientID=[parameter] например). Също така кой е PrimaryKey-а, абе всичко. Освен това тези бизнес обекти абстрактват повече от database логика - например т.н. “multiple” пропъртита - един клиент има повече от една категория, което очевидно се решава с релационна таблица между Client и Category. За бизнес обекта това продължава да си е едно пропърти, просто се хендълва различно. Освен това има много силно развита концепция за наследяване - например: имаме клиенти, доставчици, подизпълнители, банки и т.н.; всички те логически са контрагенти и като такива имат общи характеристики и функционалности и би следвало да има и общ списък. Елементс решава проблемът по следния начин: имаш таблица Contractor, която съдържа общите характеристики; после имаш таблици за Client, Supplier и Bank, които имат 1:1 релация с Contractor и съдържат характерните пропъртит само. В случая, за да добавиш клиент, практически правиш запис в 2 таблици минимум - Contractor и Client. На ниво PHP това са 2 класа, които се наследяват, и съответно имаш всички бенефити на стандартното наследяване. Когато конструрираш new CClient() клас и му насетнеш некви характеристики и викнеш Update(), Елементс сам си добавя записите където трявба и изобщо хендълва цялата логка по работата с тия данни вместо тебе. Има наследяване и на интерфейсно ниво и т.н.

“Това нещо върви ли на Linux или Windows сървъри?”

Ние си харесваме BSD-то :). Имаме клиенти, които са подкарвали успешно всичко на Slackware и RedHat, но пък сме имали бесни проблеми с Debian например, но предполагам, че всичко опира до добър администратор, защото Елементс не иска нищо друго, освен добре инсталирано PHP, eAccelerator и разни нормални библиотеки, заедно с някакъв web server. Но понеже това са “open source” истории, те се различават за всички операционни системи достатъчно, че да ти причинят главоболия - segmentation faults (личните ми фаворити) и всякакви други подобни. И така.

“Всичко, което описва класове/контроли/база и т.н. е в конфигурация (xml файлове), а в базата не отива никаква application configuration information, нали така?”

XML файловете не са конфигурация, гледай ги като дефиниция. В базата има конфигурации, но това са такива, които потребителя може да променя (разбираемо, нали). Другото сме го изнесли във файлове, които се генерират, поради deployment съображения. Дори работим по идея, която ще разреши да копираш файловете някъде и то да си направи базата от нула със всикчки дефолтни записи и тям подобни неща, защото деплойването на промени по базата е един от най-големите бичове за нас.

“Трудно ли се мигрират данни?”

Значи мигрирането на данните не е кой знае какво, защото ние не сме си измислили някаква нова система за релационна база данни - тя си е ясна. Просто има определени конвенции за именоване, искаме си Foreign Keys и разни други дребни неща, но горе-долу това е. Но трбява да си го направиш ръчно. Ако не променяш структурата на съществуващото приложение всичко е окей, но пък Елементс взима определени решения за решаване на конкретни проблеми - например това, което ти описах за multiple пропъритата, което може да се различи с вашите. Но като цяло действаме като по учебниците :).

“Има ли API/възможност business objects сами да си говорят с базата, ако не наследяват от вашите data access класове?”

За толкова много ERP-та върху Елементс и още повече администрации на уеб сайтове не ни се е наложило да пишеме къстъм „приказки” на обекти с базата, не виждам защо и на някой друг ще се наложи. Освен това в Елементс има концепцията за Events – понеже в PHP концепция за делегати няма, ние общо взето си направихме такава. А всички обекти fire-ват AddComplete и EditComplete събития, както и можеш да Override-ваш Update метода, можеш да си симулираш get и set на характеристики така че имаш инструменти за къстъмизация на положението, не е като да няма. Имай предвид, че ние написахме платформата заради приложенията, не е обратното, тя се е развивала от нашите нужди, а смятам, че ERP-тата, бидейки сред най-големите приложения, покриват достатъчно много случаи. А и ние не обичаме да обикаляме проблемите, а да ги решаваме.

За къстъм бизнес обекти – мога да ти дам примера със справките – там имаш някакви ултра бясни queries, и като цяло имаш само интерфейсна част. Това няма смисъл да минава през бизнес обект, Елементс просто ти генерира скелет (който е нужен от гледна точка той да има информация що е то, като се касае до менюта, права и тям подобни информации), но оттам нататък, ти си пишеш бясното query и си го показваш или в списък, или като графика или по някакъв друг безумен начин.

Къстъм класове можеш да си добавяш на воля – ние имаме разни такива за разни приложения писани, които вършат общи задачи или държат информация просто, която се предава между обекти. Но бизнес обект да пишеш къстм просто не виждам смисъл – остави Елементс да ти генерира работата с базата и интеграцията със системата, пък ти си лющи после бизнес логика отгоре на воля.

Къстъм контроли можеш да си правиш, има заложена функционалност за това. Можеш да си комбинираш вече съществуващите само със сървърен код (както обикновено правим ние), а можеш да си комбинираш разни текстбоскове и комбота – ти си решаваш. Има си базов клас за такива неща. Контролите, които са binary-та, и правят HTTP заявки си се оправят в живота относно кодиране, декодиране и т.н. – даже имаме поддръжка за клиентски сертификати. Може би ако питаш нещо конкретно, ще мога да ти кажа по конкретно дали може или не – тъй общо ми е трудно да ти опиша какво може и какво не може.

“Как решавате проблеми с конфликти откъм клиентската страна с 3rd party javascript libraries — примерно любимите на всички prototype.js, производните и подобните му?”

Относно JS-а, аз не съм привърженик особен на тия „библиотеки”. Ние бая си умеем JS-а и си пишем каквото трявба сами, защото ако тръгнем да ползваме 2-3 библиотеки, трябва да почнем да се грижим за съвместимости и така нататък. Реално ти техничекси проблем нямаш да използваш каквото ти кефне, защото ние имаме политика при писането на такъв код с „namespaces” (var Clients = {}; Clients.DoSomething = function(){…}), въпреки, че има разни глобални функции, те са в друг Frame и оттам не би следвало да колидират с твоя код. Така че не виждам проблем. Но Елементс ползва доста js и добавянето на цяла библиотека може би ще има performance cost, но това са ми само размишления, не сме го пробвали никога. А и честно да ти кажа, имаме разни стандартни фунционалности – като например да извикаш метод на сървърен клас, да му пратиш аргументи и да получиш резултат, или да го конструираш и да си му имаш пропъртитата в клиентския скрипт и даже е желателно да се ползва това, вместо да си пишеш свое такова, защото то си е интегрирано и измислено така, че да работи добре с платформата и да е ефективно. Но пък никой не те спира да правиш каквто си искаш :).