InputOutputStream
Esa Tanskanen
I finally got the time to make the InputOutputStream system I was planning.
Here's a quick introduction:
A traditional method would be to implement two methods for every object -
fromXML and toXML. That was even originally suggested. However, the downside
of this way is that there would be two similiar methods which need to be
kept synchronized with each other. If we change one of those methods, we'll
need to change the other one accordingly. That's very prone to bugs and is
also a lot of extra work.
My approach was to create a common interface for both input and output,
namely InputOutputStream, which has the methods called process and
processChildren. Process-method processes one variable and returns the new
value for that variable. Input streams obviously don't care about the
existing value, they just return a new one. Output streams save the passed
value and return it unmodified.
Then, the objects which can be saved or loaded using the InputOutputStream
must implement the IOStreamSaveable interface. The interface has only one
method, process, which takes an InputOutputStream as an argument. Then, it
should call the InputOutputStream's methods for each stored variable and
child object.
The objects also must have a constructor, which takes an InputOnlyStream
(subclass of InputOutputStream) and just calls: process(stream). Why?
Because when a new object is constructed by an input stream, we can't use
the usual constructor for that class. However, having a default constructor
isn't a good idea, because it'll usually leave the object in an
uninitialized state. And the definition of constructor says that the
constructor must initialize the object so that it can be used after the
initialization. A such constructor would easily leave undesired bugs in the
library users' code, just because they would believe that calling the
parameterless constructors would be perfectly safe.
There's now two ways to store data, either in XML or binary format. So that
means we have 4 classes: XMLInputStream, XMLOutputStream, BinaryInputStream
and BinaryOutputStream. All those streams take a conventional InputStream or
OutputStream as an argument (and possibly other arguments, for example the
XML streams take the name of the root element).
_________________________________________________________________
Nyt löydät etsimäsi tiedot nopeasti niin koneeltasi kuin netistä.
http://toolbar.msn.fi
Esa Tanskanen
XML processing. However, I wanted to make it simple to switch to an another
XML library if that one is not suitable. In other words, the rest of FengGUI
doesn't have to know anything about what XML library is being used, so no
library specific parameters or exceptions are permitted.
The XML routines are still being tested, so don't use them yet. The code is
committed so that people can see the class structure.
/Esa
_________________________________________________________________
Uutisista turhaan tietoon. Mitä ikinä etsitkin, MSN Search löytää hakemasi.
http://search.msn.fi
Esa Tanskanen
still add a few overloaded methods (for saving floats, for example).
Johannes Schaback
Thanks a lot for your great contribution!
I read your mail twice and find your concept very cool. I also like
the idea of having two kinds of streams (binary and XML).
Maybe you could provide a little example how to use your io package?
Maybe with some pseudo-code? :)
We are currently moving FengGUI to SourceForge. The most current
sources are in the SVN on SF already. Please commit your code there
again (I am going to freeze fenggui.java.net soon)
Is there a way to load themes with your framework as well? The reason
why I am asking is because themes and layouts are quite similar up to
a certain point and it makes sense to have all the XML handling in one
place. However, themes define only the default appearance while
layouts can define the appearance AND where widgets are located, which
children they got and so on. That means that the XML schema for
layouts extends the schema of themes bascially.
Johannes
Esa Tanskanen
>Maybe with some pseudo-code? :)
OK, I've attached the sources I've tested it with.
>We are currently moving FengGUI to SourceForge. The most current
>sources are in the SVN on SF already. Please commit your code there
>again (I am going to freeze fenggui.java.net soon)
Yeah, my username is eptanska, I think it'll need to be added to the
project.
>Is there a way to load themes with your framework as well? The reason
>why I am asking is because themes and layouts are quite similar up to
>a certain point and it makes sense to have all the XML handling in one
>place. However, themes define only the default appearance while
>layouts can define the appearance AND where widgets are located, which
>children they got and so on. That means that the XML schema for
>layouts extends the schema of themes bascially.
Why not, it's not only for any specific purpose. However, one thing I'll
need to implement is a way for the elements to refer to each other, but I
haven't thought of that system throughoutly yet.
Johannes Schaback
> OK, I've attached the sources I've tested it with.
Awesome. I will check it in a second.
> >Is there a way to load themes with your framework as well? The reason
> >why I am asking is because themes and layouts are quite similar up to
> >a certain point and it makes sense to have all the XML handling in one
> >place. However, themes define only the default appearance while
> >layouts can define the appearance AND where widgets are located, which
> >children they got and so on. That means that the XML schema for
> >layouts extends the schema of themes bascially.
>
>
> Why not, it's not only for any specific purpose. However, one thing I'll
> need to implement is a way for the elements to refer to each other, but I
> haven't thought of that system throughoutly yet.
yeah, imagine you want to create a custom font and you want to refer
to it somewhere. E.g. in Label and Button or so... It were not for the
references your concept could be easily adapted for the themes.
Maybe you could introduce a whiteboard where things can be stored and
accessed publicly (similar to the current theme mechanism). just a
random thought...
Johannes
Esa Tanskanen
what I end up with.
_________________________________________________________________