Ganz einfaches MVC-Beispiel?!

Status
Nicht offen für weitere Antworten.

Verjigorm

Top Contributor
Hallo,
ich soll hier einem ganz blutigem Anfänger erklären, was man unter MVC versteht.
Hab dann erstmal im Netz nach ganz einfachen Beispielen gesucht, aber wie ich finde, waren die meist schon zu kompliziert, da oft auch Interfaces, Observer/Observable mit im Spiel waren.

Ich hab mir dann einfach selbst schnell was aus den Fingern gesagt, aber irgendwie find ich es überhaupt nicht toll :D

Wobei ich mich auch grade gefragt habe, ob ihr auch die packages view/model/controller benutzt oder wie.

Was haltet ihr denn davon:
View:
Code:
package view;

import java.awt.BorderLayout;
import javax.swing.JPanel;
import javax.swing.JFrame;
import javax.swing.JButton;
import javax.swing.JComboBox;

public class View extends JFrame {

    private static final long serialVersionUID = 1L;
    private JPanel jContentPane = null;
    private JButton jButton = null;
    private JComboBox jComboBox = null;

    /**
     * This is the default constructor
     */
    public View() {
        super();
        initialize();
    }

    /**
     * This method initializes this
     * 
     * @return void
     */
    private void initialize() {
        this.setSize(300, 200);
        this.setContentPane(getJContentPane());
        this.setTitle("JFrame");
    }

    /**
     * This method initializes jContentPane
     * 
     * @return javax.swing.JPanel
     */
    private JPanel getJContentPane() {
        if (jContentPane == null) {
            jContentPane = new JPanel();
            jContentPane.setLayout(new BorderLayout());
            jContentPane.add(getJButton(), BorderLayout.CENTER);
            jContentPane.add(getJComboBox(), BorderLayout.SOUTH);
        }
        return jContentPane;
    }

    /**
     * This method initializes jButton    
     *     
     * @return javax.swing.JButton    
     */
    public JButton getJButton() {
        if (jButton == null) {
            jButton = new JButton();
            jButton.setText("Klick Mich");
        }
        return jButton;
    }

    /**
     * This method initializes jComboBox    
     *     
     * @return javax.swing.JComboBox    
     */
    public JComboBox getJComboBox() {
        if (jComboBox == null) {
            jComboBox = new JComboBox();
        }
        return jComboBox;
    }

}
Model:
Code:
package model;

import java.text.SimpleDateFormat;
import java.util.ArrayList;
import java.util.Date;
import java.util.List;

public class Model 
{
    private static final String message = "Ein einfaches MVC-Beispiel am:\n";
    private static final Date today = new Date();
    private final List<String> listItems = new ArrayList<String>();

    public Model() 
    {
        listItems.add("Eins");
        listItems.add("Zwei");
        listItems.add("Drei");
        listItems.add("4");
        listItems.add("365");
    }
    /**
     * @return the message
     */
    public String getMessage() {
        return message;
    }

    /**
     * @return the today
     */
    public String getToday() {
        return new SimpleDateFormat("dd.MM.yyyy").format(today);
    }

    /**
     * @return the listItems
     */
    public List<String> getListItems() {
        return listItems;
    }
}
Controller:
Code:
package controller;

import java.awt.event.ActionEvent;
import java.awt.event.ActionListener;
import javax.swing.JOptionPane;
import view.View;
import model.Model;

public class Controller {

    private final Model model = new Model();
    private final View view = new View();
    
    public Controller() 
    {    
        view.getJButton().addActionListener(new ActionListener(){

            @Override
            public void actionPerformed(ActionEvent e) 
            {
                JOptionPane.showMessageDialog(view, model.getMessage()
                        + model.getToday());
            }
            
        });
        
        for(String item : model.getListItems())
        {
            view.getJComboBox().addItem(item);
        }
        
        view.setVisible(true);
    }
}
Main:
Code:
package main;

import controller.Controller;

public class Main {

    /**
     * @param args
     */
    public static void main(String[] args) 
    {
        new Controller();
    }

}
mfg Verjigorm
 
S

SlaterB

Gast
vor dem Beispiel sollte aber erstmal die Definition feststehen,
ich halte ja generell nicht so viel von festen Pattern, aber wenn ich mir den ersten google-Treffer zu MVC anschaue,
Model View Controller ? Wikipedia

dann steht da beispielsweise
"Das Modell enthält die darzustellenden Daten und gegebenenfalls (abhängig von der Implementation des MVC-Patterns) auch die Geschäftslogik. Es ist von Präsentation und Steuerung unabhängig. Die Bekanntgabe von Änderungen an relevanten Daten im Modell geschieht nach dem Entwurfsmuster „Beobachter“."

dein Modell halte ich nicht für ein Modell, das ist mit dem View überhaupt nicht verknüpft,
du erstellst die String-Daten zwar in einer separaten Klasse, danach werden sie aber in die JComboBox kopiert,

die model.Model-Klase ist danach obsolet, könnte neue Strings aufnehmen oder aus der JVM ausradiert werden,
das interessiert die View-JComboBox überhaupt nicht, die hat ihre eigenen Daten (kopiert)

wenn du dagegen ein ComboBoxModel schreiben würdest, das über Listener mit der JComboBox verknüpft ist, ja dann..


ein Controller, der nur ein JFrame zusammenbaut und sich nicht etwa um Aktionen der View (Button-Klicks) kümmert,
ist meiner Meinung nach auch nix echtes, die View kennt hier den Controller gar nicht (!),

wenn man 50% wegläßt, dann ist das vielleicht ein schön einfaches Beispiel, aber kann dann doch nicht MVC darstellen/ erklären :)
(edit: ok, Button ist drin, bisschen zu kurz draufgeschaut ;) )
 
Zuletzt bearbeitet von einem Moderator:

Geeeee

Bekanntes Mitglied
Finde es ok, aber den "reinen" Konstruktoraufruf etwas unschön, um das Programm losrödeln zu lassen. Evtl. für die bessere Übersicht im Controller eine init-methode für das Hinzufügen der Komponenten und start-Methode für das setVisible() (es ist irgendwie sinnentfreit, aber finde ich persönlich schöner für einen Anfänger).
Evtl. sogar die Instanziierung von Model und View in den Konstruktor schieben, weil du ja von einem _blutigen_ Anfänger sprichst.
Edit: gerade nochmal genauer hingeschaut, weil ja noch ein Eintrag vor mir "dazwischen" kam: Es wäre schon hilfreich wenn du: view.getJButton().addActionListener(this) einfügst und der Controller die actionPerformed abarbeitet.
 
Zuletzt bearbeitet:

Verjigorm

Top Contributor
@Slater:
Das mit dem ComboBoxModel hatte ich mir überlegt, aber wie gesagt, dass ist ein Informatikstudent im 2.Semester, der schlackert eh schon mit den Ohren, wenn ich ihm gleich 4 Klassen vorlege, da wollte ich nicht noch mit Interfaces, Oberklassen und irgendwelchen festen Modells kommen.

