How to test changed text in a JTextField?

[Dwalin_DE]

I have another question now:

I am using Netbeans with a Java Desktop Application. I want to perform an action after a JTextField component's text has been edited, i.e. whether the user pressed the enter key or if the focus has gone.
Unfortunately the focus will not change after enter key is pressed (can this be set?). So I think I am forced to add the action listener as well as the focuslost listener?
I also tried the JFormattedTextField since I read, that unlike the JTextField that one fires action on both, enter key AND focus change, however that info seems not to be right.

So what is the right way in a JDesktop app to check, if an edit of an textfield is finished and further work with that input can be done, in ONE place/event/listener?

[Dwalin_DE]

The enter key is firing the actionPerformed event, but does not do anything else. It is merely used as a confirmation to the input. The enter key is the action event of JTextField and other text fields, maybe except the multiline variants.

[efred]

private void jTextField1KeyPressed(java.awt.event.KeyEvent evt) {
int knum;
knum = 10;
int tp;
tp = evt.getKeyChar(); //catches the enter key value of 10
if (knum == tp) {
System.out.println("do validation");
jTextField2.requestFocus(); //moves to your next jTextField behaves like tab
}
}
I hope this is of some help, coded just to show meaning.
Fred

[Dwalin_DE]

My problem is not, that I do not know how to catch the enter key. I know how to do that.
My problem is, that I do not want to do that, but instead want a reliable way to know, when a text edit is finished. Even if the user clicks directly the window close button in the window frame. Even if the user switches components. Even if the user presses enter, because that is a default behaviour of JTextEdit component to fire the action event upon it. But in Java there seems not to exist ONE reliable method to do that. The closest is the document changed event, however that ain't the right one, because that also fires, if the content is changed by code, e.g. upon initializing the control, and also on every change, so that a validation might not be desired, while the user has not finished his edit, but the change fires anyway.
This is most uncomfortable in Java and apart from any "standards" GUIs of operating system "define".

[efred]

"because that is a default behaviour of JTextEdit component to fire the action event upon it."

Could you be more specific on the jTextEdit component.
As I cant find one. I googled and got this conversation.

Thank you in advance.
Fred

[Dwalin_DE]

Of course that was a typo. This whole topic refers to "JTextField".
How the text field consumes VK_ENTER events depends on whether the text field has any action listeners. If so, then VK_ENTER results in the listeners getting an ActionEvent, and the VK_ENTER event is consumed. This is compatible with how AWT text fields handle VK_ENTER events. If the text field has no action listeners, then as of v 1.3 the VK_ENTER event is not consumed. Instead, the bindings of ancestor components are processed, which enables the default button feature of JFC/Swing to work.

[Dwalin_DE]

Hi once more all,

since my question seemed to be too trivial that anyone would answer me, I did myself a bit more research and came to this conclusion:

in my other thread I already gave my oppinion about the most buggy NetBeans GUI builder and suggested workarounds. Now, for this "little" problem I asked here I did research on the Java GUI capabilities and I must say, that the Java GUI is confusing, malformed and incompatible to any other GUIs I ever saw on KDE, Macintosh OS and Windows platforms.
Why?
1. if a GUI offers the enter/return key to validate textfield input, it then also should move the focus to the next focussable component. Java doesn't.
2. if a GUI offers an event for "LostFocus" to validate textfield input, it should also be fired when window frame components are clicked (window close button, window menu etc.). Java doesn't.
3. To be positively and safely triggered on textfield changes, the Java textfield component offers the DocumentChange event, that I successfully implanted into the "after generation" code of the NetBeans GUI builder. However, in most cases noone wants to do action upon every char change in the textfield. So this is not an alternative.
4. I know, that I COULD make my own GUI system in Java, however this is not a solution to be seriously discussed in the year 2009.

Conclusion: it is with the standard GUI classes of Java impossible to create a desktop application that behaves as expected by KDE, Macintosh or windows users, or, if you get close to that, your code does more than it needed (validation on EVERY change of text).

Solution: back to the stone age... make textfields ineditable and only allow changes via a button. That way you only get triggered once after the value has been changed, and you get triggered reliably.

If Java hadn't the big advantage of being platform independant, latest now I would have quit studying and trying it, at least for desktop applications.

Just my two pence, greetings, Dwalin

[efred]

