gaglioppo
17-03-2006, 09:43
ciao amici,
ho visto su internet molti esempi di browser che usano JeditoPane, in pratica si carica con .setPage(url) la stringa con l'url e si riesce a visualizzare la pagina, poi si può andare avanti controllando i link e cose simili.
Il mio intento è diverso, ho la necessità di avere non un browser, ma di caricare una sola pagina con link inattivi e nessuno interattività riguardo all'html.
Mi serve però che ogni oggetto, in particolare Links e Form, sia un oggetto java da cliccare per averne informazioni.
Per ora ho fatto questo:
-Ho preso la pagina html, ne ho fatto un albero DOM in cui ogni tag è un nodo di un albero e come nodo radice abbiamo "<HTML>".
-Da ogni nodo DOM sono riuscito (catturandone i valori e gli attributi) a creare una stringa con il corrispondente codice HTML (es. <input type=text name=email value=ciccio@ciccio.it).
-Ogni stringa cosi' ricevuta va in un JEditorPane e viene visualizzato in un pannello.
Problema:
Cosi' facendo perdo l'integrità della pagina, infatti è come se visualizzassi una pagina html del tipo:
<html><body><table></body></html>
<html><body><tr></body></html>
<html><body><td>PEPPINO</body></html>
<html><body><td>GIUSEPPE</body></html>
<html><body><tr></body></html>
<html><body><td>NICOLA</body></html>
<html><body><td>NICKY</body></html>
in pratica non viene visualizzata la tabella, ma i 4 nomi messi come se fossero semplice testo e quindi non allineati in una tabella.
Conclusioni:
L'approccio è tutto da buttare, o posso continuare su questa strada e come?
N.b.
Sottolineo che se prendessi tutte le stringhe corrispondenti ai tag e le mettessi in un unico JEditorPane otterrei la stessa cosa che prendere l'url della pagina e metterla nel JEditorPane. La pagina sarebbe correttamente visualizzata ma nn mi servirebbe a nulla.
Oss1.
Il fatto usare tanti JeditorPane mi è ad oggi indispensabile per richiamare dei metodi su ogni JeditorPane, giusto per conoscenza, ad ogni JEditorPAne è associato un listener che apre una finestra di popup
Oss2.
Se conoscete l'inspector Dom di firefox potete farvi un'idea di quello che mi servirebbe.
gaglioppo
17-03-2006, 23:31
up
sto cercando di andare avanti, l'unico problema che mi resta è gestire le tabelle, non trovo soluzioni da questo punto di vista
gaglioppo
20-03-2006, 10:18
scusate se riporto sopra la mia discussione, ma è un punto cruciale per ultimare il mio lavoro.
up :-(
Il dubbio che mi frena dal rispondere e che credo attanagli anche altri riguarda il modello che hai scelto per il tuo sistema.
Le soluzioni astratte sono un'infinità ma non tutte potrebbero adattarsi a quello che hai già scritto.
Il dom inspector di firefox visualizza un albero di elementi a sinistra e i dettagli dell'elemento selezionato a destra. Un JTree può certamente contenere nodi in forma di JEditorPane ma non credo che tu abbia scelto questa via.
Questo è quanto mi pare di afferrare dalla descrizione del problema: la linearizzazione dell'albero di elementi di un documento HTML in tanti JEditorPane va bene, dal punto di vista visivo, fintantochè si tratti di estrarre elementi di blocco; quando affronti degli elementi in linea, come le celle di una riga in una tabella, proporle una sotto l'altra ti lascia perplesso.
Ho inteso correttamente o sono fuori strada?
gaglioppo
20-03-2006, 17:39
Cerco di spiegarmi meglio, ma pensavo di essere stato chiaro.
Quale aspetto devo esplicitare?
Uso le librerie NekoHtml che mi consentono di avere di albero dom:
org.cyberneko.html.parsers.DOMParser;
org.w3c.dom.Node;
Dai nodo estrapolo delle informazioni che mi servono (soprattutto per quanto rigurada form e link).
Dom inspector visualizza l'albero a sinistra, i dettagli a destra e la pagina in basso.
A me serve creare quella pagina, precisa, cliccabile su ogni elemento.
Come hai capito linearizzare l'albero in tanti Jeditopane uno di seguito all'altro non sempre mi va bene. dovrei mantenere la struttura ad albero in qualche modo.
Non so veramente cosa altro dire, fammi tu una domanda specifica.
In linea generale, io creerei un browser ad hoc per gli elementi che devi proiettare. Nota la regione di spazio occupata dagli elementi che il browser proietta, è facile risalire al bersaglio del click. E' un lavoro che può essere più o meno lungo, secondo la varietà di elementi e formati che vuoi proiettare, ma è molto semplice (e un po' noioso :D).
Altrimenti usi dei componenti per mostrare il contenuto secondo un certo aspetto. Il tuo approccio mi sembra corrispondere a questo profilo. Tra l'altro, è simile a come Swing gestiva il testo stilizzato nelle prima versioni. Per distribuire i componenti useresti i normali layout. Supponiamo ad esempio che tu abbia questo elenco di componenti (tipo GridLayout(4, 1)):
JEditorPane (<title>)
JEditorPane (<td>)
JEditorPane (<td>)
JEditorPane (<td>)
Dovresti accumulare i tre "td" in un contenitore intermedio (GridLayout(1, 3)):
JEditorPane (<title>)
- Container(GridLayout(1, 3))
- JEditorPane, JEditorPane, JEditorPane
"meccanicamente", ogni volta che incontri un elemento "tr" crei un contenitore (JPanel), gli affidi un GridLayout con un numero di colonne pari al numero di celle presenti e infili nel contenitore le celle. Poi inserisci il contenitore dove avresti messo i tre JEditorPane.
Quanto a distribuzione dei componenti nello spazio, puoi ottenere tutti gli effetti che desideri. Mantieni anche la possibilità di interagire con i singoli pezzi della pagina usando gli XXXListener di AWT/Swing. Tutto bene a meno che tu non preveda un tipo di interazione che si rifletta su più componenti. Sarebbe il caso, ad esempio, della classica selezione di testo su più linee comune a molti editor/browser di testi.
gaglioppo
21-03-2006, 15:29
La prima possibilità non l'ho capita, ma forse nn ho le basi di programmazione giuste per capirle.
La seconda potrebbe essere una idea.
Nello scorrere l'albero, incontrando un tag <table> potrei creare un Jpanel da riempire, se trovo un tag <tr> posso creare un altro jpanel a griglia anche se non so in anticipo come si svilupperà l'albero......e cosi' via.
(spero di poterci riuscire)
Mi chiedo però se tutti questi jpanel non possano deteriorare l'efficieneza del mio tool in maniera considerevole. Scusatemi ma nn sono molto pratico (ancora) di programmazione, sono alle prime vere esperienze.
Grazie per l'aiuto.
Circa il degrado delle prestazioni vale l'adagio "meno è meglio". Praticamente è come non dir nulla :D. Non so dirti quale sia il limite oltre il quale il numero di pannelli renda un'applicazione troppo "lenta". I componenti Swing sono oltremodo efficienti. C'è una sola superficie per finestra, idealmente "accelerata" e Java2D usa OpenGL o DirectDraw per disegnare, secondo il sistema operativo, il tipo di operazione ed i parametri di avvio della JVM. Senza una prova comparativa tra la stessa applicazione, in due versioni (con tanti pannelli e con pochi) è difficile dire quanto meno rapida sia la prima soluzione rispetto alla seconda.
gaglioppo
22-03-2006, 10:29
ho provato a lavorare coi pannelli.
Il mio pannello principale si chiama pan:
JPanel table=new JPanel(new GridLayout(0,1));
JPanel tr1=new JPanel(new GridLayout(1,0));
JPanel tr2=new JPanel(new GridLayout(1,0));
table.setBorder(BorderFactory.createMatteBorder(
1, 1, 1, 1, Color.RED));
table.add(tr1);
table.add(tr2);
tr1.add(new JEditorPane("text/html","testo1"));
tr1.add(new JEditorPane("text/html","testo2"));
tr2.add(new JEditorPane("text/html","testo3"));
tr2.add(new JEditorPane("text/html","testo4"));
tr2.add(new JEditorPane("text/html","testo4A"));
tr2.add(new JEditorPane("text/html","testo4B"));
tr2.add(new JEditorPane("text/html","testo4C"));
tr2.add(new JEditorPane("text/html","testo4D"));
tr2.add(new JEditorPane("text/html","testo4E"));
tr2.add(new JEditorPane("text/html","testo4F"));
tr2.add(new JEditorPane("text/html","testo4G"));
JPanel table2=new JPanel(new GridLayout(0,1));
JPanel tr12=new JPanel(new GridLayout(1,0));
JPanel tr22=new JPanel(new GridLayout(1,0));
table2.setBorder(BorderFactory.createMatteBorder(
1, 1, 1, 1, Color.BLACK));
table2.add(tr12);
table2.add(tr22);
tr12.add(new JEditorPane("text/html","testo5"));
tr12.add(new JEditorPane("text/html","testo6"));
tr22.add(new JEditorPane("text/html","testo7"));
tr22.add(table);
pan2.add(table2);
con questo esempio ho visto che potrei anche innestare una tabella in una cella di un'altra tabella.
Ho evidenti problemi con questo approccio.
In questo modo mi risulterebbe complesso considerare anche ROWSPAN COLSPAN delle tabelle.
Inoltre anche i tag <p> dovrebbero essere considerati per ricreare l'aspetto grafico originale della pagina html.
Il vero problema è che le pagine html da visualizzare in questo modo non sono fisse, possono cambiare.
Mi ci vorrebbe qualcosa di piu' potente, tipo appunto un Browser ad hoc.
Il messaggio che segue è oscenamente lungo :eek:
Come anticipato, si tratta di materia molto semplice anche se un po' prolissa. Ti mostro come disegnare e interagire con una tabella rappresentata dagli ipotetici elementi XML:
XMLTable
XMLTableRow
XMLTableCell
PCData
La base è un Tipo XMLElement che, contrariamente ai dettami del Model-View-Controller, incapsula vista e modello. Si tratta di un irrigidimento che, a mio modo di vedere, semplifica la comprensione del sistema, probabilmente perchè riduce il livello di astrazione. Più chiaro ma meno flessibile, per farla breve.
XMLElement
package it.tukano.xmlbrowser;
public interface XMLElement {
//MODELLO
XMLElement getParent();
void setParent(XMLElement e);
void addChildren(XMLElement...elements);
java.util.Collection<? extends XMLElement> getChildren();
//VISTA
int getHeight(int width, java.awt.Graphics context);
java.awt.Rectangle paint(PaintInfo p);
java.awt.Rectangle getBounds();
XMLElement getChildAt(java.awt.Point p);
}
La prima parte è quella comune al nodo di un albero. XMLElement ha un genitore e dei figli che rappresentano il suo contenuto. La seconda parte è relativa al meccanismo di proiezione. Il metodo getHeight restituisce l'altezza del contenuto proiettato dall'elemento. Nel caso di un elemento che contenga del testo (come PCData), l'altezza dipende dal contesto grafico. Il parametro "width" è necessario nel caso in cui sia previsto che un certo contenuto (tipicamente il testo) possa dover essere spezzato su più linee. Il numero di linee e quindi l'altezza totale dell'elemento dipenderà dallo spazio orizzontale disponibile. Nell'esempio che ti faccio non separo il testo su più linee dunque non uso questo intero width, per brevità di esposizione. La separazione richiede la scrittura di un proiettore di testi che rende il tutto non più complicato ma più lungo. Sarebbe inoltre necessario un metodo getWidth(Graphics) al fine di poter calcolare l'altezza di una linea su cui siano presenti più elementi, di altezza diversa.
Il metodo paint proietta il contenuto di questo XMLElement usando un PaintInfo per alcuni parametri di disegno. Il disegno di un documento strutturato richiede che ciascun elemento abbia delle informazioni sulla posizione in cui proiettare il suo contenuto i cui valori dipendono dagli elementi precedenti. La riga di una tabella deve essere disegnata sotto la riga precedente nella stessa tabella, una cella dopo l'altra e via discorrendo.
Il sistema di proiezione del documento funziona così: ogni genitore disegna i propri figli informandoli, uno ad uno, del punto a parire dal quale inziare la proiezione, dello spazio a disposizione e del contesto grafico da usare per il disegno. I figli rispondono al genitore dicendo "con i dati che mi hai passato, mi sono proiettato in una regione pari a...". Il genitore usa le dimensioni del rettangolo di proiezione di un figlio per stabilire i dati di proiezione del figlio successivo.
Il metodo getBounds() restituisce la regione di spazio occupata da un elemento DOPO la sua proiezione. Questa regione può essere usate per stabilire quale XMLElement si trovi in un certo punto dello spazio.
Il metodo getChildAt restituisce l'elemento figlio di questo XMLElement che si trovi in posizione p o null.
PaintInfo
PaintInfo rappresenta i dati necessari alla proiezione di un XMLElement. E' poco più di un insieme di puntatori, con le conseguenze del caso.
package it.tukano.xmlbrowser;
import java.awt.*;
public class PaintInfo {
public int x, y, width;
public Graphics graphics;
public PaintInfo(int x0, int y0, int w, Graphics g) {
x = x0;
y = y0;
width = w;
graphics = g;
}
}
XMLBrowser
Il proiettore di un documento XML è un JComponent a cui è affidato un certo XMLElement, supposta radice del documento.
package it.tukano.xmlbrowser;
import java.awt.*;
import javax.swing.*;
public class XMLBrowser extends JComponent {
private XMLElement root;
public XMLBrowser(XMLElement root) {
this.root = root;
}
public XMLElement getRoot() {
return root;
}
public XMLElement getElementAt(Point p) {
return root.getChildAt(p);
}
protected void paintComponent(Graphics g) {
g.setColor(Color.WHITE);
g.fillRect(0, 0, getWidth(), getHeight());
Insets margin = getInsets();
PaintInfo info = new PaintInfo(
margin.top,
margin.left,
getWidth() - margin.left - margin.right,
g);
Rectangle rootArea = root.paint(info);
}
}
Il componente stabilisce la regione iniziale in cui la radice dovrà proiettare il suo contenuto. Passa la palla alla radice e se ne lava le mani :D.
AbstractXMLElement
Questo oggetto semplifica la vita fornendo una definizione comune al modello di un XMLElement. E' fatto com'è fatto perchè così mi è sembrato più facile scrivere un albero di elementi XML (grande profondità teorica :D).
package it.tukano.xmlbrowser;
import java.util.*;
public abstract class AbstractXMLElement implements XMLElement {
private ArrayList<XMLElement> children = new ArrayList<XMLElement>(1);
private XMLElement parent;
public AbstractXMLElement(XMLElement parent, XMLElement...childElements) {
this.parent = parent;
if(parent != null) {
parent.addChildren(this);
}
if(childElements != null) {
for(XMLElement e : childElements) {
children.add(e);
e.setParent(this);
}
}
}
public void setParent(XMLElement parent) {
this.parent = parent;
}
public XMLElement getParent() {
return parent;
}
public void addChildren(XMLElement...e) {
children.ensureCapacity(children.size() + e.length);
for(XMLElement x : e) {
children.add(x);
x.setParent(this);
}
}
public Collection<? extends XMLElement> getChildren() {
return children;
}
}
Ribadisco il principio che ho usato per il disegno degli elementi prima di vederli. In fondo l'obiettivo è il meccanismo e non la sua realizzazione. Un elemento riceve delle informazioni di proiezione relative alla regione di spazio in cui dovrà proiettare il suo contenuto. Un elemento restituisce le dimensioni della regione che abbia occupato per il disegno. Un genitore userà le regioni occupate da un figlio per stabilire l'area di proiezione del figlio successivo.
XMLTable
La tabella è definita come un insieme di elementi disposti su più righe. La proiezione della tabella è proeizione dei suoi figli, uno sotto l'altro. L'area occupata dalla tabella è la massima larghezza di una riga e la somma delle altezza delle righe.
package it.tukano.xmlbrowser;
import java.awt.*;
public class XMLTable extends AbstractXMLElement {
private Rectangle bounds = new Rectangle();
public XMLTable(XMLElement parent) {
super(parent);
}
public Rectangle getBounds() {
return bounds;
}
public XMLElement getChildAt(Point p) {
if(bounds.contains(p)) {
for(XMLElement row : getChildren()) {
XMLElement target = row.getChildAt(p);
if(target != null) return target;
}
return this;
} else {
return null;
}
}
public int getHeight(int lineWidth, Graphics context) {
int height = 0;
for(XMLElement row : getChildren()) {
height += row.getHeight(lineWidth, context);
}
return height;
}
public Rectangle paint(PaintInfo info) {
int x0 = info.x;
int y0 = info.y;
int maxWidth = 0;
int maxHeight = 0;
for(XMLElement row : getChildren()) {
Rectangle rowArea = row.paint(info);
info.y += rowArea.height;
info.x = x0;
if(rowArea.width > maxWidth) maxWidth = rowArea.width;
maxHeight += rowArea.height;
}
bounds.setRect(x0, y0, maxWidth, maxHeight);
return new Rectangle(0, 0, maxWidth, maxHeight);
}
public String toString() {
String s = "Table\n";
for(XMLElement e : getChildren()) {
s += "\t" + e + "\n";
}
return s;
}
}
La proiezione per righe è realizzata spostando info.y di una quantità pari all'altezza dell'ultima riga disegnata. Ogni riga usa (info.x, info.y) come punto di partenza per il disegno da cui l'effetto risultante.
XMLTableRow
XMLTableRow è come XMLTable, solo che disegna i figli uno dopo l'altro lungo una sola linea orizzontale. Qui è info.x a spostarti mentre prima era info.y.
package it.tukano.xmlbrowser;
import java.awt.*;
public class XMLTableRow extends AbstractXMLElement {
private Rectangle bounds = new Rectangle();
public XMLTableRow(XMLElement parent, XMLElement...children) {
super(parent, children);
}
public Rectangle getBounds() {
return bounds;
}
public XMLElement getChildAt(Point p) {
if(bounds.contains(p)) {
for(XMLElement child : getChildren()) {
XMLElement target = child.getChildAt(p);
if(target != null) return target;
}
return this;
} else {
return null;
}
}
public int getHeight(int width, Graphics context) {
int height = 0;
for(XMLElement cell : getChildren()) {
int cellHeight = cell.getHeight(width, context);
if(cellHeight > height) height = cellHeight;
}
return height;
}
public Rectangle paint(PaintInfo info) {
bounds.setLocation(info.x, info.y);
int maxHeight = 0;
int maxWidth = 0;
for(XMLElement cell : getChildren()) {
Rectangle cellArea = cell.paint(info);
info.x += cellArea.width;
if(cellArea.height > maxHeight) maxHeight = cellArea.height;
maxWidth += cellArea.width;
}
bounds.setSize(maxWidth, maxHeight);
return new Rectangle(0, 0, maxWidth, maxHeight);
}
public String toString() {
String s = "ROW";
for(XMLElement e : getChildren()) {
s += " | " + e;
}
return s;
}
}
XMLTableCell
Una cella è un elemento che contiene un altro elemento. E' in grado di realizzare qualsiasi malefatta grafica, questa fa poco o niente salvo dire al suo contenuto "disegnati".
package it.tukano.xmlbrowser;
import java.awt.*;
public class XMLTableCell extends AbstractXMLElement {
private XMLElement content;
public XMLTableCell(XMLElement parent, XMLElement content) {
super(parent, content);
this.content = content;
}
public int getHeight(int lineWidth, Graphics context) {
return content.getHeight(lineWidth, context);
}
public XMLElement getChildAt(Point p) {
return content.getChildAt(p);
}
public Rectangle getBounds() {
return content.getBounds();
}
public Rectangle paint(PaintInfo info) {
int x = info.x;
int y = info.y;
Rectangle area = content.paint(info);
info.graphics.setColor(Color.BLUE);
info.graphics.drawRect(x, y, area.width, area.height);
return area;
}
public String toString() {
return "(" + content + ")";
}
}
PCData
Questo è il contenuto che uso nell'esempio. Testo semplice. Molto semplice :D.
ackage it.tukano.xmlbrowser;
import java.awt.*;
public class PCData extends AbstractXMLElement {
private String text;
private Rectangle bounds = new Rectangle();
public PCData(XMLElement parent, String content) {
super(parent);
text = content;
}
public int getHeight(int width, Graphics context) {
return context.getFontMetrics().getHeight();
}
public Rectangle getBounds() {
return bounds;
}
public XMLElement getChildAt(Point p) {
return bounds.contains(p) ? this : null;
}
public Rectangle paint(PaintInfo info) {
FontMetrics m = info.graphics.getFontMetrics();
int w = m.stringWidth(text);
int h = m.getHeight();
info.graphics.setColor(Color.BLACK);
info.graphics.drawString(text, info.x, info.y + h - m.getDescent());
bounds.setRect(info.x, info.y, w, h);
return new Rectangle(0, 0, w, h);
}
public String toString() {
return text;
}
}
Main
Qui tiriamo le fila del discorso. Affidiamo un XMLBrowser ad un JFrame. Connettiamo ad XMLBrowser un MouseListener. Al click del mouse, richiediamo ad XMLBrowser quale sia l'elemento che si trovi in posizione e.getPoint(). XMLBrowser risponderà interrogando la sua radice, che interroga i figli, e i figli i figli e via dicendo. L'unica cosa da notare è che se al click corrisponda un PCData il MouseListener stamperà a video il suo genitore perchè, idealmente, PCData non contiene attributi che non sia già visibili all'utente quando osservi il browser.
package it.tukano.xmlbrowser;
import java.awt.*;
import java.awt.event.*;
import javax.swing.*;
public class Main {
private XMLBrowser browser;
private JFrame frame = new JFrame("XMLBrowser sample");
private Runnable starter = new Runnable() {
public void run() {
frame.setVisible(true);
}
};
private MouseListener clickHandler = new MouseAdapter() {
public void mouseClicked(MouseEvent e) {
XMLElement target = browser.getElementAt(e.getPoint());
if(target == null) {
target = browser.getRoot();
} else if(target instanceof PCData) {
target = target.getParent();
}
System.out.println("And the winner is: " + target);
}
};
private void startApp() {
XMLElement root = new XMLTable(null);
XMLTableRow row = new XMLTableRow(root);
row.addChildren(
new XMLTableCell(null, new PCData(null, "Cella 0,0")),
new XMLTableCell(null, new PCData(null, "Cella 0,1")),
new XMLTableCell(null, new PCData(null, "Cella 0,2")),
new XMLTableCell(null, new PCData(null, "Cella 0,3")));
row = new XMLTableRow(root);
row.addChildren(
new XMLTableCell(null, new PCData(null, "Cella 1,0")),
new XMLTableCell(null, new PCData(null, "Cella 1,1")),
new XMLTableCell(null, new PCData(null, "Cella 1,2")),
new XMLTableCell(null, new PCData(null, "Cella 1,3")));
browser = new XMLBrowser(root);
browser.setBorder(BorderFactory.createEmptyBorder(10, 10, 10, 10));
browser.addMouseListener(clickHandler);
frame.add(browser);
frame.setSize(400, 400);
frame.setDefaultCloseOperation(JFrame.DISPOSE_ON_CLOSE);
SwingUtilities.invokeLater(starter);
}
public static void main(String...args) { new Main().startApp(); }
}
Qui si nota la bieca funzione di AbstractXMLElement :D.
Ci sono due cose che mancano nell'esempio. La proiezione degli elementi è molto semplificata. Il presupposto, non realistico, è che tutti gli elementi su una stessa riga abbiano la stessa altezza. Il procedimento per supportare la proiezione di elementi in linea con altezze diverse può essere questo:
1. calcola la larghezza di ogni elemento;
2. data la larghezza della linea, ricava l'altezza di ogni elemento che si trovi su quella linea, fino ad esaurimento dello spazio orizzontale disponibile (da cui il getWidth(Graphics));
3. nel caso in cui l'ultimo elemento del passaggio precedente ecceda la larghezza della linea, lo conserva;
4. stabilisce l'altezza massima tra quelle determinate nel punto 2 che diventa altezza della linea corrente;
5. stabilisce l'altezza di base per disegnare il testo in base all'altezza della linea;
6. disegna il contenuto usando l'altezza della linea corrente, l'altezza di base, il punto iniziale e la larghezza della linea;
7. riparte da 1, spostandosi verso il basso di un valore pari all'altezza della linea corrente: se l'ultimo elemento fosse eccedente, nel sendo specificato in 3, usa questo elemento come prima della linea, per la parte in eccesso. Altrimenti parte dall'elemento successivo.
Il tutto vale non solo per la proiezione di testo stilizzato ma, in generale, per qualsiasi successione di elementi in linea (tipo image, span, a, b, i eccetera).
Manca inoltre l'attribuzione di una dimensione ad XMLBrowser. La dimensione può essere calcolata usando la regione di spazio risultante dalla proiezione della radice.
Come si suol dire, è un lavoro "certosino". Sono tutti passaggi non complicati solo che occorre farne un bel po'.
Mi spiace per la lunghezza del messaggio ma l'alternativa era parlare a vanvera per tre o quattro righe e lasciarti con un pungo di mosche in mano.
^TiGeRShArK^
22-03-2006, 22:39
Circa il degrado delle prestazioni vale l'adagio "meno è meglio". Praticamente è come non dir nulla :D. Non so dirti quale sia il limite oltre il quale il numero di pannelli renda un'applicazione troppo "lenta". I componenti Swing sono oltremodo efficienti. C'è una sola superficie per finestra, idealmente "accelerata" e Java2D usa OpenGL o DirectDraw per disegnare, secondo il sistema operativo, il tipo di operazione ed i parametri di avvio della JVM. Senza una prova comparativa tra la stessa applicazione, in due versioni (con tanti pannelli e con pochi) è difficile dire quanto meno rapida sia la prima soluzione rispetto alla seconda.
Se non erro in java 6 (mustang) sono stati eliminati numerosi colli di bottiglia per la gestione della grafica swing ottenendo incrementi di prestazioni MOLTO interessanti (ma potrei anke ricordare male xkè quel giorno stavo cercando le novità dell'implementazione di jogl con i lightweightcomponent in java 6 e non so se mi sto confondendo:p)
comunque complimenti vivissimi x il LUUUUNGO post seguente :D
mi piace molto il codice ke hai scritto :D
ma l'hai scritto solo x spiegare la richiesta fatta in questo thread???:eek:
Se io fossi nell'autore ti farei un monumento :D
Era tanto simpatico il codice ke sei riuscito a distogliermi dallo studio di diritto amministrativo :muro:
Ma non sono riuscito a resistere alla tentazione :D
in effetti se non beccavo il tuo post probabilmente avrei imparato qualcosa di quella skifosa materia, ma cmq mi è servito x ripassare l'uso dei varargs ke mi ero quasi completamente dimenticato :asd:
Ottimo lavoro ;)
Amministrativo I, II e Procedura amministrativa sono state tra le mie materie preferite.
Di Java 6 cantano miglioramenti nella pipeline OpenGL (java -Dsun.java2d.opengl=True applicazione.java) rispetto al 5. Non ho avuto l'opportunità di percepire le differenze ma mi fido :D.
Il codice è ad hoc (non che io mi stia girando i pollici :D) ma la materia non mi è nuova. Prima del monumento dobbiamo sperare che sia stato utile. Il problema è che HTML di tag ne ha una marea :cry:
gaglioppo
23-03-2006, 08:46
... ho comprato 3 quintali di cemento, sabbia, ferri per la struttura, ho ingaggiato un ing. civile, un architetto e uno scultore.
Mi mandi un tuo calco a dimensioni reali in gesso?
Mi copio/incollo le classi e me le studio con calma, poi ti faccio sapere.
Ancora grazie per l'aiuto, sarai citato nella mia tesi, prima di prof, genitori e amici.
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.