Aber ich glaube es wird nicht anders funktionieren, sonst kann man damit wohl doch kein MVC mehr erklären.

edit: Naja ich hab ihm erstmal Eclipse gezeigt, der hat bisher im Texteditor programmiert, damit ist er mal sicher einige Stunden/Tage beschäftigt :D
 

Marco13

Top Contributor
vor dem Beispiel sollte aber erstmal die Definition feststehen,
ich halte ja generell nicht so viel von festen Pattern, ...

Ja, neulich habe ich auch mal nach einer verbindlichen Definition von MVC gesucht. Nur indirekt in bezug auf eine "feste Struktur", sondern vielmehr in bezug auf die tatsächlichen Verantwortlichkeiten der einzelnen Klassen. Und nach langer Suche bin ich zu dem Schluss gekommen: Das gibt's nicht. Das kann man machen, wie man will :rolleyes: Im spziellen bezog sich meine Recheche auf den Controller...:

ein Controller, der nur ein JFrame zusammenbaut und sich nicht etwa um Aktionen der View (Button-Klicks) kümmert,
ist meiner Meinung nach auch nix echtes, die View kennt hier den Controller gar nicht (!),

Dann würde mich mal interessieren, was deiner Meinung nach ein "echter" Controller ist. In bestimmten (speziell Web-bezogenen) Anwendungen kann ein Controller tatsächlich ein echter "Mediator" sein, der sich um die gesamte Kommunikation kümmert, und z.B. die Daten in beide Richtungen über's Netztwerk schaufelt oder so. Aber in einer "normalen" Anwendung ist ein Controller in dieser Form IMHO sinnlos: Wenn man einen Controller hat, der 50 Listener-Interfaces implementiert, und 1:1 mit der View verdengelt ist, und nichts anderes macht, als Anfragen von der View ans Modell weiterzureichen, bringt er keinen Vorteil, sondern nur Nachteile. Bestätigt wurde diese (meine) Ansicht durch einen Haufen Seiten, auf denen vermeintliche Experten ihre Interpretation des MVC-Pattens mit konstruiert-gekünstelten Suggestivbeispielen zu verdeutlichen versuchten, die nichts (aber auch garnichts) mit realen Anwendungen zu tun hatten, und durch scheinbar banale Fragestellungen, die mit ausufernden Diskussionen benatwortet wurden, wie etwa unter Whatsa Controller Anyway (und etwas ähnliches steht uns vermutlich auch hier bevor ;) )

Ich bin inzwischen der Meinung, dass es in (nochmal: Nicht Web-basierten) Anwendungen häufig nicht "einen Controller" gibt, sondern dass jeder (möglicherweise anonyme) Listener, der an irgendeinem Button hängt (und der - ja - auch direkt in der View-Klasse stehen kann!) ein "kleiner Controller" ist.
 
S

SlaterB

Gast
'ein Controller' muss ja nicht 'eine Java-Klasse' bedeuten, mehrere Listener können das genauso sein, wenn man Controller eher als eine bestimmte Schicht in der Verarbeitung ansieht,

was der/ die nun für Aufgaben, hmm, ist doch nicht mein Thread hier ;)
lose überlegt und mit dem Wiki-Text verglichen:
der Controller ist NICHT die View, sondern was anderes,

nach Wiki "Sie [die Steuerung (Controller)] enthält weiterhin Mechanismen, um die Benutzerinteraktionen der Präsentation einzuschränken."
wäre ein solcher Einbau kein Grund, eine JTable zu überschreiben, sondern eine neue Basisklasse für (potentiell viele) Listener zu erstellen,
die auf Ereignisse reagieren und nun vielleicht erstmal schauen ob die stadardisierte Aktion erlaubt ist

--------

der Controller ist derjenige, der die Info erhält, dass Daten X neu zu laden sind,
dann irgendwo her die Daten holt, sie in Model Y schreibt, den Focus auf Textfeld Z legt und die Hintergrundfarbe von Statusfeld W ändert,
sowas macht keine JTable, hat ja auch keine Möglichkeiten dafür,

ob nun die Listener anonyme innere Klassen sind, die eigene JFrame-Unterklasse selber ActionListener implementiert oder ob es separate Klassen (eine oder mehrere) dafür gibt,
ist eine Frage der Organisation und der Doppelimplementation von Aufgaben, da kann sicher vieles falsch und schöner machen,
durch Listener + Models ist aber der MVC-Grundgedanke in Swing meist gar nicht zu vermeiden
 
Zuletzt bearbeitet von einem Moderator:

Marco13

Top Contributor
nach Wiki "Sie [die Steuerung (Controller)] enthält weiterhin Mechanismen, um die Benutzerinteraktionen der Präsentation einzuschränken."
wäre ein solcher Einbau kein Grund, eine JTable zu überschreiben, sondern eine neue Basisklasse für (potentiell viele) Listener zu erstellen,
die auf Ereignisse reagieren und nun vielleicht erstmal schauen ob die stadardisierte Aktion erlaubt ist

Hm - das mit der (nicht zu) überschreibenden JTable kann ich jetzt nicht ganz einordnen. Aber bei Swing hat man ja das klassische Beispiel, wo beim MVC einfach mal der C weggelassen wurde. Die Aussage "der Controller ist NICHT die View, sondern was anderes," stimmt daher nur ... bedingt .. eben nur, wenn es so ist, aber es kann auch anders sein :rolleyes: Bei einem Slider wird es deutlicher als bei einer JTable: Wenn man am Slider zieht, ändern sich die Werte des BoundedRangeModels. Der Slider ist demnach View UND Controller (oder nach meiner Definition: Der MouseMotionListener, der im Slider versteckt ist, ist der Controller)
 

Wildcard

Top Contributor
Alle Swing Objekte sind eigentlich Controller und die Trennung existiert dort, ist aber nicht sofort ersichtlich (und an manchen Stellen natürlich, wie bei fast jedem MVC, verwaschen).
Die JComponents sind Controller. Sie 'besorgen' sich die jeweiligen UI Klassen in Abhängigkeit des Look'n'Feels, welche die View repäsentieren.
Man kann das Messer auch etwas weiter oben ansetzen und sagen: Die Renderer sind die View.
 

Marco13

Top Contributor
Das mit dem "Messer weiter oben ansetzen" ist ein wichtiger Punkt (den hatte ich schonmal in einem der anderen MVC-Threads betont) : Die Klassen übernehmen ja bestimmte Rollen.

Man könnte sagen: Ein JSlider ist kein Controller, sondern eine View - schließlich "ist er etwas, was gezeichnet wird" - dass das painting an das UI delegiert wird, sieht man ja von außen nicht.

