Se sono sulla stessa macchina, non puoi far leggere direttamente i dati che servono nei database dove sono memorizzati ?Originariamente inviata da jeck
Se sono sulla stessa macchina, non puoi far leggere direttamente i dati che servono nei database dove sono memorizzati ?
si potrei, ma le credenziali di accesso sono diverse, nel caso cambio password poi devo farlo su 2 file, potrei cambiare l'open base dir, ma non so se è la soluzione migliore
Non complicarti la vita, lascia stare l'open base dir. Cambiare password e username su due file è una banalità. E risolve efficacemente il tuo problema.
no infatti, l'open base dir l'ho proprio scartato a priori.
Quindi secondo te anche per altri tipi di implementazione (sempre scambio dati e memorizzazioni nel db dell'altro portale) mi conviene fare in due file separati?
per esempio, ora i due portali danno 2 differenti servizi, ma gli utenti iscritti sono gli stessi, quindi quando si iscrive un utente su un portale in automatico deve finire nell'altro. Ci sono 2 database distinti, quindi ho creato un webservice che permette di spedire i dati da un portale all'altro e fare la memorizzazione. In questo caso le modifiche o nuove integrazioni allo script le ho fatte su un solo file, invece come dici te le avrei dovute fare su due file differenti, con la conseguenza di poter dimenticare qualcosa e commettere più errori.
Io finora ho fatto così, mi trovo comodo, i file hanno direttive comuni alle applicazioni, ne modifico uno in locale e poi lo spedisco via ftp nelle cartelle delle applicazioni che servono. D'altronde se stanno sulla stessa macchina.. perchè aumentare il carico con un webservice di scambio dati ?
Cmq sono curioso, perchè non mi ci sono mai cimentato, con cosa hai creato il webservice di scambio dati ?
ad esclusione del file di configurazione che modificare quello non è un problema, ma la mia preoccupazione è se cambia le esigenze del progetto, che potrei cambiare lo stesso codice su due file differenti per avere lo stesso risultato, io vorrei evitare questo, o meglio cercare di ridurlo al minimo.
Immagina l'iscrizione utente, si trova in entrambi i portali e se fatta nel portale principale deve finire anche nel secondario, e non viceversa. Quindi immaginando che l'utente si iscrive al principale, li ho 2 script identici (o quasi) che fanno la stessa operazione, una dal portale principale e l'altra dal portale secondario. Nel caso cambiano i dati da raccogliere per l'iscrizione,devo modificare 2 script, uno presente nel portale principale e l'altro nel secondario. Invece con webservice, socket xml o altro, ho un solo script che si occupa della memorizzazione, quindi le integrazioni vengono fatte in un solo script, con la conseguenza riduzione di errori. Forse è una mia ossessione, ma come logica mi sembra corretta.
Il webservice l'ho fatto in php e xml. un portale genera un xml con i dati che mi interessa, e li spedisce ad un file php esterno, tale file elabora il file xml con i dati e i comandi da eseguire, i comandi sono i vari metodi della classe. Al termine delle operazioni il file php restituisce un file xml con l'esito delle operazioni.
Premesso che "webservice" mi pare esagerato, la tua logica è corretta (Io uso chiamare webservice i programmi che godono di vita propria, che in php non si possono fare, ma è una cosa mia.. ). Devi aspettarti però che piccole modifiche ai rispettivi siti li dovrai comunque fare in caso di cambiamenti.
Lo script php non gode di vita propria, lo devi avviare tu con una richiesta.
Dato che mi sembra di capire che i dati da passare da un portale all'altro sono poca roba, mi sembra inutile l'uso del file.
L'uso di file xml o altri standard basati su file (anche inventati di sana pianta) è tipico dell'elaborazione in due tempi. Io mando il file, il webservice (che gode di vita propria), quando può elabora il file e mi restituisce un file con i risultati delle operazioni che io ricevo quando ho tempo.
Se è tutto in tempo reale, come php è obbligato a fare, a quale pro doversi scambiare file e non direttamente i dati ?
Ridurresti la complessità e la memoria utilizzata.
Ultima modifica di W Thunderbird; 23-04-2014 a 10:05
Permessi di invio
Rispondi quotando