Please excuse if am off target.
I very new to java and netbeans.
tab moves from jTextField to the next ordered jTextField which then has focus.
jTextField for reasons I dont know doesnt seem to use enter.
jTextField for reasons I dont know doesnt seem to use tab, just moves to the next ordered jTextField.
jTextArea uses tab to tab in the text area and uses enter to add another line in the jTextArea.

I guess you are using enter to do tab or want to use jTextArea.

code:

private void jTextField1KeyPressed(java.awt.event.KeyEvent evt) {
// TODO add your handling code here:
System.out.println("key pressed \n" + evt.toString());
}

Maybe you can use lost focus to run the above suggested button.
I sure there is a better way.
Good luck
Fred

[Dwalin_DE]

Hi Fred, and ty for your reply.

I have no problem to install any listeners, action, lostfocus, documentchanged, keyboard or anything.

My topic here has completely different background: I am looking for a reliable way in Java to always know, when a textfield's content has changed, but not on every keystroke/char change.

In all OS guis that I know, that is KDE in Linux, Macintosh and all windows OS, the lostfocus event is the only place you need to check. It there is fired no matter if you tab away the focus, click on system components or close the window with a key combo. This is not the case with Java.

To do this in Java you can (afaik) only workaround this... one way is a document changed listener, but that is fired upon any change, so not really what I need. You can install an action listener for the enter key PLUS a lost focus listener for the focus change, BUT... then you still will get no event when you click a system component to close the window. Besides you gotta install several listeners for one component, which is just stupid.

So my q was, if there is a way in Java too, like in operating systems, to be triggered whenever the focus of a component is going away, which it in Java does not, when you close the window. And of course, on a GUI with dozens of components I do not want to check myself all component's content, when the user closes the app.

Thats why I think, that Java is the crappiest way to create a GUI app, except for it's platform independancy.

[efred]

jTextField and jTextFieldFormat seem to have the same preconditions in this case.

Ref: first message, the enter key.

Maybe its a message-driven architecture receiving the enter char key 10 as compared to char 65 key(a) which it has a function and knows what to do with it.
And char key 10 which it sent to the byte bucket so to speak (ha), not having function.

I have no idea of how many jTextFields you need thus have trouble relating to your issues.
If somebody types into or tabs to the jField it gains focus, and tabs out looses focus or clicks someplace
else it looses focus. (note: enter does nothing) Unless Im not seeing something else
events could be confined to the jTextField at hand.
Thus each jTextField would be responsible for its own validity on focus exit in this case.

Thanks for your patience with me.
Please excuse if Im seeing this wrongly.
Fred

[Gregg Wonderly]

Only when a dialog is closed do I ever check the contents of components that
represent a "form" type of data input. The WindowListener.windowClosing()
method, ActionListener.actionPerformed() on buttons and the return code from
JOptionPane.showInputDialog() are all the places that I do this. I just write
the method once that collects and commits the input to "wherever". I then call
it at one of these spots when the event I receive is appropriate for saving the
content.

Never, ever do I consider it a good idea to "commit" data on tab between fields
or hitting enter on a multi fielded form.

Focus lost seems like a bad thing for doing anything but "filtering" of input to
indicate what is acceptable in a field.

Can you provide a more concrete example of the issue?

Gregg Wonderly

Post by Dwalin_DE
Hi Fred, and ty for your reply.
I have no problem to install any listeners, action, lostfocus, documentchanged, keyboard or anything.
My topic here has completely different background: I am looking for a reliable way in Java to always know, when a textfield's content has changed, but not on every keystroke/char change.
In all OS guis that I know, that is KDE in Linux, Macintosh and all windows OS, the lostfocus event is the only place you need to check. It there is fired no matter if you tab away the focus, click on system components or close the window with a key combo. This is not the case with Java.
To do this in Java you can (afaik) only workaround this... one way is a document changed listener, but that is fired upon any change, so not really what I need. You can install an action listener for the enter key PLUS a lost focus listener for the focus change, BUT... then you still will get no event when you click a system component to close the window. Besides you gotta install several listeners for one component, which is just stupid.
So my q was, if there is a way in Java too, like in operating systems, to be triggered whenever the focus of a component is going away, which it in Java does not, when you close the window. And of course, on a GUI with dozens of components I do not want to check myself all component's content, when the user closes the app.
Thats why I think, that Java is the crappiest way to create a GUI app, except for it's platform independancy.