Man könnte auch sagen: Ein JSlider ist ein Controller, das SliderUI ist die View, das BoundedRangeModel ist das Model.

Aber wenn man das Messer (in diesem Sinne) weiter unten ansetzt, ist ein JSlider kein Controller, sondern doch wieder eine View, in der man eine Eigenschaft seines eigenen Datenmodells anzeigt. (Das "Modul" bestehend aus JSlider, SliderUI und BoundedRangeModel übernimmt bei gröberer Abstraktion die Rolle einer View).

Es ist eben schwierig, View und Controller voneinander zu trennen, und Zuständigkeiten klar zuzuweisen. Ich fand meine Odyssee durch die verschiedenen MVC-Beispiel-Seiten irgendwie ... fast schon "frustrierend".... Überzogen formuliert: MVC ist das hochgelobte Universalpattern ... bei dem aber zu 1/3 unklar ist, was es eigentlich ausmacht.... :rolleyes: Diese anderen 2/3 sind aber umso wichtiger: Das Modell sollte eigentständig und "isolierbar" sein. Den Rest können View und Controller unter sich ausmachen ... :)
 

Wildcard

Top Contributor
Das mit dem "Messer weiter oben ansetzen" ist ein wichtiger Punkt (den hatte ich schonmal in einem der anderen MVC-Threads betont) : Die Klassen übernehmen ja bestimmte Rollen.

Man könnte sagen: Ein JSlider ist kein Controller, sondern eine View - schließlich "ist er etwas, was gezeichnet wird" - dass das painting an das UI delegiert wird, sieht man ja von außen nicht.
Richtig. Swing Intern ist ein JSlider keine View, für mich, als Client, allerdings schon.

Es ist eben schwierig, View und Controller voneinander zu trennen, und Zuständigkeiten klar zuzuweisen. Ich fand meine Odyssee durch die verschiedenen MVC-Beispiel-Seiten irgendwie ... fast schon "frustrierend".... Überzogen formuliert: MVC ist das hochgelobte Universalpattern ... bei dem aber zu 1/3 unklar ist, was es eigentlich ausmacht.... :rolleyes: Diese anderen 2/3 sind aber umso wichtiger: Das Modell sollte eigentständig und "isolierbar" sein. Den Rest können View und Controller unter sich ausmachen ... :)
Ja, dem kann ich zustimmen. Ich habe bisher eigentlich nur sehr wenige real life Beispiele gesehen, bei denen die View/Controller Trennung sauber durchgezogen wird. Meistens verschmelzen View und Controller auf die eine oder andere Art.
Wenn du dich aber für ein solches Interessierst, schau dir GEF an. Wirklich interessante Sache.

Wie die Trennung praktisch umgesetzt wird ist hier beschrieben:
GEF Description - Eclipsepedia
 

Marco13

Top Contributor
Ich habe bisher eigentlich nur sehr wenige real life Beispiele gesehen, bei denen die View/Controller Trennung sauber durchgezogen wird. Meistens verschmelzen View und Controller auf die eine oder andere Art.

"Sauber" - das klingt jetzt aber wieder, als sei es irgendwie besonders erstrebenswert, die beiden komplett zu trennen. Abgesehen von den schon erwähnten Ausnahmen (Web-Zeux und Spezialfälle) sehe ich im allgemeinen keinen Grund, das zu tun. Es ist im allgemeinen kaum praktikabel, das umzusetzen, und erfordert viel Aufwand und bringt IMHO keinen Vorteil...

Aber vielleicht ändert sich meine Ansicht dazu ja noch - das mit dem GEF werd' ich mir auf jeden Fall mal :rtfm: en.
 

Wildcard

Top Contributor
"Sauber" - das klingt jetzt aber wieder, als sei es irgendwie besonders erstrebenswert, die beiden komplett zu trennen. Abgesehen von den schon erwähnten Ausnahmen (Web-Zeux und Spezialfälle) sehe ich im allgemeinen keinen Grund, das zu tun. Es ist im allgemeinen kaum praktikabel, das umzusetzen, und erfordert viel Aufwand und bringt IMHO keinen Vorteil...
Ja... für die normale GUI bin ich mir auch nicht sicher ob das wirklich erstrebenswert ist. Aber du verstehst schon was ich mit sauber getrennt meine, also lassen wir es dabei :)
GEF ist allerdings primär für grafische Editoren gedacht, hautpsächlich Diagramme.
Ich sag mal so, ich habe jahrelang an einem solchen grafischen Editor gearbeitet in dem Model View und Control zu einem Wollknäul verschmolzen sind und dann weißt du ein 'sauber' getrenntes Framework doch sehr zu schätzen.
Im Falle von Diagrammen halte ich die konsequente Trennung für absolut sinnvoll. Bei Widget basierten GUIs... wer will da schon päpstlicher als der Papst sein.
 

André Uhres

