Witam,

przymierzam się do projektu, serwisu ogłoszeniowego, tyle że dość nietypowego. Chodzi w skrócie o to, aby serwis posiadał centralną bazę danych, ale działał jako dziesiątki niezależnych serwisów. Idea jest taka, że każdy kto będzie chciał będzie mógł sobie postawić na subdomenie taki serwis z częścią lub całością contetntu, która będzie interesowała użytkowników jego witryny + możliwością wykonywania akcji typu dodawanie ogłoszeń (które będą widoczne także na pozostałych stronach biorących udział w wymianie), ocenianie ich itp. Czyli innymi słowy dla postronnego użytkownika odwiedzającego tą strone ma być zwykły serwis ogłoszeniowy.

Problem jaki chcę przeskoczyć to prostota instalacji. Tj. aby osoba, która będzie chciała uruchomić taki serwis mogła to zrobić na zasadzie utworzenia subdomeny i wgrania plików, bez konieczności hostowania bazy, dbania o aktualizacje itp. W aplikacji przewiduje jedynie ingerencję w warstwę wizualną, czyli drobne modyfikacje html szablonu (np. stopki/headera) czy zmianę styli - żadnych zmian w kodzie php itp. W zasadzie takie rzeczy mogłyby być także przechowywane na serwerze centralnym, który serwowałby gotową do wyświetlenia stronę

Teraz pytanie jak najprościej osiągnąć taki efekt? Przychodzi mi do głowy prosta aplikacja php, która będzie pobierała na podstawie url'a całą treść strony z serwera centralnego (powiedzmy przez file_get_content), a wszelkie żądania POST itp serializować i wysyłać do serwera centralnego w kwestii obróbki, ale pewnie można to jakoś bardziej elegancko rozwiązać. Może zrobić klienta w Java Script?

Dodam, że chodzi także o uniwersalność rozwiązania, tak aby można je było odpalić (mowa o wersji klienta, nie serwera centralnego) na każdej standardowej konfiguracji serwera współdzielonego.

PS. Nie będę tego sam pisał - chcę tylko ogarnąć zagadnienie na tyle, aby móc napisać w miarę przyzwoitą wstępną specyfikację.

Myślę że najsensowniejszym rozwiązaniem jest użycie protokołu SOAP lub pokrewnych. Wówczas klient ma pełną kontrolę nad tym co gdzie i kiedy się wyświetla, jednocześnie nie ma możliwości operowania na całej bazie danych. Ponadto korzystając z tego rozwiązania jesteś w stanie kontrolować kto i kiedy używa aplikacji.

Na przykład możesz dostarczyć podstawę używającą jquery jednocześnie klient z pomocą programisty może bez problemu zintegrować twoje rozwiązanie z dowolną aplikacją i wcale nie musi korzystać z ani kawałka kodu html/js dostarczonego przez Ciebie.

Właśnie cała idea jest taka, żeby klient mógł postawić sobie stronę bez programisty. Powiedzmy wrzucić pliki na ftp i tyle.
Ewentualne modyfikacja wyklikuje sobie w panelu. Taki skrypt "wgraj i zapomnij". Oczywiście zakładam dostosowanie do wyglądu strony, ale to da się załatwić css'em + modyfikacją html nagłówka i stopki.

Sam SOAP oczywiście jest dobrym pomysłem, ale pytanie czy jest sens używania, gdy w zasadzie cała strona ma powstawać na centralnym serwerze (raczej nie przewiduje wysyłania danych do klient, z których potem tworzona jest strona, bo to by oznaczało, że aplikacja klienta byłaby dość rozbudowana i będzie wymagała w przyszłości np. upgradu, a tego chcę uniknąć).

Trochę się pogubiłem

Ja rozumiem, jakie jest założenie. W przypadku np SOAP, tworzysz całą aplikację 1 raz klient wrzuca pliki i wszystko działa. Dopóki nie będziesz zmieniał samego API dopóty każdy upgrade kodu obsługującego żądania na serwerze, będzie obejmował wszystkie aplikacje klienckie. A dodatkowym atutem jest to że twój produkt będzie jeszcze bardziej elastyczny. Być może 1/100 klientów będzie chciał aby twoja aplikacja działała w jego środowisku, wówczas na własny koszt będzie mógł sobie to zrobić (mając do dyspozycji dokumentację).