[Thomas Wolf]

Hi Dwalin,

Post by Dwalin_DE
Hi once more all,

I don't have your original posting handy (most of us read this mailing
list via an e-mail client, not via the web forum), so I can't answer for
certain, but it seems from this posting that you're asking Java/Swing
questions - and this is a Netbeans user mailing list, so perhaps that is
why you didn't get any response.

Post by Dwalin_DE
in my other thread I already gave my oppinion about the most buggy NetBeans GUI builder and suggested workarounds. Now, for this "little" problem I asked here I did research on the Java GUI capabilities and I must say, that the Java GUI is confusing, malformed and incompatible to any other GUIs I ever saw on KDE, Macintosh OS and Windows platforms.
Why?

Because the other GUIs you have come across can cater to the
idiosyncrasies of their particular system. Java tries to logically
mask the differences between the different OSs - sometimes,
unfortunately, by providing a "lowest-common-denominator" level API.

Post by Dwalin_DE
1. if a GUI offers the enter/return key to validate textfield input, it then also should move the focus to the next focussable component. Java doesn't.

There's a traversal mechanism that gives you pretty complete flexibility
on how you can move focus. Not sure what would need to be done to have
it do its thing on enter/return being pressed. The default traversal
mechanism uses the tab key.

Post by Dwalin_DE
2. if a GUI offers an event for "LostFocus" to validate textfield input, it should also be fired when window frame components are clicked (window close button, window menu etc.). Java doesn't.

You are assuming that "LostFocus" is provided to validate textfield
input. While that is certainly possible, I don't think it's the
prescribed way of doing validation checks. The better way is to
implement a DocumentListener.

Post by Dwalin_DE
3. To be positively and safely triggered on textfield changes, the Java textfield component offers the DocumentChange event, that I successfully implanted into the "after generation" code of the NetBeans GUI builder. However, in most cases noone wants to do action upon every char change in the textfield. So this is not an alternative.

I don't think you can make generalizations like "in most cases noone
wants to do action upon every char change..." Any GUI that
enables/disables buttons based on whether a given set of text fields has
changed would make use of this interface. Just because the API is too
fine-grained for *you* doesn't make it wrong.

Post by Dwalin_DE
4. I know, that I COULD make my own GUI system in Java, however this is not a solution to be seriously discussed in the year 2009.
Conclusion: it is with the standard GUI classes of Java impossible to create a desktop application that behaves as expected by KDE, Macintosh or windows users, or, if you get close to that, your code does more than it needed (validation on EVERY change of text).

You can do whatever much or little work you want in Java, depending on
your needs. I've used Java/Swing/AWT for 13+ years and I've had no
problem creating large-scale desktop, client/server, and applet-based
GUIs using it. It does take time to learn.

Post by Dwalin_DE
Solution: back to the stone age... make textfields ineditable and only allow changes via a button. That way you only get triggered once after the value has been changed, and you get triggered reliably.

My suggestion is, if you haven't already done so, to spend some time
really learning Java/Swing and the underlying philosophy before throwing
in the towel. It's definitely NOT a good idea to learn Java GUI
development by pointing and clicking your way through GUI panels via
Matisse and then looking at its source code to figure out how to get
around the GUI builder's limitations.

Post by Dwalin_DE
If Java hadn't the big advantage of being platform independant, latest now I would have quit studying and trying it, at least for desktop applications.
Just my two pence, greetings, Dwalin

The above is just my $.02. Best wishes,
Tom
**********************************************************************************************
IMPORTANT: The contents of this email and any attachments are confidential. They are intended for the
named recipient(s) only.
If you have received this email in error, please notify the system manager or the sender immediately and do
not disclose the contents to anyone or make copies thereof.
*** eSafe scanned this email for viruses, vandals, and malicious content. ***
**********************************************************************************************

[efred]

private void jTextField1KeyPressed(java.awt.event.KeyEvent evt) {
finddocument();

}

@Action
public void finddocument() {
Object gl = jTextField1.getDocument().getLength();
jTextField2.setText(gl.toString());

}

Thanks Dwalin
Fred

[Dwalin_DE]

Hi Thomas,