Top Contributor
Ich finde das Beispiel auch OK, ausser eben die Modelgeschichte.
Das könnten wir aber leicht anpassen, etwa so:
Code:
public class Model {
...
    private DefaultComboBoxModel listItems = new DefaultComboBoxModel();
    public Model() {
        listItems.addElement("Eins");
        listItems.addElement("Zwei");
...
    public DefaultComboBoxModel getListItems() {
        return listItems;
    }
}
Code:
public class Controller {
...
    public Controller() {
...
        view.getJComboBox().setModel(model.getListItems());
...
 
G

Gast2

Gast
Servus,

wenn so ein Thema schon mal diskutiert wird würde ich gern mal die Meinung zu so einem Aufbau hören. Was man besser/geschickter machen kann. Und ob ich eventuell grundsätzlich etwas falsch verstanden hab.

View mit main:
[HIGHLIGHT="Java"]
import java.awt.BorderLayout;
import java.awt.event.ActionEvent;
import java.awt.event.ActionListener;
import java.beans.PropertyChangeEvent;
import java.beans.PropertyChangeListener;
import java.util.List;

import javax.swing.DefaultComboBoxModel;
import javax.swing.JButton;
import javax.swing.JComboBox;
import javax.swing.JFrame;
import javax.swing.JTextField;

public class View extends JFrame implements PropertyChangeListener {

private JTextField txtEingabe;
private JComboBox cAusgabe;
private JButton button;
private Controller controller;

public View(Controller c) {
super("MVC Beispiel");
this.controller = c;
controller.addListener(this);
txtEingabe = new JTextField(30);
cAusgabe = new JComboBox();
button = new JButton("Hinzufügen");
add(txtEingabe, BorderLayout.NORTH);
add(cAusgabe, BorderLayout.CENTER);
add(button, BorderLayout.SOUTH);
button.addActionListener(new ActionListener() {

public void actionPerformed(ActionEvent e) {
controller.addItem(txtEingabe.getText());

}

});
pack();
setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
setVisible(true);
}

public void propertyChange(PropertyChangeEvent evt) {
if (evt.getPropertyName().equals(Controller.ITEMS_CHANGE)) {
List<String> newValue = (List<String>) evt.getNewValue();
cAusgabe.setModel(new DefaultComboBoxModel(newValue.toArray()));
}

if (evt.getPropertyName().equals(Controller.ADD_ITEM)) {
String newValue = (String) evt.getNewValue();
cAusgabe.addItem(newValue);
}

}

public static void main(String[] args) {
Controller contoller = new Controller();
new View(contoller);
}

}

[/HIGHLIGHT]

Controller

[HIGHLIGHT="Java"]
import java.beans.PropertyChangeEvent;
import java.beans.PropertyChangeListener;
import java.beans.PropertyChangeSupport;
import java.util.List;

public class Controller {

public static final String ITEMS_CHANGE = "itemchange";
public static final String ADD_ITEM = "itemadd";
private Model model;
private PropertyChangeSupport listeners = new PropertyChangeSupport(this);

public Controller() {
model = new Model();
}

public void setItems(List<String> items) {

List<String> old = getItems();
if (old.equals(items)) {
model.setItems(items);
firePropertyChange(new PropertyChangeEvent(this, ITEMS_CHANGE, old, items));
}
}

public List<String> getItems() {
return model.getItems();
}

public void addItem(String item) {
model.addItem(item);
firePropertyChange(new PropertyChangeEvent(this, ADD_ITEM, null, item));
}

public void addListener(PropertyChangeListener listener) {
listeners.addPropertyChangeListener(listener);
}

public void removeListener(PropertyChangeListener listener) {
listeners.removePropertyChangeListener(listener);
}

public void firePropertyChange(PropertyChangeEvent event) {
listeners.firePropertyChange(event);
}

}

[/HIGHLIGHT]

[HIGHLIGHT="Java"]
import java.util.ArrayList;
import java.util.List;


public class Model {

private List<String> items;

public Model()
{
setItems(new ArrayList<String>());
}

public void setItems(List<String> items) {
this.items = items;
}

public void addItem(String item)
{
items.add(item);
}

public List<String> getItems() {
return items;
}
}


[/HIGHLIGHT]
 
S

SlaterB

Gast
meiner Ansicht nach ist dein Controller komplett noch Model,
es macht zwar Sinn, zwischen reinen Daten aller höchstens mit ner Collection und einem Ding zur Verwaltung von Listenern und Events zu unterscheiden,
aber dafür gibts ja ComboBoxModel & Co., und das sind Model, wie der Name schon sagt,

wirklich Controller ist Zeile 34 im View-Codeblock

Zeile 44-55 im View ist was seltsames zwischen Model und View, was normalerweise eine JTable zum TableModel schon automatisch kann,

je nach Abstraktionsebene (View ist nur der Renderer) verschiebt sich natürlich die Interpretation
 
Zuletzt bearbeitet von einem Moderator:
G

Gast2

Gast
ok ich mache mit den daten ja nichts spannendes :oops:...
aber das model könnte ja noch geschäftslogik enthalten oder die daten auswerten...
Klar gibt es ein ComoboxModel, aber ich dachte so hab ich ein "reines" Datenmodel
und wenn ich mehrer Panels(Views) hätte, die gleichen Daten benutzen und anderst darstellen, können alle Views diese benutzen oder wie würdest du sowas machen???
und Zeile 44-55 wie würdest du die View benachrichtigen, dass sich das Model gändert hat???
Wär echt cool wenn mal ein paar erfahrene Programmierer sagen könnten wie Sie das in ihre Projekte so realisieren =)...
Weil ich hab auch schon gesehen, dass das Model die Listener aufnimmt und die Event verschickt wenn es sich geändert hat, bei anderen macht es der Controller usw.
Wie ist des denn eigentlich üblich???:rtfm:

Gruß
 
S

SlaterB

Gast
es spricht ja nix gegen diese Trennung/ Eigenprogrammierung,
wenn es Swing-Models nicht gäbe, dann ist es ja nicht verboten sie zu erfinden ;)

> können alle Views diese benutzen oder wie würdest du sowas machen???

ich hab das kürzlich mal gemacht und mir den coolen Begriff MetaModel ausgedacht, ein MetaModel hat mehrere normale Swing-Model als Listener, die wiederum ihre Views informieren, siehe auch
http://www.java-forum.org/awt-swing-swt/80557-jlist-jtree-jtextarea-daten-refresh.html
(wenn auch von mir da nicht viel steht)
(edit: aber du hast in dem Thema auch schon gepostet ;) )

deinem Controller gar nicht unähnlich, man müsste die Klasse nur umbenennen

und die Daten ins ComboBoxModel zu kopieren ist dann meiner bescheidenen Meinung nach redundant,
lieber ein neues ComboBoxModel schreiben, welches bei getSize() die aktuelle Länge des MetaModels abfragt,
bei getElementAt(int index) auch beim MetaModel nachfragt usw.,
ein leeres Model, welches nur das MetaModel kapselt und dessen Änderung-Events in die andere Richtung übersetzt und weiterleitet
 
G

Gast2

Gast
(edit: aber du hast in dem Thema auch schon gepostet )

ja aber bei dem Adapter bin ich dann ausgestiegen, weil ich nicht genau wusste was damit gemeint war bzw. wie es gemeint war die zu realisieren :p
 

Marco13

Top Contributor
Ich finde das Beispiel auch OK, ausser eben die Modelgeschichte.
Das könnten wir aber leicht anpassen, etwa so: ...
[s.o.]

Also DAS kapier' ich jetzt nicht ???:L (Ehrlich gesagt bin ich sogar SEHR irritiert, dass DU das so vorschlägst... ???:L ).

Wenn überhaupt, dann würde man da sicher kein DefaultComboBoxModel zurückgeben, sondern ein ComboBoxModel. Das kann noch ein Copy&Paste-Fehler sein, aber ... meine Irritation bezieht sich auf einen viel allgemeineren Punkt: Wenn man sein eigenes Model schreibt, dann ist es doch (zurückhaltend formuliert...) unzweckmäßig, sich auf ein Swing-Model zu stützen. Wenn das ganze dann mal in einer JList dargestellt werden soll, was soll man dann machen? Das ComboBoxModel in ein ListModel ändern? Eine Implementierung von ListModel anbieten, die an ein ComboBoxModel delegiert? Häm... ne, ich versteh' das gerade nicht ... :bahnhof:
 
S

SlaterB

Gast
nur für die Möglichkeit, dass es mal auch auf einer JList dargestellt werden soll, soll man sich vorsorglich die Arbeit eines eigenen Models machen?
welchen Sinn hat das denn

man kann doch dann anpassen, wenn es dazu kommt, wieso vorher?
zudem in einem einfachen Beispiel doch sehr deplaziert (ups, SirWayne hat das ja auch ;) )

> Wenn man sein eigenes Model schreibt

