[Java] Creazione automatica dei componenti Swing

[andbin]

Questo è un approccio migliore per la gerarchia

No, purtroppo, mi spiace. Credo che non hai ancora la visione generale di queste problematiche. Dovrei/potrei mostrarti un esempio di cosa intendo io ma in queste settimane sono molto preso con il mio lavoro. Forse riesco a scrivere qualcosa nel weekend.

[alka]

Potrei anche creare il solito file xml annidando i figli uno nell'altro. Ma ci sono soluzioni migliori ad intuito che potrei adottare.

A intuito, io direi che è abbastanza improbabile che i formati proposti (o eventuali alternative "manuali") siano più comprensibili, convenzionalmente definiti, supportati a livello globale, leggibili e già dotati di un parser pronto all'uso rispetto al formato XML (o equivalente).

Adottare scelte di formati non standard, quando la problematica da risolvere non lo impone, significa semplicemente porsi davanti problemi già affrontati e risolti brillantemente da intere community di tecnici: laddove non sia un "caso di studio" o un qualcosa che nasce per hobby e sperimentazione, posto che ognuno può fare liberamente le proprie scelte, usare un formato totalmente custom in questo modo non ha molto senso né giustificazione.

[jabjoint]

D'accordo grazie. Non ho fretta.

[jabjoint]

Secondo me è più comprensibile il formato che ho proposto anche pià del solito XML che comunque trae spunto da quest' ultimo.

Penso che il sistema da me adottato non sia per nulla da gettare via è veloce da capire, semplice da scrivere, logico e conciso.

Un XML sarebbe più ripetitivo.

Per il parsing un sistema si trova sempre.

Per il resto rimango in attesa di @andbin, probabilmente non ho chiaro qualcosa.

Saluti.

[jabjoint]

XML lavora cosÌ di solito:

[frames]
  [frame index=0]

  [containers]
  [container index=0]

      [panels]
        [panel index=0]
        [/panel]
     [/panels]

  [/container]

  [/containers]

  [/frame]
[/frames]

Con questo metodo di "annidamento" se i blocchi sono molti non si capisce più nulla.

@andbin è questo il metodo che vuoi mostrare?

[alka]

Secondo me è più comprensibile il formato che ho proposto anche pià del solito XML che comunque trae spunto da quest' ultimo.

Se intendi che è più comprensibile per te in quanto inventato da te, può anche essere vero.

Penso che il sistema da me adottato non sia per nulla da gettare via è veloce da capire, semplice da scrivere, logico e conciso.
Un XML sarebbe più ripetitivo.

Cosa c'entra la ripetizione? C'entra l'obiettivo da perseguire, l'impegno dedicato a inventarsi uno standard da zero, le problematiche di rappresentazione, l'encoding dei caratteri, i casi particolari, c'entra tutto quello che è già stato affrontato e gestito in passato, in modo eccellente, e che stai cercando di reinventare da zero, sostenendo tecnicamente che sia meglio.

Ripeto il concetto: se vuoi farlo perché ti piace o ne hai voglia, nessuno può impedirti di fare il contrario, né di ritenere altre soluzioni migliori di questa, se a te piace.

Se invece estendiamo la valutazione su scala generica e globale, da un piano puramente tecnico valutando vantaggi/svantaggi, inventarsi quel formato al posto di adottarne un altro standard già riconosciuto e supportato, non ha alcuna ragione tecnica valida a supporto, o comunque ne ha molte, molte di meno.

Per il parsing un sistema si trova sempre.

Certo, è sempre possibile realizzare un parser per un formato di dati "custom", però il problema è che c'è da scriverlo, mentre per l'XML è già stato formalizzato, scritto, standardizzato, documentato, testato, globalmente adottato, riconosciuto.

Peraltro, uno degli standard più diffusi che è nato proprio per rappresentare interfacce utente in modo documentale e di nuova generazione, ovvero XAML, guardacaso si basa proprio su XML.