I am a professional software developer myself since the early eighties and have seen most evolutions in software developing environments. I also know, that the "lowest-common-denominator" between the different OSses GUIs is far beyond what the NetBeans GUI Builder, resp. the underlying classes offer. I have worked on some very large-scaled, multi-tier applications (of course in teams), do as well systems as applications development and database designing. As you might have seen, I have researched the different options of checking for the time to validate a textfields content, as I refer to the action events (enter key, can also be done by a keyboard event), lostfocus event, which normally is the time to forward an entered value to an underlying classes object, unless some binding can be do
ne that automizes the exchange between an object's property and the textfields text property and also handles a "data dirty" flag. The API looks not "fine-grained" to me, but overloaded, lea
ving out options that are standard for decades to users of many OSses, hopelessly redundant in many places, where loads of old libs/workspaces should become obsolete, but aren't to keep compatibility for some apps that have been written 10 years ago and a lot more to nag.
However, I also see some advantages for Java/NetBeans, just not for GUI development. Maybe Java offers solutions, maybe the NetBeans GUI builder supports it, but then I find most tutorials too incompletely to give the right idea. I should expect that I can bind visual component's properties to properties of my own classes, but can't find an tutorial to see how that is done, and how it is done with NetBeans GUI builder.

Hi Gregg,

sorry, but English ain't my native language, so here I tell again briefly, what I want to do:
I have build an own class hierarchy that holds a lot of different data, that together build a medium complex project container. The GUI offers on register tabs a lot of different editors for each data type. Each data object is of course represented by a classes instance of that data. Whenever a property is changed on the editors visual components, I want
a) reflect it into the data class instance
b) have the instance check, if the value changed and set a dirty flag

Of course I do not want:
a) check on every keypress, because that is too many unnecessary checks
b) use more then one event for one component
c) check ALL hundreds (thousands) of data at one time (e.g. closing the app)
d) check on every change (document listener), because then I had to track myself double changes, that go back to the original result and do not require a save of the project

Usually this is done, when a component loses its focus, because that indicates that the user is done editing that component. However, in the swing GUI only the components in the "client area", i.e. not the windows decoration components, seem to take away the focus from the former component. Closing the window does not fire a lostfocus for the last active component, so that the data is lost/unhandled. Maybe a solution could be, that in the ExitListener I only get and check the value of the component that presently holds the focusand do all others by lostfocus events?

@ all
maybe someone can suggest a good tutorial (and I mean far better than the "Insel" one and the "swing tutorial") for creating effectively GUIs using NetBeans with swing?

[efred]

Just a note:

When you type in characters abcdef, your getEndPostion is 6
Now do a [enter] your getEndPostition is 7
[backspace] your getEndPosition is still 7 characters are abcde

Fred

[Thomas Wolf]

Hi Dwalin,

...As you might have seen, I have researched the different options of checking for the time to validate a textfields content, as I refer to the action events (enter key, can also be done by a keyboard event), lostfocus event, which normally is the time to forward an entered value to an underlying classes object, unless some binding can be done that automizes the exchange between an object's property and the textfields text property and also handles a "data dirty" flag. The API looks not "fine-grained" to me, but overloaded, leaving out options that are standard for decades to users of many OSses, hopelessly redundant in many places, where loads of old libs/workspaces should become obsolete, but aren't to keep compatibility for some apps that have been written 10 yearas ago and a lot more

to nag.

However, I also see some advantages for Java/NetBeans, just not for GUI development. Maybe Java offers solutions, maybe the NetBeans GUI builder supports it, but then I find most tutorials too incompletely to give the right idea. I should expect that I can bind visual component's properties to properties of my own classes, but can't find an tutorial to see how that is done, and how it is done with NetBeans GUI builder.

I didn't mean to imply that you didn't know what you were doing. But as
with everything, there are many different ways to skin a cat. In the
Swing projects I've worked on, we've typically extended the standard
Swing components with more specialized ones and had those components
emit abstract events that "application-level" listeners would act on.
For instance, we would implement a ModifiableTextField component that
emits a "Modified" event whenever the inputted text changed from some
initial value. The listener might be a controller - e.g. the containing
panel - who then decides whether to update the corresponding data
object/model.

The specialized components deal with whatever low-level mechanism is
necessary to determine whether something's "changed". In the case of
the JTextField, I would use a DocumentChangeListener - because that
tells me 100% of the time when something's changed and lets me send the
"modified" event at the appropriate times. Similarly, in the case of
the various buttons, I'd internally use an ActionListener; in the case
of JComboBox, an ItemStateListener, etc.