macht ja keiner, falls du nicht eine simple Klasse, die ein DefaultComboBoxModel enthält, schon als eigenes Model ansiehst,
auf diese recht leere Klasse kann man sicherlich verzichten und nur das ComboBoxModel irgendwo speichern,
denkbar,

aber wenn es wie im Ursprungsbeispiel zusätzlich noch den String + das Datum enthält, dann ist das eben eine Art Sammelstelle für mehrere Model
(wobei String + Datum ganz andere Arten von Model sind ohne Listener usw., das ist ein Thema für sich)
 
G

Gast2

Gast
ja aber ich sehe es bis jetzt auch so wie Marco...
Da es sich um ein einfaches Beispiel handelt sollte man jetzt nicht auf dem einfachen Model rum "nörgeln"...
Wenn ich die Liste in verschiedenen Komponenten oder sonstigen Views angezeigt werden sollen wieso dann auf ein SwingModel beziehen... in dem model könnten ja auch z.B. noch Berechnungen für irgendwelche Statistiken gemacht werden usw. oder???

Aber ich weiß immer noch nicht wie du es bewerkstelligen willst, wenn sich dein Model ändert, dass die Views das mitbekommen wenn du meine Listener geschichte nicht so gut fandest??
Könnte mal jemand was posten wie man es auch anders machen könnte, würde mich interessiert :):)...
 
S

SlaterB

Gast
wo habe ich denn geschrieben, dass ich deine Listener-Geschichte nicht gut finde?
ohne Listener gehts nicht, für ein Model für mehrere Views schon gar nicht, was ich allerdings als Eingangsbeispiel etwas übertrieben finde,

wenn man nur ein View und ein Model hat, dann sind eigene Listener + Events statt DefaultComboBoxModel etwas merkwürdig, aber nicht unbedingt falsch,
eigene Listener, die dann doch nur ein DefaultComboBoxModel befüllen noch seltsamer doppelt gemoppelt,
das könnte man vielleicht als 'nicht gut von mir bewertet' interpretieren, ok ;)

dass das im Sinne von ein Model für mehrere Views wiederum ok ist, habe ich aber geschrieben:
> deinem Controller gar nicht unähnlich, man müsste die Klasse nur umbenennen
 
G

Gast2

Gast
wo habe ich denn geschrieben, dass ich deine listener-geschichte nicht gut finde?
ohne listener gehts nicht, für ein model für mehrere Views schon gar nicht, was ich allerdings als Eingangsbeispiel etwas übertrieben finde
Ja ich finde wenn man schon MVC erklärt sollte man das listener konzept schon anschlagen da bei der GUI Komponenten z.B. JButton gar nichts funktioniert ;)...

Ok das andere habe ich wohl missverstanden :p ...

1.Aber wie macht ihr das lasst ihr eurem controller events schicken oder macht ihr das direkt im Model????
2. bei dem 1. Beispielt instanziert er die view im controller und benutzt dort auch die Swing komponenten mit weiteren Listener... ist doch ziemlich unpratikabel oder?
3. hätte ich noch ne arichtektur frage ;)... wenn ihr ein controller, welcher die listener added, habt und mehrer views... macht ihr euren controller dann statisch oder übgebt ihr ihm konstruktor???

irgendwie beteiligen sich bis jetzt wenig an diesem thema :bae:...
hab gehofft man bekommt paar arichtektur tipps von unseren "Java Gurus" :D...
 
Zuletzt bearbeitet von einem Moderator:

Marco13

Top Contributor
nur für die Möglichkeit, dass es mal auch auf einer JList dargestellt werden soll, soll man sich vorsorglich die Arbeit eines eigenen Models machen?
welchen Sinn hat das denn

man kann doch dann anpassen, wenn es dazu kommt, wieso vorher?

[...]

> Wenn man sein eigenes Model schreibt

macht ja keiner, falls du nicht eine simple Klasse, die ein DefaultComboBoxModel enthält, schon als eigenes Model ansiehst,

Ich kapier das gerade echt nicht ???:L

Man modelliert irgendwas. Als Dummy-Beispiel eine Liste für Namen und Geburtsdaten. Das Modell sollte KOMPLETT unabhängig von der View sein. Wenn man das Modell schreibt, muss man vergessen können, dass es Swing überhaupt gibt. Darum (und man könnte sagen: NUR darum) geht es doch bei MVC eigenttlich - das ist doch (zumindest nach meinem Verständnis) Sinn und Kern des ganzen Patterns.

Man definiert also für diesen Fall das (und genau das) was mit dem Modell gehen soll.
Code:
interface Model
{
    int getNumPersons();
    Date getDate(int i);
    String getName(int i);
    ..
}
Und im Iedalfall sollte sich dieses interface nie mehr ändern.

Das Modell ist jetzt fertig modelliert. Es kann das (und genau das) was es können soll. Es ist das (und genau das) modelliert, was das Modell ausmacht.

So. Weil du das auch immer machst ;) hier mal eine Trennlinie:

---------

Jetzt kommt der zweite Teil: Die View(s)

Man schreibt eine View, die ein Modell bekommt (das interface, bei dem sie sich darauf verlassen kann, dass es im Idealfall immer so bleiben wird, wie es ist). Diese View stellt die Daten aus dem Modell dar.

Wenn man das oben beschriebene Modell in zwei ComboBoxes darstellen will, wäre es natürlich "bequem" und "praktsich", wenn man die Daten als zwei ComboBoxModels bekommen würde. Aber die View muss sich am Modell orientieren, und nicht umgekehrt. Sich dann "grundlos" im Modell auf etwas festzulegen, was mit dem abstrakten Gebilde das ein Datenmodell darstellt, nichts zu tun hat, nur weil das für eine bestimmte View-Implementierung "praktisch" ist, kann ja nicht das Ziel sein.

Ein Problem hätte man dann spätestens, wenn es mehrere Views gibt, die das ganze dann
- in zwei ComboBoxes
- in einer ComboBox(!)
- in einer JList
- und in einer JTable
darstellen wollen: wie soll man da dann das "passende" Swing-Modell reinpfriemeln? Das gibt es nicht. Aber für das oben beschriebene, allgemeingültige Modell kann man mit minimalem Aufwand ComboBoxModels, ListModels und TableModels schreiben, die das echte Modell als Delegate verwenden. Dass es prinzipiell möglich wäre, mehrere ListModels zu einem TableModel zusammenzuwursten hatte ich ja schon erwähnt, aber sich bei der Beschreibung des Modells an einer "bevorzugten" oder "im ersten Moment sinnvoll erscheinenden" View zu orientieren erscheint mir fragwürdig ???:L
 
S

SlaterB