Jednocześnie klient ma pełną kontrolę nad html/css/js (który jest na jego serwerze) nie musząc bawić się w modyfikacje kodu PHP. Co do konieczności aktualizacji u klienta, to brak takowych to raczej utopijna wizja. Prawie zawsze się okazuje że chcesz coś rozbudować gdzieś znajdziesz bug, lub wraz z nową wersją PHP twój kod jest przestarzały lub generuje błędy więc tak czy inaczej trzeba by zaplanować jakiś system auto-upgrade'u.



W takim razie nie jestem pewien jak to dobrze rozwiązać ale jeżeli jest jakieś lepsze rozwiązanie które dają taką samą elastyczność pod względem modyfikacji wyglądu aplikacji to chętnie się dowiem .

Chyba po prostu myślisz o zbyt rozbudowanej aplikacji ;-)

Widzisz, bo tutaj cały problem polega właśnie na tym, że rozwiązanie z SOAP jest po prostu zbyt rozbudowane. Mówiąc wprost produkt będzie przeznaczony "dla Pani Czesi", która prowadzi bloga i chciałaby go wzbogacić o ogłoszenia w swojej tematyce. Opcje jakie będzie potrzebowała pani Czesia to w skrócie:
- ewentualne ograniczenie wyświetlanych kategorii (czyli np. wyświetla tylko ogłoszenia o tematyce x i tylko od swoich znajomych)
- być może (co jest bardzo wątpliwe) p. Czesia będzie chciała trochę upodobnić kolorystycznie ogłoszenia do swojego bloga, lub np. dodać w nagłówku "ogłoszenia Pani Czesi"
Obie te rzeczy Pani Czesia będzie mogła zrobić w panelu na serwerze centralnym. Jak już na prawdę będzie miało być full wypas, to pani Czesia będzie mogła edytować css (też pewnie nie jako plik, ale jako wpis do bazy danych).

Pani Czesia natomiast na pewno nie będzie zainteresowana integracją tego ze swoim blogiem, nie będzie chciała programować, grzebać w API itp.

Czyli jednym słowem, rozumiesz - to nie ma być profesjonalna elastyczna aplikacja, tylko dodatek do bloga/strony, który będzie posiadał minimalne opcje konfiguracyjne, ale za to będzie banalnie prosty do zainstalowania, nawet dla osoby, która nie potrafi nic zrobić samodzielnie w temacie. W skrajnej wersji przewiduję nawet hostowanie subdomeny na własnym serwerze, tak że Pani Czesia jedynie zmieni wpis w rekordach domeny w panelu swojego providera.

Tak na prawdę chodziłoby mi o coś takiego, że klient tylko wysyła żądanie do serwera centralnego po kliknięciu linku coś w stylu {user: czesia; url: abc/add; POST:[...] } i otrzymuje gotową stronę w oparciu o ustawienia użytkownika Czesia. Jedyne co komplikuje sprawę, to to, że użytkownicy na stronie p. Czesi:
- mogą się logować
- dodawać treści/edytować je
- oceniać te treści
itp. Czyli ogólnie wszystko to co robi się na serwisach ogłoszeniowych i ma to być transparentne, tak aby gość Pani Czesi nie wiedział, że tak na prawdę działa na serwerze centralnym.

Rozumiem co chcesz osiągnąć moim zdaniem problem w:



To spowoduje, że nawet jak napiszesz coś takiego w js to będzie to duże, średnio użyteczne i nie będzie działać bez JS rozwiązanie o którym piszę na dobrą sprawę mogłoby się sprowadzić do wklejenia 3 linijek PHP na stronę na której chce się uruchomić tą aplikację. Moim zdaniem takie wstawki w JavaScript są dobre do datków typu addthis ale nie do całej aplikacji ogłoszeń.

Kod do wklejenia poza przerzuceniem plików mógłby wyglądac np tak:

[PHP] pobierz, plaintext 
require_once('ogloszenia/app.php');
$app=new Ogloszenia();
$app->run();
[PHP] pobierz, plaintext 

czy jest to trudniejsze od wklejenia kawałka kodu JS ?

Tak czy inaczej ilu programistów tyle rozwiązań osobiście wolałbym postawić na elastyczność już na starcie niż miałoby się później okazać, że jednak jest ona potrzebna i wszyscy poprzedni klienci muszą zmienić kod na stronie.

A dlaczego nie zdecydujesz się na hostowanie wszystkiego u siebie? Jeszcze mniej roboty dla kienta, a nad wszystkim masz zawsze kontrolę. Google: SaaS