The above methodology may not be optimal in term of the number of events
different components need to listen to internally, but at least external
to the components the events are at "just the right level". Another
benefit, although probably not that important, is that it insulates much
of the application from Swing-specifics. In the case of Java/Swing this
is not as important anymore, but back in the 80's I worked on a couple
of projects that used very sophisticated but proprietary APIs and when
the company went belly up (does anyone remember Visigenics' "Galaxy"
framework), all the code that was so tightly coupled to the proprietary
API had to be rewritten. That is a lesson I took from those days.

Well, enough said. Maybe in the end, I'm making much ado about nothing
- maybe I'm just defending Swing because I've been quite happy with it
for such a long time. Although I've never had the "pleasure" of
developing anything using Microsoft's toolkits, I have used quite a few
GUI toolkits: a bunch of C and C++ X11 toolkits (Athena, OpenLook, and
Motif), NeXTStep, cross-platform C++ GUIs (zApp, Galaxy, a couple other
proprietaray ones I can't remember), and I can honestly say that
Java/Swing has been the easiest to work with - for me.

Best wishes,
tom


**********************************************************************************************
IMPORTANT: The contents of this email and any attachments are confidential. They are intended for the
named recipient(s) only.
If you have received this email in error, please notify the system manager or the sender immediately and do
not disclose the contents to anyone or make copies thereof.
*** eSafe scanned this email for viruses, vandals, and malicious content. ***
**********************************************************************************************

[efred]

If DocumentListener looks right for you.
Example:
http://www.java2s.com/Tutorial/Java/0260__Swing-Event/DocumentListenerandDocumentEvent.htm

Thanks for sharing that with me.
Fred

[Dwalin_DE]

@ Thomas

Thank you, now that really is a valuable hint. In fact I yesterday tried to subclass a JTextField, but it nagged about missing definition of "serialVersionUID". I did find how it is declared and defined, however I didn't find a sample on how to set it properly and reliable, assuming (I didn't find yet an explanation for it) that it's purpose is to uniquly identify a component subclass, maybe like M$ GUID for old ActiveX. I also saw yesterday, that you can easily add subclassed components with the NetBeans GUI builder from the context menu "add from palette/beans/select bean" by stating the class name.
Do you have a suggestion for a tutorial, that shows how to subclass any JComponent (including those requiring a serialVersionUID), and how to avoid to mangle data with GUI by doing it wrong? I am missing a way to e.g. set a document to a JPanel as the data container, for that the GUI is only the view, and that synchronizes GUI and data. Would it be a good idea to define bigger beans, that contain several components that reflect one data classes properties?

@ Fred

Thank you for your assistance, Fred. I did already implement a document listener. However, that was so far not the right event for me. Maybe, in combination with Thomas remarks, it will become useful.

[bhobiger]

Post by Dwalin_DE
In fact I yesterday tried to subclass a JTextField, but it nagged about missing definition of "serialVersionUID". I did find how it is declared and defined, however I didn't find a sample on how to set it properly and reliable, assuming (I didn't find yet an explanation for it) that it's purpose is to uniquly identify a component subclass, maybe like M$ GUID for old ActiveX.

Look in the API docs for Interface Serializable.

[efred]

If DocumentListener looks right for you.
Example:
http://www.java2s.com/Tutorial/Java/0260__Swing-Event/DocumentListenerandDocumentEvent.htm

Thanks for sharing that with me.
Fred

[efred]

I looking for a windows api in java, would you please share that with me.
If I said that right.

Thanks in advance.
Fred

[efred]

Please bye the way.
A. Would you share with the group your Listener Class.
B. If somebody in the group has there own Listener Class, raw as it maybe I would like to see it. Even if it is not complete, but works fundamentally.

Thanks in advance.
Fred

[Thomas Wolf]

Dwalin,

Post by Dwalin_DE
@ Thomas
Thank you, now that really is a valuable hint. In fact I yesterday tried to subclass a JTextField, but it nagged about missing definition of "serialVersionUID". I did find how it is declared and defined, however I didn't find a sample on how to set it properly and reliable, assuming (I didn't find yet an explanation for it) that it's purpose is to uniquly identify a component subclass, maybe like M$ GUID for old ActiveX.