Gast
alles schon bekannte Themen, ich will nicht auf alles durcheinander antworten und gar wiederholend, daher zum einen nur kurz zwei Zitate:
es macht zwar Sinn, zwischen [zum einen] reinen Daten allerhöchstens mit ner Collection und [zum anderen] einem Ding zur Verwaltung von Listenern und Events zu unterscheiden,
aber dafür gibts ja ComboBoxModel & Co., und das sind Model, wie der Name schon sagt,
> Das Modell ist jetzt fertig modelliert

zum Model gehört auch Benachrichtigung über Änderungen,
gerne in zwei unterschiedlichen Klassen (Daten mit ComboBoxModel), aber jedenfalls Teil des Models, nicht der View


+
ich hab das kürzlich mal gemacht und mir den coolen Begriff MetaModel ausgedacht, ein MetaModel hat mehrere normale Swing-Model als Listener, die wiederum ihre Views informieren

--------

außerdem habe ich eh schon auf eine Gelegenheit gewartet, einen kürzlich aufgeschnappten schlauen Satz zu zitieren:
Vorsicht, Falle Nummer 1: MVC ist kein Schichtenmodell

Wir haben in der Praxis und in der Literatur schon häufiger eine Interpretation von MVC vorgefunden, die unserer Meinung nach einfach falsch ist.

MVC ist ein Muster für Interaktionen in der Präsentationsschicht. Es setzt damit bereits voraus, dass wir uns grundsätzlich auf eine Architektur eingelassen haben, die Schichten vorsieht und die Präsentation vom Rest der Anwendung trennt.
Galileo Computing :: Praxisbuch Objektorientierung – 8.2 Die Präsentationsschicht: Model, View, Controller (MVC)

MVC spielt sich (je nach Interpretation) nur innerhalb der Präsentation ab,
es ist ganz ok wenn alle Model und Listener auf Swing-Interfacen aufbauen, das Modell in MVC muss nicht auch die Datenbankschicht beinhalten

dass man mit nur einem Model in seinen Möglichkeiten begrenzt sein kann, ist davon unberührt, Stichwort MetaModel ;)
 
Zuletzt bearbeitet von einem Moderator:
G

Gast2

Gast
Kannst du ein kleines Beispiel von deinem MetaModel posten vielleicht kann iches mit dann vorstellen ...^^
 

Marco13

Top Contributor
Ok, teilweise nähert sich das jetzt an.

Die Benachrichtigungen über Änderungen hatte ich bei dem Dummy-Beispiel weggelassen, da es ja erstmal Read-Only war. In bezug auf das "Meta-Modell" (viele wissenschaftliche Veröffentlichungen bestehen bei genauerem Hinsehen nur daraus, dass ein Begriff für etwas altbekanntes definiert wird ;) : Ich finde es fragwürdig (d.h. nicht "nicht gut" oder "gut", sondern nur fragwürdig) ein (potentiell ZU spezielles) Swing-Model innerhalb seines eigenen Modelles zu verwenden, und das dann nach draußen zu exponieren. Dass ein Modell (ähnlich(!) wie bei einer Facade) auch aus mehreren Teilen bestehen kann, ist aber klar.

Dass MVC ein Schichtenmodell ist wurde auch nicht angedeutet (auch wenn man bestimmte Aussagen vielleicht so interpretieren könnte). Aber ich finde, dass das Modell unabhängig von der View entstehen sollte - und das ""Wissen"", dass man irgendwelche Daten in irgendeiner bestimmten Swing-Component darstellen will, ist lange nicht so sicher, wie das Wissen darüber, was die Daten eigentlich SIND....

EDIT: Versuch einer Präzisierng - hab' gerade leider nicht viel Zeit für elaborierten code..
 
S

SlaterB

Gast
hab doch gesagt, dass es etwa wie deins ist, aber bitte ;)
so wie ich es benötigte ein Model für zwei Tabellen, die unterschiedliche Anteile derselben Daten anzeigen,

ändert man in einer Tabelle den Vornamen, erscheint er auch in der anderen

Code:
public class TestGUI extends JFrame {

	public TestGUI() {

		PersonMetaModel metaModel = new PersonMetaModel();
		JTable tableWith = new JTable(new PersonTableModel(true, metaModel));
		JTable tableWithout = new JTable(new PersonTableModel(false, metaModel));

		add(tableWith, BorderLayout.NORTH);
		add(tableWithout, BorderLayout.SOUTH);
		setSize(400, 300);
		setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
		setVisible(true);

	}

	public static void main(String[] args) {
		new TestGUI();
	}

}

class Person {
	String firstName;

	String lastName;

	public Person(String firstName, String lastName) {
		super();
		this.firstName = firstName;
		this.lastName = lastName;
	}

}

class PersonMetaModel {
	private List<ChangeListener> listener = new ArrayList<ChangeListener>();

	private List<Person> personList = new ArrayList<Person>();

	
	public PersonMetaModel() {
		this.personList.add(new Person("Karl","Ranseier"));
		this.personList.add(new Person("Boris","Becker"));
	}

	public Person get(int index) {
		return this.personList.get(index);
	}

	public int size() {
		return this.personList.size();
	}

	public void changed() {
		for (ChangeListener c : this.listener) {
			c.changed();
		}
	}

	public void addListener(ChangeListener listener) {
		this.listener.add(listener);
	}
}

interface ChangeListener {
	public void changed();
}

class PersonTableModel extends AbstractTableModel implements ChangeListener {

	private boolean showLastName = false;

	private PersonMetaModel metaModel;

	public PersonTableModel(boolean showLastName, PersonMetaModel metaModel) {
		this.showLastName = showLastName;
		this.metaModel = metaModel;
		this.metaModel.addListener(this);
	}

	public int getColumnCount() {
		return (this.showLastName ? 2 : 1);
	}

	public int getRowCount() {
		return this.metaModel.size();
	}

	public Object getValueAt(int rowIndex, int columnIndex) {
		Person p = this.metaModel.get(rowIndex);
		if (columnIndex == 0) {
			return p.firstName;
		} else {
			return p.lastName;
		}
	}

	public boolean isCellEditable(int rowIndex, int columnIndex) {
		return true;
	}

	public void setValueAt(Object aValue, int rowIndex, int columnIndex) {
		// ob das hier erlaubt ist oder eine andere Instanz das machen sollte,
		// sei außen vor, das funktioniert ja hier ganz ohne Listener
		Person p = this.metaModel.get(rowIndex);
		if (columnIndex == 0) {
			p.firstName = (String) aValue;
		} else {
			p.lastName = (String) aValue;
		}
		this.metaModel.changed();
	}

	public void changed() {
		fireTableDataChanged();
	}

}
 

Marco13

Top Contributor
(So als Nachtrag: Mit sowas würde ich auch konform gehen - einige Aussagen vorher klangen für mich nach etwas ganz anderem, als das, was du gerade gepostet hast)
 
S

SlaterB