In sintesi, forse stai facendo una cosa che è già stata fatta, che è stata fatta bene e che funziona, inutilmente.
Ripeto, inutilmente se l'obiettivo non è "giocare a inventare un formato per rappresentare controlli".

[jabjoint]

Se intendi che è più comprensibile per te in quanto inventato da te, può anche essere vero.


Cosa c'entra la ripetizione? C'entra l'obiettivo da perseguire, l'impegno dedicato a inventarsi uno standard da zero, le problematiche di rappresentazione, l'encoding dei caratteri, i casi particolari, c'entra tutto quello che è già stato affrontato e gestito in passato, in modo eccellente, e che stai cercando di reinventare da zero, sostenendo tecnicamente che sia meglio.

Ripeto il concetto: se vuoi farlo perché ti piace o ne hai voglia, nessuno può impedirti di fare il contrario, né di ritenere altre soluzioni migliori di questa, se a te piace.

Se invece estendiamo la valutazione su scala generica e globale, da un piano puramente tecnico valutando vantaggi/svantaggi, inventarsi quel formato al posto di adottarne un altro standard già riconosciuto e supportato, non ha alcuna ragione tecnica valida a supporto, o comunque ne ha molte, molte di meno.


Certo, è sempre possibile realizzare un parser per un formato di dati "custom", però il problema è che c'è da scriverlo, mentre per l'XML è già stato formalizzato, scritto, standardizzato, documentato, testato, globalmente adottato, riconosciuto.

Peraltro, uno degli standard più diffusi che è nato proprio per rappresentare interfacce utente in modo documentale e di nuova generazione, ovvero XAML, guardacaso si basa proprio su XML.

In sintesi, forse stai facendo una cosa che è già stata fatta, che è stata fatta bene e che funziona, inutilmente.
Ripeto, inutilmente se l'obiettivo non è "giocare a inventare un formato per rappresentare controlli".

Siccome il software lo uso io poco importa se ad altri è più comprensibile XML.
Poi si può sempre convertire da un sistema all'altro...

[alka]

Siccome il software lo uso io poco importa se ad altri è più comprensibile XML.

Questo genere di risposta mi lascia sempre interdetto, per tanti buoni motivi.

Il "poco importa" dipende: anche se si lavora per sé stessi, si dovrebbe sempre cercare di lavorare nell'ottimale, di risolvere i problemi, non di crearsene di nuovi, e ogni problematica è sempre un'occasione per imparare cose nuove, in termini di linguaggi, standard, librerie, metodologie...

Non capisco il senso di porre un problema, chiedere aiuto in merito e condurre una discussione dove fondamentalmente, invece di fare tesoro di quel che viene detto, o quantomeno di discuterne a livello tecnico, si tenta di convincere chi da una mano della validità della propria scelta sbagliata, dicendo tutti i motivi per cui si va nella direzione contraria, anzi in realtà senza dire nulla di tecnicamente valido, visto che il discorso si conclude con una sorta di "ok, tutto bello, ma tanto chissenefrega".

Tu chiedi, ma tanto la risposta l'hai già scelta.
Noi le risposte già le sappiamo, ed è inutile raccontartele.
A conti fatti, a che serve la discussione? Anzi, a chi?

Poi si può sempre convertire da un sistema all'altro...

Ah, per quanto mi riguarda si possono usare anche 10, 1000 formati diversi, e si può sviluppare con la testa ruotata e una gamba sollevata. Non cambia la questione.

Mi arrendo.
Lascio la palla al buon andbin.

[jabjoint]

A me risulta più complesso lavorare con XML.
Non vedo perché devo complicarmi la vita.
Ben vengano metodiche nuove, quelle standard son scritte ovunque. aspetto che mi illumini @andbin.

[andbin]

A me risulta più complesso lavorare con XML.

In che senso? Cosa ti è ostico? Per XML, tra l'altro, già solo in Java esistono svariati approcci: DOM, SAX, StAX (e citiamo anche JAXB ma per la tua necessità è assolutamente da scartare), senza contare librerie di terze parti. Conosci una di queste tecniche? O nessuna?