I'm not sure what trouble you're running into, but you don't need to
provide a serialVersionUID to a subclassed component. None of our
subclasses do so. The only time you need this id is when you actually
want to "serialize"/"deserialize" your Java instances - something that
is rarely necessary (I don't even think it's advisable) for GUI
components. The important thing, if you plan on including your extended
components in the Matisse Palette, is to make sure your components are
"beans" - i.e. they follow the Java bean pattern (have an empty
constructor and have getter/setter methods for all the properties your
subclass defines).

Post by Dwalin_DE
I also saw yesterday, that you can easily add subclassed components with the NetBeans GUI builder from the context menu "add from palette/beans/select bean" by stating the class name.

I just right-click on the java file in the navigator and select
Tools->Add to Palette.

Post by Dwalin_DE
Do you have a suggestion for a tutorial, that shows how to subclass any JComponent (including those requiring a serialVersionUID), and how to avoid to mangle data with GUI by doing it wrong? I am missing a way to e.g. set a document to a JPanel as the data container, for that the GUI is only the view, and that synchronizes GUI and data. Would it be a good idea to define bigger beans, that contain several components that reflect one data classes properties?

I don't know of any specific tutorials - because I haven't really needed
them in a long time. If you haven't tried it, I used to reference the
Java tutorial frequently - just do a google search - it's at the sun.com
site somewhere. This tutorial has a "Swing" trail that might be helpful
in illustrating all the major swing components and, more importantly,
concepts.

As far as building bigger beans out of smaller ones: yes, I do that a
lot - but only up to the "window" level. After that, there's really no
point as you don't need to lay out window objects. So, if you have a
window that needs to display an "Employee" JPanel, that panel might
consist of further logical "areas" - such as Address, PersonalInfo,
Employment History, etc. I would make those logical units JPanels
themselves. If my outside presentation needs to show all of these units
at the same time - i.e. they need to be laid out within the Employee
panel, I would go through the trouble of making these panels "beans" so
I can use Matisse to drag/drop them around. If the Employee panel
presents these units as tabs, then it might not be worth it to make
these panels beans, since you won't really have to lay them out.

Where, in the component hierarchy you map GUI components to data objects
kind of depends on what feels right (not a very scientific answer, I
know). And it kind of depends a little on how you're going to represent
the data on disk (DB tables, object database, whatever). Sorry for not
giving you a better explanation, but this is going more into OOD than I
feel I have the time for - gotta do some work or my employer might
wonder what I'm doing :-)

Best of luck,
tom


**********************************************************************************************
IMPORTANT: The contents of this email and any attachments are confidential. They are intended for the
named recipient(s) only.
If you have received this email in error, please notify the system manager or the sender immediately and do
not disclose the contents to anyone or make copies thereof.
*** eSafe scanned this email for viruses, vandals, and malicious content. ***
**********************************************************************************************

[Vladislav Kisliy]

Post by Thomas Wolf
I don't know of any specific tutorials - because I haven't really needed
them in a long time.  If you haven't tried it, I used to reference the Java
tutorial frequently - just do a google search - it's at the sun.com site
somewhere.  This tutorial has a "Swing" trail that might be helpful in
illustrating all the major swing components and, more importantly, concepts.

May be something like that
http://java.sun.com/docs/books/tutorial/uiswing/TOC.html ?

[Dwalin_DE]

Thanx a lot, Tom!

and , lol, I din't ask for OOP fundamentals, only if there is a Java way for document/view architecture for container components, so that data objects (and I do *not* mean database objects) can be bound to gui objects via document abstraction. If there is no ready made thing like that, my q is obsolete.

Nice hint to add the bean into the palette, saves a lot of typing. I hoped the NetBeans IDE had a function for that.

The swing tutorial is exactly the one I mentioned as being too poor to be helpful. It anyway is included into the donwloaded JAVA SDK docs. However, surfing this forum has a lot of excellent stuff. There are more sources of course, some days ago I found an excellent brief explanation on how to add an ExitListener to a frameview somewhere else. Worked instantly and gave me control on checking my dirty mark to save the project before closing.

From an OOP view it feels "natural" (and thus right) to have beans that work as views to data objects, i. e. I would create beans that can serve a data classes instance and only provide a view (an editor) to that "documents" content.

Thanks again for your enlighting answers, and ty BHOBIGER too, I now know that in most cases I can ignore the warning that I didn't implement serialVersionUID, unless I really want it. So I switched of that hint/warning, when I really needed serialisation, I should know what to do :)