Gast
ich fand Swing-Models früher (auch?) relativ speziell, aber im Laufe der Zeit immer weniger,
im Grunde sind es beliebige Container, die nur size, get + vielleicht set anbieten und irgendeine Art von Listener unterstützen, welche auch nur ein Interface sind,

weniger kann man eigentlich nicht verlangen, irgendeine kleine Schnittstelle muss man den komplexen View-Komponenten wie JTable ja geben
 
G

Gast2

Gast
(So als Nachtrag: Mit sowas würde ich auch konform gehen - einige Aussagen vorher klangen für mich nach etwas ganz anderem, als das, was du gerade gepostet hast)
Dito.

Ich hab einige Aussagen GANZ ANDERS interpretiert und verstanden ...
 
Zuletzt bearbeitet von einem Moderator:

Verjigorm

Top Contributor
Memo an mich selbst:
Poste keine "einfache" Frage(n) mehr über die sich eine halbe Community den Kopf zerbricht :D
 
G

Gast2

Gast
dann war das Beispiel ja doch nützlich

Schon ;)

Memo an mich selbst:
Poste keine "einfache" Frage(n) mehr über die sich eine halbe Community den Kopf zerbricht

halbe community ist ein bischen übertrieben ;)... wäre mir aber lieb gewesen...
hätte mich interessiert wie das die anderen so handhaben bzw. sehen ;)
 

Verjigorm

Top Contributor
Naja ist ja Freitag Mittag, da schaut vielelicht nicht mehr jeder hier rein ;)

In diesem Sinne:
Schönes Wochenende
 

mvitz

Top Contributor
Memo an mich selbst:
Poste keine "einfache" Frage(n) mehr über die sich eine halbe Community den Kopf zerbricht :D

Naja, ich finde so Threads immer sehr interessant und aufschlussreich, auch wenn ich bei solchen Threads dann häufig nur mitlese, bin ich der Meinung das man gerade durch solche Threads auch lernen und eine andere Sicht auf spezielle Dinge bekommen kann.
 

André Uhres

Top Contributor
Wenn das ganze dann mal in einer JList dargestellt werden soll, was soll man dann machen? Das ComboBoxModel in ein ListModel ändern? Eine Implementierung von ListModel anbieten, die an ein ComboBoxModel delegiert? Häm... ne, ich versteh' das gerade nicht ... :bahnhof:
Ja, ich versteh's auch nicht, warum Swing nicht einheitlich in den Models ist.
 

Marco13

Top Contributor
Ehrlich gesagt war ich leicht :oops: als ich gemerkt habe, dass ich mir für die Verdeutlichung dieses Punktes genau das besch****enste Beispiel rausgesucht hatte, das es gibt: ComboBoxModel erbt von ListModel... :oops: Aber an der grundsätzlichen Problematik (wie etwa im anderen Beispiel: 2 ListModels vs. ein 2-spaltiges TableModel oder so) änder das ja nichts.
 

Ebenius

Top Contributor
Ist nicht ein Modell die Schnittstelle für die Daten einer Komponente? Sollte nicht das Modell die Daten so anbieten wie dies für die Komponente sinnvoll ist? Wäre nicht eine zweite Spalte in einer Liste äußerst verwunderlich? Hällt den Entwickler die Existenz zweier verschiedener Interfaces davon ab, eine Klasse Modell für zwei Komponentenarten zu sein?

Fragt sich der Ebenius.
 
G

Gast2

Gast
Ist nicht ein Modell die Schnittstelle für die Daten einer Komponente? Sollte nicht das Modell die Daten so anbieten wie dies für die Komponente sinnvoll ist? Wäre nicht eine zweite Spalte in einer Liste äußerst verwunderlich? Hällt den Entwickler die Existenz zweier verschiedener Interfaces davon ab, eine Klasse Modell für zwei Komponentenarten zu sein?

Fragt sich der Ebenius.

Ja okay wir haben jetzt einfaches Beispiel, also ich finde es besser die Daten "neutral" zu halten und nicht von irgendwelchen Swing sonstige Komponente Sachen abhängig zu machen, weil so kann die Logik auch für eine SWT, Webanwendung usw. verwendet werden oder würdest du dann jedes mal dein Model anpassen oder neue Interface anbieten????
Also ich finde die View sollte die Daten neutral bekommen und dann darstellen

Gruß
 

Ebenius

Top Contributor
Ohje muss ich getrunken haben. :D Aber was ich meinte ist klar. Ich kann doch eine Klasse haben, die sowohl das ListModel als auch das TableModel-Interface implementiert und die selben Daten für zwei verschiedene Komponenten modelliert.

Ebenius
 

André Uhres

Top Contributor
Ich kann doch eine Klasse haben, die sowohl das ListModel als auch das TableModel-Interface implementiert und die selben Daten für zwei verschiedene Komponenten modelliert.
Sicher kann man das machen, aber wozu so ein Aufwand für unser simples Beispiel??
Mein Vorschlag oben hat einfach zum Ziel, den Kopiervorgang einzusparen, der imho auch in diesem einfachen Beispiel sinnlos ist. Ob der Rückgabewert DefaultComboBoxModel, ComboBoxModel oder ListModel heißt, ist dabei wohl von untergeordneter Bedeutung. Allgemein wird aber ein Programm flexibler sein, wenn wir ein passendes Interface benutzen, um auf ein Objekt zuzugreifen (respektiv die oberste Klasse in der Hierarchie, die die gewünschte Funkionalität hat).
 
Zuletzt bearbeitet:

Wildcard

Top Contributor
SirWayne, modellier dir einfach mal ein Model mit EMF, dann siehst du wie so etwas idealerweise aussehen sollte.
 
G

Gast2

Gast
ja wollte ich schon lang mal machen, dachte aber dass man für so ein simples Beispiel auch so eine gute/sinvolle Erklärung bekommen kann, wie es am besten gemacht werden sollte ;)
 
G

Gast2

Gast
Ah was ich noch sagen/fragen wollte ich denk mal nicht jeder hat sich mit EMF seine Models generieren lassen oder schon mal gemacht, von daher muss ja auch jeder Erfahrungen darüber berichten können wie er/sie sowas angeht bzw. sieht ;)...


Noch ne Frage: wo benachrichtigt ihr die listeners/views, dass sich das model geändert hat?

im controller? oder im model??? ...
 

Ebenius

Top Contributor
Das Modell gibt dem Controller Bescheid, wenn es sich (und in welcher Weise es sich) verändert hat. Views sind passiv. Sie reagieren nicht automatisch auf Veränderungen sondern nur auf Befehl (des Controllers). Der Controller entscheidet (zum Beispiel anhand eines / mehrerer Events des Modells / der Modelle) wann er welche View(s) aktualisieren möchte.

Ebenius
 

Stefan S.

