Originariamente inviato da valia
Allora scendi dal piedistallo in cui ti sei auto-posto
Non mi pare il caso di offendere, cerco solo di difendere le mie opinioni come fai anche tu in maniera vivace
e continuo a ripeterti che si parla di roba differente e di modi differenti di lavorare (e di impostare il rapporto con il cliente).
giusto, ma questo non vuol dire, a mio parere, di privarsi di un certo dinamismo che può tornar utile.
Da qui si vede il peso che ha l'azienda per cui si lavora, perché va bene andare incontro al cliente, ma dei limiti si devono porre.
Non dipende solo dall'importanza dell'azienda ma anche da come questa sceglie la strada da intraprendere per il futuro.
Se si parla di personalizzazioni, cosa intendi per personalizzazione? Il cambio del bottone? Puoi cambiare il look and feel di un solo bottone su windows o office?
certo che no, ma mi aspetto che grossi progetti come office sappiano come gestire l'aspetto grafico dell'applicazione senza chiedere al programmatore di andare nei singoli file per cambiare l'aspetto. Come farlo spetta a chi il progetto lo fa nascere.
Apro soffice.ini, ad esempio, e vedo questo
codice:
[Bootstrap]
Logo=1
ProgressBarColor=4,68,155
ProgressFrameColor=58,159,232
Ora, senza fare controlli e senza approfondire, a me quei dati sembrano dei valori rgb.
In ...\OpenOffice.org 3\Basis\share\config\soffice.cfg\modules\swriter\m enubar\menubar.xml
trovi un altro bell'esempio di quello che ti parlo (tra l'altro calza parecchio con l'altro mio post). Prova a togliere questa voce:
codice:
<menu:menuitem menu:id=".uno:Save"/>
e trovi riscontro in quello che dico.
Openoffice non è indirizzato ad un singolo cliente, non è fatto da un'azienda di 10 persone.
Puoi farlo su una pagina HTML? vedi che gli ambiti applicativi per quel tipo di personalizzazione sono differenti.
Beh sì, ovvio che se faccio un portalino allora tutto il mio discorso può essere messo da parte, ma parlando di CMS o di progetti generalisti, rendere il tutto configurabile (in questo caso con CSS) è importante oltre che agevole (sempre grazie ai CSS, che svolgono molto bene questo lavoro)
Tu parli di branch, ti posso assicurare che è meglio creare un branch per le personalizzazioni.
Totalmente in disaccordo, non vorrei essere nei panno di chi deve fixare qualcosa su tutti i branch, creati per altro per motivazioni che non mi sembrano funzionali.
In genere ci sarà un intero spazio su disco riservato al cliente (per alcuni nella mia azienda sono presenti intere macchine virtuali, fornite dai clienti, che riproducono l'ambiente di lavoro).
Stessa situazione, ma sono perfettamente d'accordo con te che dipende dal progetto, non c'è dubbio
Anche perché si può partire dalla pura personalizzazione di un singolo bottone per finire a funzionalità differenti (quindi tenere separato il codice è sempre buona cosa).
In genere anche prodotti di grosse dimensioni non sono mai venduti in blocco a differenti clienti, la personalizzazione non si limita alla grafica (la pagina html a volte si, ma si torna in ambiti operativi differenti).
fermo restando che quello che dici è vero, se si riesce a tenere lontano bene la vista col resto, allora le sue personalizzazioni non dovrebbero pesare troppo dalle funzionalità.
Se le funzionalità cambiano, allora è un altro discorso e pare che siamo d'accordo già su questo.
Per un prodotto di una certa entità, è necessario fissare paletti e muoversi intorno a quelli, è impensabile che a prodotto finito ti cambino i requisiti (e qui vedi la serietà/potenza dell'azienda che lascia mano libera al cliente fino ad un certo punto).
sono anche io contro l'esplosione del progetto a causa della troppa flessibilità, ma non è il caso di cui parlo. Se posso crearti dei set di bottoni configurabili, cerco di fartelo perchè chi ci guadagna sono io. Che ci debba essere buonsenso è chiaro.
Poi parli di requisiti (quindi pare parti dalla nascita dell'applicazione) senza pensare che anche a lavoro concluso possono pagarti ancora per fare qualcosa. Talvolta anche per modificare la grafica.
Per quanto riguarda la combo: se usi JComboBox nuda e cruda, una roba come quella che hai detto non la puoi mica fare: si tratta di definizione di rendering, non puoi pensare di non intervenire su quello quando lo metti immagini in una combobox (anche solo per fissare le dimensioni della combo) e non puoi pensare di farlo con codice xml. Banalmente JComboBox fa il toString() dell'oggetto, quindi devi intervenire a priori per far visualizzare al posto del toString() una label con un'immagine.
io parlo molto banalmente di fissare il render, cosa fattibilissima con un xml di configurazione e con un pò di polimorfismo se vuoi fare il fine
JComboBox Tutorial
senza stravolgere l'aspetto funzionale ovviamente, altrimenti andiamo oltre quello di cui parlo
Se parli di html è diverso, io ti sto parlando di java.
Se riesci a fare tutto questo con il componente standard, senza configurazione e modifiche extra allora è un altro paio di maniche.
No no, parlo di Java, con una JComboBox e con un renderer che decidi a configurazione.
Ritorni al menù: parlando di html, il menu a volte è a destra e/o sinistra, in java (o con le swing) il componente JMenu è quello che sta messo in alto alla finestra, un pannello, in genere di piccole dimensioni, che farlo apparire/scomparire non sconvolge il layout. Se devi far apparire le voci, queste non toccano il layout sottostante. Anche qui, mettere immagini nel menu vuole un minimo di rendering (che come fai a specificare via xml ?)
Oddio non dovrebbe essere così difficile dal momento che un Jmenu è un AbstractButton e affidandoci sempre al buonsenso.
Ti ho in parte risposto sopra e comunque questo viene da un mio esempio reale, funzionante.
codice:
<menubar>
<menu id="menu-file" disabled="false" icon="resources/16x16/mfile.png">
<menu-item id="menu-file-exit" disabled="false" icon="resources/32x32/menuexit.png"/>
..
</menu>
</menubar>
Parliamo di componenti che spariscono: devi dire agli altri di ridimensionarsi: allora è più comodo cambiare via codice un'istruzione oppure controllare se i componenti sono presenti e fare in modo che in automatico si riposizionino? Parlando di html la seconda, parlando di java si tratta di impostare bene prima delle istruzioni facilmente leggibili anche da xml.
mai detto che devi ucciderti per far andare tutto da XML. Passi da un estremo all'altro mentre io ti continuo a ripetere che devi decidere prima cosa vuoi e come lo vuoi. Non ho mai parlato di costruirti uno specchio da configurazione, così che il cliente possa guardarlo e dire "ok, mi va bene così".
Questo però dovrebbe far venir meno l'utilità di configurare, nella profondità che tu imposti, una GUI?
Ora ti rendi conto che tu parli di roba nata per browser e io parlo di swing, libreria offerta da java, che non è nata per browser o no?
Perdonami, ma io parlo di swing e non capisco perchè mi continui ad accusare di parlare di HTML. Il thread è nel forum Java, l'utente a chiesto consigli sui GUI Java e io parlo di Swing.
Ho cercato "html" nei miei post e non ho trovato neanche un'occorrenza.
Ti rendi conto che non tutto è configurabile via xml e che oltretutto renderesti il codice di difficile modifica (visto che è pilotato da un xml esterno)?
la verità sta nel mezzo, ma non mi pare sia buono invece qualcosa pilotato tutto da codice. Questo rende parecchio difficile fare anche la minima modifica.
Poi, perchè mai rende il codice di difficile modifica?
Tu hai questo:
codice:
setText(...);
setMnemonic(....)
setIcon(...)
e per cambiarlo devi andare nel codice, modificare, ricompilare e rilanciare.
Io vado nel mio XML, cambio e rilancio. Se hai scritto una schifezza come testo, devi rilasciare il pacchettino associato per fixare, a me basta dare via l'XML/properties/ini del caso.
Senza tenere conto dell'utilità di questo approccio durante il salvataggio del layout da parte del cliente. Oltre a tornare utile nel dizionariamento della GUI (cosa che fa, ad esempio, la libreria QT, che non è l'ultima arrivata diciamo).
Poi sei tanto attento alle esigenze del cliente, che vuole il bottone differente, e non pensi ai tempi di risposta e alle risorse consumante?
Parti, fai la tua bella applicazione. Caso 1: l'applicazione non cambia mai, finito.
Caso 2: l'applicazione deve cambiare faccia, vai a rivoltare il codice, potresti (sottolineo potresti, visto che parliamo di aria, ogni caso ha una soluzione propria) perdere più tempo così che non avere iniziato a fare tutto configurabile. Se cicli sul caso 2 un pò di volte, ti accorgi che qualcosa non va.
Chi consuma più risorse? Chi risponde più veloce? Tu che fai la stessa cosa più volte o la persona che configura e ti risponde dopo 1 giorno?
Non me ne volere, abbiamo esperienze differenti in ambiti differenti e modi di impostare il lavoro differenti.
Ma figurati, dico solo che non puoi vedere un'applicazione come il compilato di un codice, ma di vederla come qualcosa con varie esigenze che girano attorno.
Poi ovvio che tu sai come lavori e sai che quello che fai è giusto, nessuno mette in discussione questo.
Alla prox
Ciao, buona domenica
Rispondi quotando