@d3ut3r - hmm no właśnie o taki kod mi chodzi ;-) Muszę trochę poczytać - nigdy nic nie robiłem w SOAP, jedynie proste sprawy w xmlrpc itp. Muszę o tym trochę poczytać.

@Crozin - no w zasadzie właśnie o coś takiego mi chodzi, tylko jak to udostępnić na stronie użytkownika pod jego domeną taką aplikację? Jedną opcją byłoby przekierowanie subdomeny na mój serwer, ale to nie zawsze jest możliwe. Są jakieś inne możliwości?

Bo w skrócie chciałbym uzyskać coś w stylu ogloczenia.paniczesia.pl lub paniczesia.pl/ogloszenia

W przypadku modelu SaaS to Ty musiałbyś udostępniać serwer, a klient jedyne co by robił to podpinał sobie domenę do niego.

Jakiś przykład poza przypadkiem, gdzie klient chce mieć wszystko u siebie? Ale w takim przypadku rozwiązanie z SOAP-em, również się nie zda.

No tu jest właśnie problem, bo ja chcę aby to była część bloga oparta albo o subdomenę albo nawet w domenie bloga. Tak więc typowy SaaS odpada, bo nie każdy ma możliwość np. skierowania subdomeny na inne ip i nie każdy też może chcieć to zrobić.

Chyba, że jest jakiś sposób aby za pomocą skryptu php działać "w tle" na innym serwerze. Stąd właśnie pomysł z tym aby na serwerze był skrypt, który po prostu "pośredniczy" w pobieraniu i serwowaniu treści. Ogólnie po prostu byłby to jakiś taki router, którego zadaniem byłoby przechwycenie żądania get/post, zserializowanie go, przesłanie do serwera centralnego i wyświetlenie treści. Problem byłby zapewne z sesjami itp. - ale pewnie dałoby się to rozwiązać ciasteczkiem na stronie klienta i sesją utrzymywaną w bazie danych.

Nigdy czegoś takiego jednak nie robiłem (nie wiem czy czegoś nie przegapiłem w tym temacie) + nie wygląda mi to na zbyt eleganckie rozwiązanie - raczej jakaś proteza.

Nadal nie rozumiem dlaczego wzbraniasz się przed SOAP'em. Wrzucenie trzech linijek kodu (czy stworzenie wtyczki na bloga) to raczej nie problem. Klient SOAP, może reagować na dowolne żądania bez konieczności "programowania czegoś przez p. Jadzie".

[PHP] pobierz, plaintext 
$soap = new Soap('serwer_centralny');
$soap -> setReqest($_REQUEST);
echo $soap -> getResponse('javascript'); //lub json/html/css/mix itd.. :)
[PHP] pobierz, plaintext 

CuteOne - nie wzbraniam się przed tym rozwiązaniem - tak jak pisałem wcześniej:

[PHP] pobierz, plaintext 
@d3ut3r - hmm no właśnie o taki kod mi chodzi ;-) Muszę trochę poczytać - nigdy nic nie robiłem w SOAP, jedynie proste sprawy w xmlrpc itp. Muszę o tym trochę poczytać.
[PHP] pobierz, plaintext 

Muszę trochę o tym poczytać, bo tego rozwiązania nie znam (w sensie wiem o co chodzi, ale nigdy nie korzystałem). Zobaczyć, czy to bez problemu da się uruchomić na w miarę dowolnym hostingu itp. Jest to na pewno obecnie jedna z opcji jaką rozważam, ale też może ktoś ma inny pomysł.

- soap
- file_get_contents('serwer/request.php?request='.json_encode($_REQUEST))
- <script></script>

To chyba najpopularniejsze rozwiązania, które nie wymagają od klienta wiedzy o programowaniu

Dzięki,

czyli tak:
- file_get_contents - to rozwiązanie wydaj mi się niezbyt eleganckie, ale jego zaletą jest prostota
- js - chyba przy tak rozbudowanym projekcie jak już wyżej pisano, to mogłoby być niewygodne
- soap - to chyba faktycznie będzie najlepsze, ale muszę o tym trochę poczytać i rozpoznać temat. Zawsze SOAP unikałem, bo wydawał mi się zbyt skomplikowany jak na moje potrzeby, ale chyba jednak od tego nie ucieknę, przynajmniej na tyle aby ogarnąć na tyle, żeby zlecić to komuś ;-)