Aktives Mitglied
Das Modell gibt dem Controller Bescheid, wenn es sich (und in welcher Weise es sich) verändert hat. Views sind passiv. Sie reagieren nicht automatisch auf Veränderungen sondern nur auf Befehl (des Controllers). Der Controller entscheidet (zum Beispiel anhand eines / mehrerer Events des Modells / der Modelle) wann er welche View(s) aktualisieren möchte.

Das ist nicht richtig. Views implementieren das Observer Muster und reagieren auf Veränderungen des Models dynamisch.

Der Controller ist eine reine Zwischenschicht, zwischen View und Model. Das Model hat intern keine "Ahnung" vom View. Es stellt nach außen nur ein Interface bereit, so dass sich Beobachter beim Model registrieren können und damit der Controller zugreifen kann.

Der Controller ist zuständig für die Steuerung. Er nimmt die Benutzereingaben der View entgegen und führt entsprechende Operationen am Model aus.

Das Model enthält auch die Anwendungslogik für die Datenverarbeitung. Besonders klar wird es bei einer Datenbankanwendung. Das Model stellt den Zugriff bereit.

Wenn man eine GUI bastelt, sollte man die Listener in der View halten. Wird ein Button gedrückt, ruft man aus dem Listener den Controller auf, der dann entscheidet was das Drücken dieses Button für Konsequenzen für das Model und die View hat.
 
Zuletzt bearbeitet:

André Uhres

Top Contributor
Ich habe eine Frage: sollten wir mit dem Einsatz von Modelevents nicht vorsichtig sein? Sollten die Events nicht möglichst nur von der View ausgehen? Jedenfalls scheint's mir gefährlich zu werden, wenn von zwei Seiten geschossen wird, oder wie seht ihr das?
 

Ebenius

Top Contributor
Das ist nicht richtig. Views implementieren das Observer Muster und reagieren auf Veränderungen des Models dynamisch.
:oops: Ohje, stimmt. Was ich beschrieben hab kommt schon eher aus der Model-View-Adapter-Architektur (wenn man "Controller" durch "Adapter" austauscht). Oder bin ich dabei noch immer auf dem Holzweg?

Ebenius
 
Status
Nicht offen für weitere Antworten.
Ähnliche Java Themen
  Titel Forum Antworten Datum
W While Schleife funktioniert nicht ganz Allgemeine Java-Themen 4
GreenTeaYT Verstehe nicht ganz das Observer Pattern in einer Arrayliste? Allgemeine Java-Themen 3
K Java installiert sich nicht ganz Allgemeine Java-Themen 15
O BufferedReader von ganz unten anfangen zu lesen Allgemeine Java-Themen 7
N Vererbung Static & private fields - Nicht ganz einfach? Allgemeine Java-Themen 4
M Exception ganz sehen Allgemeine Java-Themen 2
C Hilfe! Mein Java mag nich mehr ganz... Allgemeine Java-Themen 11
F Wie zur Laufzeit ganz neue Objekte erzeugen? Allgemeine Java-Themen 5
N HTML2TXT ganz einfach Allgemeine Java-Themen 6
Horst79 Ein ganz simpler filebrowser als applet Allgemeine Java-Themen 2
C Listen in Java. Anehängter Code nicht ganz klar Allgemeine Java-Themen 19
H ganz simpler chat Allgemeine Java-Themen 8
S Ganz übler Anfänger - Webseiten mit Java Allgemeine Java-Themen 3
G Java-Exceptions werden nicht ganz angezeigt. Wo ändern? Allgemeine Java-Themen 3
C Java Native binding Code will nicht so ganz Allgemeine Java-Themen 2
L Mal ne ganz doove Frage. Allgemeine Java-Themen 2
J Ganz allgemeine Frage Allgemeine Java-Themen 3
F Einfaches Beispiel mit Netty Socket.IO Allgemeine Java-Themen 6
temi Einfaches Eventhandling führt zu Brett vor Kopf Allgemeine Java-Themen 2
S Einfaches Programm programmieren Allgemeine Java-Themen 5
K Einfaches Array in 2 neue aufteilen. Allgemeine Java-Themen 2
A Lotto, einfaches Problem? Allgemeine Java-Themen 11
E einfaches Beispiel zu MVC und Sinn V --> M ? Allgemeine Java-Themen 22
M einfaches Lagerverwaltungsapp Allgemeine Java-Themen 4
Gossi Threads Suche ein (einfaches) Beispiel Allgemeine Java-Themen 5
E Beispiel für ein möglichst einfaches Interface Allgemeine Java-Themen 22
E Einfaches Problem mit Tomcat Allgemeine Java-Themen 18
D Einfaches Nutzen von Plugins mittels generischer Methode Allgemeine Java-Themen 3
W Einfaches Installer/setup tool für java programme das. Allgemeine Java-Themen 4
E (einfaches) Problem mit import und package (export) Allgemeine Java-Themen 4
J Einfaches AspectJ Beispiel Allgemeine Java-Themen 2
reibi javax.crypto.SecretKey - Einfaches Beispiel gewünscht ;-) Allgemeine Java-Themen 2
T Einfaches Java Programm PHP5-fähig machen Allgemeine Java-Themen 19
V Suche einfaches JasperReports Tutorial Allgemeine Java-Themen 23
F Log4j2 SMTP Appender Beispiel Allgemeine Java-Themen 3
marcooooo Frage zum Beispiel im Anhang Allgemeine Java-Themen 16
O Suche größeres Beispiel für WebserverAnwendung mit Java Allgemeine Java-Themen 2
B MVC-Pattern größeres Beispiel Allgemeine Java-Themen 16
M Fabrik Methode, gutes Beispiel? Allgemeine Java-Themen 0
S Ist Java intrinsisch 'sicherer' als zum Beispiel C/C++ ? Allgemeine Java-Themen 2
D API - Beispiel + static member in inner (non static) class Allgemeine Java-Themen 2
Hotkey Beispiel für grosse Java Projekte Allgemeine Java-Themen 9
hdi Beispiel für EDT Violations gesucht Allgemeine Java-Themen 4
hdi Probleme mit Deadlock-Beispiel Allgemeine Java-Themen 11
W Frage zu Vererbung / konkretes Beispiel Allgemeine Java-Themen 4
M Frage zu Interfaces (Beispiel: Comparable) Allgemeine Java-Themen 13
E Exmatrikulations-Beispiel Allgemeine Java-Themen 8
G multithreading, concurrency conveyor belt beispiel Allgemeine Java-Themen 2
T Prototyp Beispiel Allgemeine Java-Themen 12
J Threads, Doppelpufferung --> Beispiel gefunden, geht net Allgemeine Java-Themen 16
F Installer für Windows schreiben! Hat jemand ein Beispiel? Allgemeine Java-Themen 8
K Brauche euren Lösungsweg zu einem File/IO-Beispiel Allgemeine Java-Themen 23
E Servlet-Beispiel gesucht Allgemeine Java-Themen 3

Ähnliche Java Themen

Neue Themen


Oben