Joomla.it Forum
Joomla! 2.5 (versione con supporto terminato) => Joomla! 1.6/1.7/2.5 => : Oslino 08 Mar 2011, 03:59:02
-
Salve,
ho letto nei vari post che le varie versioni di Joomla saranno rilasciate ogni 6 mesi.
A luglio è prevista l'uscita di Joomla 1.7 per essere seguita a breve dalla 1.8.
Da quel che leggo la 1.6 ha avuto una pesante riscrittura del codice (così come tra la 1.0 e la 1.5, e tra la 1.5 e la 1.6). Se sarà così anche per la 1.7, 1.8, ecc. ogni volta ci sarà l'obbligo di sviluppare nuove estensioni native.
Chi ha Joomla 1.5, se vuole stare al passo, deve provvedere alla migrazione, alla riscrittura dei template, attendere le nuove estensioni... e a parte il tempo e il lavoro per fare tutto ciò... dopo 6 mesi deve ricominciare tutto da capo!
Non è che questo porta a demotivare le persone ad usare Joomla? E ancora peggio.. non è che demotiva gli sviluppatori a rilasciare nuove estensioni (quantomeno gratuite) sapendo che di lì a 6 mesi dovranno rifarle?
E' giusta la mia valutazione o c'è qualcosa che mi sfugge?
Voi che ne pensate?
-
Ti sfugge il fatto che la 1.6 è stata creata lasciandosi alle spalle una notevole quantità di codice legacy per un motivo ben preciso.
Quindi nel 99% dei casi le nuove versioni maggiori (1.7,1.8, ecc ecc) saranno appunto "semplici" aggiornamenti e non "migrazioni".
-
Da quel che leggo la 1.6 ha avuto una pesante riscrittura del codice (così come tra la 1.0 e la 1.5, e tra la 1.5 e la 1.6). Se sarà così anche per la 1.7, 1.8, ecc. ogni volta ci sarà l'obbligo di sviluppare nuove estensioni native.
Ciao Oslino,
no, quello che hai scritto non è vero. La 1.7 non necessiterà di grandi modifiche per le estensioni e l'aggiornamento dalla 1.6 sarà relativamente semplice.
-
Ciao Oslino,
no, quello che hai scritto non è vero. La 1.7 non necessiterà di grandi modifiche per le estensioni
In teoria se le estensioni seguono correttamente l'MVC non dovrebbere servire cambiare nemmeno una riga di codice.... in teoria! ;D
-
Speriamo che questa sterzata serva a qualcosa.
Quando si passò dalla 1.0 alla 1.5 gli sviluppatori iniziarono immediatamente ad aggiornare i loro componenti ed a produrne di nuovi.
Ora che la 1.6 è fuori da parecchio tempo, ancora non si vede quasi nulla.
-
Speriamo che questa sterzata serva a qualcosa.
Quando si passò dalla 1.0 alla 1.5 gli sviluppatori iniziarono immediatamente ad aggiornare i loro componenti ed a produrne di nuovi.
Ora che la 1.6 è fuori da parecchio tempo, ancora non si vede quasi nulla.
veramente è tutto l'opposto!
dalla 1.0 alla 1.5 trovavi più roba solo perchè nella 1.5 c'è il plugin legacy.
Le 1.5 "native" restano poche in rapporto al tempo di vita della 1.5.
Invece con 1.6 si trovano molte più native già da subito!
E' la mancanza del supporto legacy che ti fa sembrare che per la 1.5 ci fosse più roba.
-
Non mi pare Simbus, dove le vedi queste cose native per 1.6???
Temi si e no il 10%, Editor 2(!), componenti appena appena complessi... manco uno.
O tu hai un repository personale o non so davvero come tu possa dire che vi sono addon nativi 1.6 in abbondanza.
Per la 1.5 già a tre mesi dall'uscita c'era parecchia roba nativa, e tutti i developer iniziarono immediatamente ad aggiornare il proprio software.
-
Evidentemente non hai capito cosa ho detto.
Io vedo 890 estensioni sulla JED (più altre che sono in giro per i siti degli sviluppatori) "native 1.6"
http://extensions.joomla.org/extensions/advanced-search-results/258643
A un mese dall'uscita della 1.5.0 a quel numero non arrivavano neppure le "Legacy 1.5".
-
Speriamo comunque funzionino , bene, al momento sono rimasto scottato con l'aggiornamento alla 1.6.1 , tranne il sito senza template e con sole 2 estensioni che continua a funzionare bene, gli altri ho avuto problemi, su due ho reinstallato la 1.6 e su uno la 1.5.22 per paura che l'aggiunta di alcune estensioni utili mi creino nuovamente casini, purtroppo irrimediabili, in quanto uno dei problemi era la impossibilità di disabilitare e disinstallare estensioni e template. Allora il problema futuro potrebbe essere (io avrei potuto disabilitare tema e estensioni, ho sbagliato a non farlo prima di aggiornare ma mi ha tratto in inganno l'aggiornamento ben riuscito del primo sito) che aggiornando si creino problemi, o che avndo su un template magari pagato perchè ha caratteristiche che ci servono, poi installi un aggiornamento e non ti funziona più o sei costretto ad abbandonarlo. Come invece si spera negli ultimi aggiornamenti della 1.5 non c'erano problemi.
-
Simbus, la definitiva della 1.6 è uscita tre mesi fa e non un mese addietro.
La RC1, ossia la prima versione sufficientemente stabile da permettere un lavoro di sviluppo dei componenti, è invece disponibile da circa un'era geologica...
-
La RC1, ossia la prima versione sufficientemente stabile da permettere un lavoro di sviluppo dei componenti, è invece disponibile da circa un'era geologica...
:o
-
Alex, 4 mesi per adattare alla nuova rel ti sembrano pochi? la RC1 è uscita nella prima metà di Dicembre, se non erro.
Io il mio primo sito lo feci con la 1.5 che era uscita da un paio di mesi, ormai molti anni fa, ed i porting 1.0 -> 1.5 dei componenti importanti erano ormai a buon punto.
Le versioni legacy si usavano quasi esclusivamente per comodità di chi aveva i siti già impostati e non perchè ve ne fosse una reale necessità, ed infatti il mio lupoide.org (che forse ricorderai nei contest dei siti joomla) era fatto tutto con componenti nativi, e ne aveva tanti!
Qui cavolo non c'è neppure un editor funzionante al 100%.
-
ma hai mai provato a scrivere un componente per Joomla che sia un minimo complesso e articolato?
Il tutto poi ovviamente solo per divertimento per poi donarlo alla community e non guadagnarci niente, lavorandoci di notte e nei ritagli di tempo........ ci vogliono anni, non mesi.
Anche la mancanza di documentazione ufficiale sullo sviluppo incide molto su questi tempi.
Il team ufficiale non è ancora riuscito a terminare le schermate di help dell'uso normale di Joomla, ci vorrà ancora molto prima che sia disponibile della buona documentazione sulle API e sullo sviluppo per Joomla 1.6, e necessitiamo dell'aiuto di tutti per realizzare questa documentazione.
-
Alex, 4 mesi per adattare alla nuova rel ti sembrano pochi? la RC1 è uscita nella prima metà di Dicembre, se non erro.
Io il mio primo sito lo feci con la 1.5 che era uscita da un paio di mesi, ormai molti anni fa, ed i porting 1.0 -> 1.5 dei componenti importanti erano ormai a buon punto.
Le versioni legacy si usavano quasi esclusivamente per comodità di chi aveva i siti già impostati e non perchè ve ne fosse una reale necessità, ed infatti il mio lupoide.org (che forse ricorderai nei contest dei siti joomla) era fatto tutto con componenti nativi, e ne aveva tanti!
Qui cavolo non c'è neppure un editor funzionante al 100%.
Quante falsità e prepotenza.
- Joomla 1.5.0 è uscita nel Gennaio 2008, non "molti anni fa".
- Joomla 1.6.0 è uscita il 10 Gennaio 2011, DUE mesi fa, non tre.
- RC1 aveva la feature freeze, ma ciò non vuol dire che fosse buona come base di sviluppo (e infatti il changelog è IMMENSO). Ed è uscita il 14 Dicembre 2010, quindi TRE mesi fa.
- Editor per Joomla 1.6? Non sai usare nemmeno google? JoomlaCKeditor va BENISSIMO, e pure JCE va benissimo con la 1.6.
Tu mi sembri uno che si lamenta tanto di un progetto opensource e gratuito per chi lo usa ma... come stai collaborando?
-
Alex,
credo di poter dire che di roba ne scrivo di più complessa rispetto ai componenti per Joomla, dal momento che è sviluppando software che mi guadagno da vivere.
Ma non è della difficoltà che sto parlando, solo della differenza di tempistica fra quando si passò dalla 1.0 alla 1.5 rispetto alla migrazione attuale.
Qui non si tratta di riscrivere da zero i componenti, il che giustificherebbe sicuramente il ritardo, ma di adattarli alle nuove API che non credo essere totalmente differenti dalla versione precedente, no?
Simbus,
vero e chiedo scusa, sono 2.
Però:
- Gli editor online puoi usarli tu e non gli utenti... specialmente se su un sito hai decine di redattori.
- CKe va benino e non benissimo, e difatti non è ancora in final.
- JCE idem.
- Gli editor di default sono buoni per giocare.
Quando sviluppi, quello che conta è avere la freeze, che ti mette nelle condizioni di poter linkare al sottostante. Gli affinamenti ed il debugging finale puoi farli in seguito.
Come collaboro? Inviando soldi al team di sviluppo e tenendo offline il sito (che è a pago) per trovare le cause del bug che presenta... e tu?
-
Qui non si tratta di riscrivere da zero i componenti, il che giustificherebbe sicuramente il ritardo, ma di adattarli alle nuove API che non credo essere totalmente differenti dalla versione precedente, no?
è qui la magagna.... che di estensioni veramente native 1.5 non ne esistono molte, queste si necessitano di una riscrittura ma essendo già MVC il procedimento è più lineare.
Ovviamente non puoi aspettarti un docman od un virtuemart od un sobi2 ecc... per Joomla 1.6 perchè non hanno niente di MVC e sono molto complesse da riscrivere da zero.
-
Ecco, questa inizia ad essere una risposta seria Alex.
Domanda: la struttura della 1.6 è uguale a quella della 1.5, ossia separata in tre blocchi logici?
Altra domanda, che non ha nulla a che fare (perdona l'OT), a livello teorico, i blocchi logici alla base della 1.5 potrebbero essere distribuiti su macchine differenti, con un canale IPC che li collega; qualcuno ci ha mai provato?
L'utilità? Ci sarebbe, ci sarebbe...
-
nella 1.6 è cambiata molto rispetto alla 1.5 la struttura del database e molte funzioni ma rimane MVC come la 1.5, mentre non saprei risponderti sul secondo quesito della distribuzione dei blocchi logici.
-
Simbus,
vero e chiedo scusa, sono 2.
Però:
- Gli editor online puoi usarli tu e non gli utenti... specialmente se su un sito hai decine di redattori.
- CKe va benino e non benissimo, e difatti non è ancora in final.
- JCE idem.
- Gli editor di default sono buoni per giocare.
Quando sviluppi, quello che conta è avere la freeze, che ti mette nelle condizioni di poter linkare al sottostante. Gli affinamenti ed il debugging finale puoi farli in seguito.
Fino a prova contrario l'editor in joomla è quello che si usa per CREARE I CONTENUTI.
E vanno sia in backend che in frontend. Da MIGLIAIA di redattori contemporaneamente, se il tuo server li tiene.
Poi le frasi "CKe va benino e non benissimo, e difatti non è ancora in final" mi fanno veramente ridere.
Un software non è mai "final", bug e nuove feature vengono sempre aggiunte e corretti. Poi che un editor sia basato su CK non finale non interessa, interessa quello che si pubblica su un sito.
E su un sito si pubblica testo e multimedia, se devi far girare codice tuo ti crei un componente/modulo e gli fai fare quello che vuoi.
Ma sopratutto... che centra lo sviluppo software con la presenza di estensioni per joomla 1.6? ::)
Ti manca qualcosa? Olio di gomito e te la fai :-)
PS: per il tuo OT... i blocchi logici della struttura MVC non sono "processi" quindi parlare di IPC è un po' anomalo: magari parlerei di MVC Distribuited. Comunque teoricamente puoi mettere i 3 "blocchi" su varie macchine e via "rete" far si che il visualizzatore peschi i dati elaborati dal model dentro un altro server, e a loro volta ricevano i comandi dal controller posizionato in una terza posizione. Tanto ogni blocco è un "file" quindi si fa presto a fare i riferimenti e passare le richieste. Se devi partire questo componente ti sarà di aiuto http://extensions.joomla.org/extensions/miscellaneous/development/1509
-
Tralascio il precedente visto che non mi va di polemizzare con nessuno.
Il fatto che siano o meno processi ha poca importanza; qualsiasi libreria può venir linkata esponendo metodi via IPC invece che tramite altri metodi.
Per farti un esempio, al momento sto lavorando ad un sistema operativo distribuito, Ubique, basato su architettura microkernel, dove tutti i servizi sono implementati come processi indipendenti e distribuibili a piacere.
Perfino il filesystem è un processo a sè stante, ospitato su database.
Di fatto non vi è alcuna difficoltà di codifica nel trasformare un linking stretto (libreria) in uno lasco (processo server), quindi nulla impedisce, almeno a livello teorico, di implementare i tre componenti base di Joomla secondo tale tecnica. Stavo solo chiedendo se qualcunio lo avesse fatto, magari in via sperimentale.
-
Perfino il filesystem è un processo a sè stante, ospitato su database.
Di fatto non vi è alcuna difficoltà di codifica nel trasformare un linking stretto (libreria) in uno lasco (processo server), quindi nulla impedisce, almeno a livello teorico, di implementare i tre componenti base di Joomla secondo tale tecnica. Stavo solo chiedendo se qualcunio lo avesse fatto, magari in via sperimentale.
Che sappio io no, o almeno non ne trovo traccia. Ma di soluzioni software che sfruttano un modello MVC distribuito ce ne sono assai.
Ma che pro ci sarebbe nel distribuire il MVC? Posso immaginarmi una applicazione di calcolo dove le istruzioni nel Model possono essere talamente complesse e pesanti da necessitare tanta potenza da staccare il model stesso dalla macchina del controller e del view... in modo che non vada a influire negativamente sulle prestazioni... Oppure?
-
Ottimo... mi piace ciò che vien fuori da questo Topic ..
Quando avete due minuti liberi, e viste le conoscenze esternate, perchè non fate un piacere a tutti e soprattutto anche a voi stessi girottolando, ogni tanto, in questa sezione?
http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemBrowse&tracker_id=8103
C'è realmente bisogno dell'aiuto di tutti anche di chi sa solo semplicemente usare if(): else: endif; ;)
-
uno passa la vita a creare oggetti ...incapsulare classi per farle girare su 3 macchine in un unico thread?
M.
-
Si, il bilanciamento della potenza di calcolo è sicuramente una delle ragioni della distribuzione dei sistemi, ma ve ne sono anche altre.
Però qui andiamo decisamente OT, quindi dispostissimo a spostare da qui in poi su altra sezione del forum.
Altre ragioni:
- Ridondanza: ogni servizio può essere reso ridondante senza grandi difficoltà, anche su macchine differenti. Quindi maggior garanzia di funzionamento in caso di fault di un server o di una parte di rete.
- indipendenza dal linguaggio: Ogni processo server diviene un'entità a sè e quindi può essere sviluppato con linguaggi a scelta, l'importante è che nel dialogo IPC venga mantenuta l'uniformità di protocollo. Questo è particolarmente interessante perchè consente di utilizzare linguaggi di scripting per la parte non CPU-intensive ed usare qualcosa di più performante (C, C# etc etc) per i servizi più pesanti.
- Versioning semplificato: Ogni nuova versione dei moduli può essere mandata online senza dover abbattere l'intero sistema; teoricamente gli utenti potrebbero non accorgersene neppure.
- Facilità di debugging: in sistemi molto grandi l'analisi del traffico fra moduli favorisce in modo significativo il processo di debugging; gli errori query->answer fra processi separati si prestano ad essere individuati in via automatica assai meglio di quanto non si possa fare anche con il miglior debugger del mondo. In aggiunta, ogni modulo può essere testato a sè, facilitando ulteriormente la ricerca dei bug.
Insomma, le ragioni per "sparpagliare" i grossi sistemi ci sono, e visto che ormai andiamo verso bande passanti più che decenti, il processo diviene più che fattibile.
-
Ottimo... mi piace ciò che vien fuori da questo Topic ..
Quando avete due minuti liberi, e viste le conoscenze esternate, perchè non fate un piacere a tutti e soprattutto anche a voi stessi girottolando, ogni tanto, in questa sezione?
http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemBrowse&tracker_id=8103
C'è realmente bisogno dell'aiuto di tutti anche di chi sa solo semplicemente usare if(): else: endif; ;)
E' una delle ragioni per cui chiedevo.
Il PHP lo conosco davvero poco, e quel poco non è che mi entusiasmi (come tutti i linguaggi di scripting). Un contributo in C / C# lo darei volentieri, ma che io sappia Joomla accetta solo PHP, ma potrei sbagliare...
-
Altre ragioni:
- Ridondanza: ogni servizio può essere reso ridondante senza grandi difficoltà, anche su macchine differenti. Quindi maggior garanzia di funzionamento in caso di fault di un server o di una parte di rete.
Ok, che si ricollega a quello detto io.
- indipendenza dal linguaggio: Ogni processo server diviene un'entità a sè e quindi può essere sviluppato con linguaggi a scelta, l'importante è che nel dialogo IPC venga mantenuta l'uniformità di protocollo. Questo è particolarmente interessante perchè consente di utilizzare linguaggi di scripting per la parte non CPU-intensive ed usare qualcosa di più performante (C, C# etc etc) per i servizi più pesanti.
beh molto interessante, in effetti qualcuno potrebbe volere anche riutilizzare modelli già pronti, e dovrebbe adattare solo la parte di "comunicazione" con gli altri 2 blocchi. Porting più facili anche.
- Versioning semplificato: Ogni nuova versione dei moduli può essere mandata online senza dover abbattere l'intero sistema; teoricamente gli utenti potrebbero non accorgersene neppure.
- Facilità di debugging: in sistemi molto grandi l'analisi del traffico fra moduli favorisce in modo significativo il processo di debugging; gli errori query->answer fra processi separati si prestano ad essere individuati in via automatica assai meglio di quanto non si possa fare anche con il miglior debugger del mondo. In aggiunta, ogni modulo può essere testato a sè, facilitando ulteriormente la ricerca dei bug.
Queste due cose invece non sono pregi del distribuito perchè si possono fare anche ora.
Spesso faccio delle modifiche al php di alcuni "model" per personalizzare alcune situazioni, e non mi pare che devo riavviare il server o chiudere il sito in joomla.
Per la facilità del debugging stessa cosa, basta ovviamente mettere qualcosa che faccia tutto il log della comunicazione tra i vari blocchi. E cmq Joomla dalla 1.5 è stato studiato per poter eseguire lo Unit Testing, in modo da isolare ogni singolo modulo di codice.
E' una delle ragioni per cui chiedevo.
Il PHP lo conosco davvero poco, e quel poco non è che mi entusiasmi (come tutti i linguaggi di scripting). Un contributo in C / C# lo darei volentieri, ma che io sappia Joomla accetta solo PHP, ma potrei sbagliare...
Beh, il codice dentro joomla da "capire" non è poi così difficile, è anche abbastanza documentato ed autoesplicativo: potresti provare pian piano a farti un bel fork/porting in C partendo dai componenti basilari.... sicuramente qualcuno ti seguirà in questo progetto ;-)
Oppure se hai un "componente" o un applicativo che sapresti fare ma solo in C, lo sviluppi e lo fai girare dove vuoi e poi ci comunichi con il protocollo XML-RPC.... Ad esempio ci sono parecchie applicazioni windows che comunicano con joomla via xm-rpc.
-
Queste due cose invece non sono pregi del distribuito perchè si possono fare anche ora.
Spesso faccio delle modifiche al php di alcuni "model" per personalizzare alcune situazioni, e non mi pare che devo riavviare il server o chiudere il sito in joomla.
Per la facilità del debugging stessa cosa, basta ovviamente mettere qualcosa che faccia tutto il log della comunicazione tra i vari blocchi.
No Sim, non puoi.
Pensa ad esempio a cosa accadrebbe se una nuova versione di modulo utilizzasse, magari, il database in modo anche solo leggermente differente.
Il debugging, ti assicuro, è enormemente semplificato se puoi analizzare i moduli indipendentemente, tanto più osservandone il processo di IPC.
E' sufficiente creare un driver che invii al processo sotto test una serie di query predefinite e confronti le risposte con quelle attese. In questo modo isolare gli errori ed i blocchi di codice che li hanno causati diviene mooolto più semplice.
Vero, lo puoi fare anche con un'IDE dell'ultima generazione, ma mai con la semplicità che avresti scrivendo un moduletto stupido che si connette in TCP/IP al servizio per sparargli dentro query prese da un banale file di testo, non credi?
Con qualche riga di codice in più, il moduletto puoi usarlo anche per il profiling, per trovare colli di bottiglia, stabilire se un determinato servizio è meglio metterlo sulla macchina A piuttosto che sulla B, etc etc.
-
Beh, il codice dentro joomla da "capire" non è poi così difficile, è anche abbastanza documentato ed autoesplicativo: potresti provare pian piano a farti un bel fork/porting in C partendo dai componenti basilari.... sicuramente qualcuno ti seguirà in questo progetto ;-)
Oppure se hai un "componente" o un applicativo che sapresti fare ma solo in C, lo sviluppi e lo fai girare dove vuoi e poi ci comunichi con il protocollo XML-RPC.... Ad esempio ci sono parecchie applicazioni windows che comunicano con joomla via xm-rpc.
Simbus, quando stai scrivendo un "coso" come un OS, non è che di tempo te ne resti poi molto, tanto più che ho il cane da portar fuori 4 volte al giorno! ;)
XML-RPC... bleah! Efficienza di protocollo prossima allo zero. Se provi a fare un sistema operativo distribuito scambiandoti pacchetti XML, auguri ;D
-
No Sim, non puoi.
Pensa ad esempio a cosa accadrebbe se una nuova versione di modulo utilizzasse, magari, il database in modo anche solo leggermente differente.
Il debugging, ti assicuro, è enormemente semplificato se puoi analizzare i moduli indipendentemente, tanto più osservandone il processo di IPC.
E' sufficiente creare un driver che invii al processo sotto test una serie di query predefinite e confronti le risposte con quelle attese. In questo modo isolare gli errori ed i blocchi di codice che li hanno causati diviene mooolto più semplice.
Vero, lo puoi fare anche con un'IDE dell'ultima generazione, ma mai con la semplicità che avresti scrivendo un moduletto stupido che si connette in TCP/IP al servizio per sparargli dentro query prese da un banale file di testo, non credi?
Con qualche riga di codice in più, il moduletto puoi usarlo anche per il profiling, per trovare colli di bottiglia, stabilire se un determinato servizio è meglio metterlo sulla macchina A piuttosto che sulla B, etc etc.
E in che modo così tanto diverso potresti usare un database scusa? sempre query vai a farci su mysql. letture, scritture... (nelle loro varie forme). Un tabella nuova e via :D
Per il debugging non ti capisco, è il codice di joomla stesso creato in modo che si possa fare "unit test". Ossia analizzare ogni singola parte del codice.... Con script esterni o come vuoi....
Simbus, quando stai scrivendo un "coso" come un OS, non è che di tempo te ne resti poi molto, tanto più che ho il cane da portar fuori 4 volte al giorno! ;)
XML-RPC... bleah! Efficienza di protocollo prossima allo zero. Se provi a fare un sistema operativo distribuito scambiandoti pacchetti XML, auguri ;D
Eh vabbè, credi che la gente che lavora a gratis su joomla sia messa diversamente da te me o chiunque altro?
Per XML-RPC... beh... son soluzioni :P
-
Io sto studiando Php. Spero di dare il mio contributo prossimamente
-
Simbus,
gli unit test puoi farli in qualsiasi linguaggio, non solo in PHP, non è quello il problema. E' la facilità della creazione di un sistema di testing automatizzato a differire profondamente.
Se hai un modulo totalmente indipendente puoi facilmente mettere in piedi un programma che lo testi secondo una procedura standard.
Oltretutto, una volta creato il driver, ti è utile per omologare tutte le successive versioni del modulo in testing.
Pilotare una libreria con il debugger per fargli eseguire qualche centinaio di query differenti ed analizzarne in via automatizzata le risposte non è che non si possa fare, ma è decisamente più scomodo rispetto ad una banale connessione TCP/IP. Pensa anche al fatto dell'estrema semplicità di debugging remoto, utilissimo in caso di sviluppo in team. Semplicissimo in questo caso, pressochè non fattibile con l'uso di librerie.
Per l'uso diverso del database... chi ti dice che la versione 9.5 del Joomla utilizzerà le stesse tabelle e gli stessi campi della 1.6? In un sistema distribuito la cosa interesserebbe poco, perchè è sufficiente che il processo server esponga gli stessi metodi ed utilizzi lo stesso protocollo, ed i dettagli di implementazione non riguardano il resto del sistema.
Tu dirai: ma è la stessa cosa con le librerie. Beh, si e no. Si nel senso che non è infattibile, no nel senso che con le librerie hai necessariamente un tempo di sovrapposizione delle due tecnologie che rende di fatto non fattibile la cosa.
Però qui stiamo divagando sui dettagli, la vera importanza della distribuzione dei (grossi) sistemi è l'ottimizzazione delle risorse di calcolo risiede nei primi punti da me elencati, ossia solidità dell'architettura dovuta alla ridondanza e indipendenza dalle piattaforme su cui essa è ospitata (da intendersi sia come hardware che come linguaggi/sistemi operativi).
Tanto per farti un esempio, condurre un attacco DDOS veso un server è cosa relativamente semplice, lo sappiamo tutti; farlo veso una piattaforma distribuita è (virtualmente) impossibile. O almeno estremamente complesso.
-
Simbus,
gli unit test puoi farli in qualsiasi linguaggio, non solo in PHP, non è quello il problema. E' la facilità della creazione di un sistema di testing automatizzato a differire profondamente.
Se hai un modulo totalmente indipendente puoi facilmente mettere in piedi un programma che lo testi secondo una procedura standard.
Guarda, il problema è che non guardato come funziona Joomla, perchè parli di cose diverse per come "le sai te" nel tuo campo.
Io ne so poco, forse meno di te, ma so che Joomla è stato fatto così per un motivo: sviluppo veloce e ottime prestazioni.
Lo unit testing di Joomla non è al 100% ancora ma ci "testi" ogni singolo modulo nel modo più granulare possibile così come è.
Ma parlare e basta, come fai, invece di aprire i benedetti docs e andare sui developer groups non serve a niente... Tu hai la testa nei tuoi progetti, che senso ha che sto qua a discutere su Joomla se lo paragoni sempre a cose così diverse?
-
Ma dico... stiamo scherzando o cosa?
Io avevo fatto una semplice domanda ad Alex, il quale mi ha risposto e per me era finita lì in quanto soddisfatto.
Sei tu che hai iniziato a tirar fuori tutta sta roba, mica io.
-
Big Ben ha detto Stop!
Dopo queste interessanti disquisizioni pregasi ritornare In Topic
Grazie.
-
Mi inserisco nella discussione per chiedere un piccolo chiarimento. Allora, da quanto ho letto in giro, la 1.6 è la versione successiva alla 1.5, e quindi passare dalla seconda alla prima comporta diversi cambiamenti (di estensioni in primis). La 1.5 rimarrà supportata fino al 2012 e quindi non è urgente passare subito alla 1.6, ma dato che io avevo già in programma di fare una nuova versione del mio sito, mi consigliate di fare la nuova versione con la 1.6 o rimanere alla 1.5 per poi passare direttamente alla 1.7 o 1.8 quando saranno pronte e sicure? Insomma, conviene aggiornare Joomla per piccoli passi (quindi 1.6, 1.7, 1.8, ecc.) o fare un unico maxi upgrade da Joomla 1.5 a Joomla 1.8? E ancora, le estensioni della 1.6 siamo sicuri che funzioneranno senza problemi anche con le versioni di Joomla successive? O come era accaduto per il passaggio 1.5-1.6 le estensioni andranno modificate un'altra volta?
Grazie in anticipo a chi vorrà rispondermi :)
-
ciao Nuzzina,
se devi partire con rifare il sito puoi valutare se farlo con la 1.6, è certamente consigliato.
Verifica magari prima se devi utilizzare qualche estensione esterna che queste siano compatibili con Joomla 1.6
-
Ok, grazie per i consigli :)
-
Mi dispiace tirare fuori una vecchia discussione di mesi fa, ma mi sembra che che le mie paure abbiano preso corpo.
Ho aperto questo 3d chiedendo se quelli di Joomla fossero impazziti, e vedo da molte voci in giro che forse sì, sono impazziti.
Questo sistema di aggiornamenti ha lasciato perplesse molte persone che hanno ormai paura ad avvicinarsi a Joomla.
Quel che è peggio è che, in apparenza, ci ho preso in pieno.
Componenti e template se sono fatti per la 1.6 non vanno bene per la 1.7, quindi ogni 6 mesi hai già un sito "vecchio". Aggiornandolo, però, non si ha la certezza che i componenti funzionino, oppure si aspetta che escano gli aggiornamenti anche dei componenti e compagnia bella.
Continuo a chiedermi il perché di sto sistema "semestrale" astruso....
-
Ho aperto questo 3d chiedendo se quelli di Joomla fossero impazziti, e vedo da molte voci in giro che forse sì, sono impazziti.
-------------------------------------------------------------
Quel che è peggio è che, in apparenza, ci ho preso in pieno.
-------------------------------------------------------------
Componenti e template se sono fatti per la 1.6 non vanno bene per la 1.7,
-------------------------------------------------------------
... ma che stai dicendo? ... ma l'hai capito quello che hai letto?
Qualsiasi estensione per la 1.5 va bene per la 1.7 e anche per la 10.1000 per qualsiasi sviluppatore in 10 min....
il 90% delle estensioni per joomla 1.5 non vanno bene per le successive solo perchè sono cambiate 4 righe nell'installer...
purtroppo per giudicare le cose bisognerebbe prima conoscerle e avere le competenze per farlo altrimenti conviene continuare a criticare Balotelli la mattina al bar
M.
-
Grazie per la risposta Mau, anche se non condivido il tono.
Il fatto che siano solo cambiate 4 righe nell'installer ha, infatti, reso inutilizzabili il 90% delle estensioni. Ti sembra poco?
Forse per te che sei un cyborg della programmazione risulta una stupidaggine, ma non è così per molti altri (me compreso). Malgrado siano 4 righe rimane il fatto che rende inutilizzabili il 90% delle estensioni.
Questo (http://forum.joomla.it/index.php/topic,143683.0.html) e questo (http://forum.joomla.it/index.php?topic=139522.0) post (solo per quel che riguarda i template) la dicono lunga. Aggiorni e ti si scasina tutto. Sistema perfetto! vero? Ma in fondo basta cambiare 4 righe di codice....
Se poi guardiamo sulla pagina di Joomla extension, molti componenti hanno il logo di Joomla 1.6, ma non quello di 1.7. Per me significa che vanno bene per uno ma non per l'altro.
Ho visto proprio ora che è un dubbio che hanno anche altre persone (http://forum.joomla.it/index.php?topic=140805.0) (forse non proprio "illuminate" come lo sei tu) e lì ho ricevuto altre informazioni. Di "dovrebbero" e altri condizionali quando si parla di nuove versioni e compatibilità continuo comunque a trovarne molti.
purtroppo per giudicare le cose bisognerebbe prima conoscerle e avere le competenze per farlo altrimenti conviene continuare a criticare Balotelli la mattina al bar
M.
A me di Balotelli e del calcio in generale non me ne frega una ceppa. I miei interessi sono ben altri.
edit:
Sugli stessi siti di alcuni componenti trovi 3 versioni: "scarica per 1.5", "scarica per 1.6", "scarica per 1.7". Non ho mai approfondito, ma se fossero uguali metterebbero "scarica per 1.6/1.7", o anche a loro piace complicarsi la vita?
-
Se poi guardiamo sulla pagina di Joomla extension, molti componenti hanno il logo di Joomla 1.6, ma non quello di 1.7. Pe
--------------------------------------------------------------------------------
vedi che si fa confusione.....?
..allora, Joomla è Joomla .... le estensioni centrano un tubo... ti faccio un paragone:
ho la vecchia 500 con diversi accessori ora che è uscita la nuova li pretendo anche per questa, non li trovo e mi incaxo con fiat... ma cavolo! non potete fa uscire una macchina nuova così ...nessuno ha gli accessori! .... capisci che non ha senso.
Joomla da user è sempre più user-friendly, ...ma anche da sviluppatore (..anche se sta facendo un po' di casino :) )
....le estensioni... sono estensioni appunto, accessori...
M.
-
Perdonami Mau ma non capisco il tuo esempio, o almeno non calza.
E' ovvio che se ho la 500 del 1960 non posso pretendere di usare gli accessori nuovi (Joomla 1.5 con estensioni di Joomla 1.7), ma qui il discorso è il contrario!
Io prendo l'autoradio nuova e la metto sull'ultimo modello di auto (template o estensione per Joomla 1.6 su Joomla 1.6), poi esce la macchina nuova (Joomla 1.7) e quell'autoradio non mi funziona più! O tengo la vecchia macchina o faccio a meno dell'autoradio.
Il rischio è di avere un qualcosa per Joomla 1.6 e ritrovarsi che non funziona più aggiornando all' 1.7. Qui è l'autoradio che blocca tutta l'automobile (e questo ogni 6 mesi!). Non ci trovo logica in questo.
-
vabene seguo il il tuo...
Il rischio è di avere un qualcosa per Joomla 1.6 e ritrovarsi che non funziona più aggiornando all' 1.7.
-----------------------------------------------------------
qualcosa che non è di joomla
Qui è l'autoradio che blocca tutta l'automobile.
------------------------------------------------------------
se hai scelto di dare più importanza all'autoradio che all'automobile... si ma solitamente ogni automobile esce con la sua autoradio di serie ;)
Joomla non è un forum... se ci attacchi un forumm son problemi tuoi
Joomla non è una chat ... ci sono applicazioni più idonee per questo
Joomla non è un repository di files e gallerie multimediali... idem come sopra....
Ti posso assicurare che il 50% delle estensioni che uno utilizza sono inutili perchè con un po' di manualità joomla lo fa da se.
M.
-
Il tuo discorso non fa una piega... forse.
Il bello di Joomla, oltre che essere "friendly", è che ci puoi fare molte cose "base". Il fantastico di Joomla è che puoi fare molte cose "super" grazie alle estensioni. Joomla da solo può essere paragonato a Wordpress. Preso singolarmente per un neofita le differenze possono essere minime. A mio avviso ciò che rende unico Joomla (oltre al sistema di per sé) è quello che ci gira attorno.
Joomla non è un forum, è vero. Ma se io lo utilizzo perchè ha anche il forum, e poi il forum non mi funziona più dopo 6 mesi, Joomla non fa per me.
Joomla non ha uno slide show degli articoli, ma lo scelgo perche ha un modulo esterno che lo fa. Se lo installo e dopo 6 mesi non funziona più, Joomla non fa per me.
Seguendo il tuo discorso non si dovrebbe usare nessuna estensione e lasciare Joomla così com'è. Per molti potrebbe bastare, per molti altri forse no. Oppure diventare tutti esperti di PHP, classi, oggetti, MVC, SQL, ecc. A questo punto Joomla avrebbe perso lo scopo della sua esistenza per il 99% delle persone.
Il successo di Joomla 1.5 non è stato dato solo dal core ma, sopratutto, dallo sviluppo delle estensioni di terze parti. Se queste estensioni non sono utilizzabili dopo appena 6 mesi (perchè per questioni di sicurezza mi dicono che devo aggiornare il core alla versione successiva), Joomla perde la sua utilità e fascino facendomi puntare verso qualcosa che mi dà più fiducia in termini di stabilità nel tempo.
-
bon... credo tu abbia capito infatti se vedi la questione incomincia a diventare diversa... una certa "dipendenza" che nel tempo si è creata tra estensioni e joomla.
Il tuo discorso non è strano anzi ..è ovvio
Seguendo il tuo discorso non si dovrebbe usare nessuna estensione e lasciare Joomla così com'è.
-------------------------------------------------------------------------------------
..assolutamente no, ci sono estensioni che affiancano pari pari lo sviluppo di joomla... c'è l'elenco in qualche post e la community serve anche a supplire queste difficoltà, ovvio che ti posso suggerire come adattare un template non mi metto certo a spiegarti come adattare componenti interi.
Joomla da solo può essere paragonato a Wordpress
------------------------------------------------------------------------
si si...se guardi la index a video è uguale anche ad una pagina html ... se invece ti metti a leggere entrambe le documentazioni ti accorgi che qualcosa cambia.
A mio avviso ciò che rende unico Joomla (oltre al sistema di per sé) è quello che ci gira attorno.
--------------------------------------------------------------------------------------
beh è come scegliere il profumo dalla confezione e dalla prosperità della commessa... mi è capitato di fare anche questo ma non lo consiglierei...
Joomla non ha uno slide show degli articoli, ma lo scelgo perche ha un modulo esterno che lo fa. Se lo installo e dopo 6 mesi non funziona più, Joomla non fa per me.
-----------------------------------------------------------------------
anche questo passaggio leggendo tra le righe è molto emblematico del tuo pensiero, purtroppo nemmeno dopo una sera a birre riuscirei a concludere il discorso....
e fascino facendomi puntare verso qualcosa che mi dà più fiducia in termini di stabilità nel tempo.
------------------------------------------------------------------------------------------------------------------------------------
... ti inviterei a provare ad esaudire le tue necessità con qualunque altro cms ... poi mi dici ;)
una cosa stabile nel tempo.... è vecchia!
M.