GUI - DATA HANDLING
hi there, we are working on quite a big application and the implementation of the gui becomes a bit of a spaghetti and we decided to look at the patterns . Not so familiar with it and don't find anything good for design patterns in swing when using J2EE technology. So here is the situation for the moment :
I receive a DTO from the server with needed info for the app, sometimes its the baseDTO, othertimes an extended DTO with much more details (depends what is needed for the view) , this is normal i assume.
that DTO is put in a model, together with extra info retrieved from the server (other dto's), also each view has it own model, derived from this base model.
now the gui that needs to be aware of data changes registers themselves to a kind of controller, which then updates all listeners that new data is availabel. And here is where there's a problem, in each listener we have to check for in which view we are for what to do.Also each container in gui has references to the models it uses. like model.getInstance()
this becomes a bit of spaghetti
so looked at design patterns and found something at jgoodies and a certain guy named fowler, but don't understand it wel. It's about the presentation and the model seperate and with a presenter and seperate view.
So here is the situation we changed. Now we have a viewcontroller, which holds in which view we are and will also handle if there's new data to set and data to retrieve. It will automatically call the correct gui components and set and get the data. This is done because we now have a class VIEW, in that class we hold a ref to the JFrame, the main window (as a singleton) and the subclasses are the different views. Now together with that each view has a datamodel (the dto's from above). We also use helpers for the containers in the gui, these will be called from the view to set and get the data.Of course we have also different models for components in the gui (like tables, list, cb's)
AND NOW THE QUESTION :
1. Are these good solutions, or do we miss something, if 1. yes which is the best
2. If you go for the second solution. Where should i put the models for the tables and so on :
* directly in the component (in a JTable)
* hold in the HelperView
* hold in the dataModel for a view
thx
[2369 byte] By [
soulgoda] at [2007-10-3 8:18:51]
> I receive a DTO from the server with needed info for
> the app, sometimes its the baseDTO, othertimes an
> extended DTO with much more details (depends what is
> needed for the view) ,
what is your reason for using DTOs? OO programming allows you use private data for your operations which has huge advantages than structural programming. using DTOs clearly indicates you are going back to the stone age. extening DTOs clearly indicates you are crazy!
> this is normal i assume.
it is normal only among old timers or valoo chickens or hardware testers struggling with OO programming.
> that DTO is put in a model, together with extra info
> retrieved from the server (other dto's), also each
> view has it own model, derived from this base model.
> now the gui that needs to be aware of data changes
> registers themselves to a kind of controller, which
> then updates all listeners that new data is
> availabel.
if the the server is developed to spit out data in DTOs, you would not have a choice but make do with it, meaning you have to srite code, such as DAOs, to convert the DTOS to modols for the views.
> And here is where there's a problem, in
> each listener we have to check for in which view we
> are for what to do.Also each container in gui has
> references to the models it uses. like
> model.getInstance()
> this becomes a bit of spaghetti
>
the models goes with the views: when the views, jframes, get created and displayed, the models, enclosed as compositions, will get to created, and when the views go out of scode, so do the models.
you seem to be doing the other way around, and thusly feeling the pain in the s.
> so looked at design patterns and found something at
> jgoodies and a certain guy named fowler, but don't
> understand it wel. It's about the presentation and
> the model seperate and with a presenter and seperate
> view.
>
those patterns are mostly for stateless operations such as web applications, although they are originated from things like swing or other desktop applications.
> So here is the situation we changed. Now we have a
> viewcontroller, which holds in which view we are and
> will also handle if there's new data to set and data
> to retrieve. It will automatically call the correct
> gui components and set and get the data. This is done
> because we now have a class VIEW, in that class we
> hold a ref to the JFrame, the main window (as a
> singleton) and the subclasses are the different
> views. Now together with that each view has a
> datamodel (the dto's from above). We also use helpers
> for the containers in the gui, these will be called
> from the view to set and get the data.Of course we
> have also different models for components in the gui
> (like tables, list, cb's)
>
the swing components as a framework already implemented in this pattern, you dont have to or rathen should go the other way around as they are for web applications.
> AND NOW THE QUESTION :
> 1. Are these good solutions, or do we miss something,
> if 1. yes which is the best
>
> 2. If you go for the second solution. Where should i
> put the models for the tables and so on :
> * directly in the component
> (in a JTable)
>* hold in the HelperView
> * hold in the dataModel for a view
>
> thx
they are the same pattern.
thx for the answers, i think that's my fault that i wanted to have a web design pattern on swing.
> > I receive a DTO from the server with needed info
> for
> > the app, sometimes its the baseDTO, othertimes an
> > extended DTO with much more details (depends what
> is
> > needed for the view) ,
>
> what is your reason for using DTOs? OO programming
> allows you use private data for your operations which
> has huge advantages than structural programming.
> using DTOs clearly indicates you are going back to
> the stone age. extening DTOs clearly indicates you
> are crazy!
>
> > this is normal i assume.
>
> it is normal only among old timers or valoo chickens
> or hardware testers struggling with OO programming.
>
But i don't understand your remarks on the dto's (data transfer objects). This is not OO ? The dtoj ust has the data from the server which the app need to display to the user. If that's not OO i don't know what OO is, This are things they said to use this as much as possible (on a course of design patterns, giving by java certified guys) One base class that extends another and that can be used client side as server side.... Give me an example to replace the dto's with... we don't want the adf solution or so, typing data, automatically changing on server
> > that DTO is put in a model, together with extra
> info
> > retrieved from the server (other dto's), also each
> > view has it own model, derived from this base
> model.
> > now the gui that needs to be aware of data changes
> > registers themselves to a kind of controller,
> which
> > then updates all listeners that new data is
> > availabel.
>
> if the the server is developed to spit out data in
> DTOs, you would not have a choice but make do with
> it, meaning you have to srite code, such as DAOs, to
> convert the DTOS to modols for the views.
>
> > And here is where there's a problem, in
> > each listener we have to check for in which view
> we
> > are for what to do.Also each container in gui has
> > references to the models it uses. like
> > model.getInstance()
> > this becomes a bit of spaghetti
> >
> the models goes with the views: when the views,
> jframes, get created and displayed, the models,
> enclosed as compositions, will get to created, and
> when the views go out of scode, so do the models.
>
> you seem to be doing the other way around, and thusly
> feeling the pain in the s.
ok, that i understand, but how does your ui knows when your data is updated. We don't like the propertychangelisteners, especially that you always have to set a String for each property.... hard to maintain we feel.
We don't want to change the data directly in the model when the user type in something, he has to explicitly save the data (by a savebutton)
>
> so looked at design patterns and found something at
> jgoodies and a certain guy named fowler, but don't
> understand it wel. It's about the presentation and
> the model seperate and with a presenter and
> seperate
> view.
>
> those patterns are mostly for stateless operations
> such as web applications, although they are
> originated from things like swing or other desktop
> applications.
And just for web.. read the jgoodies swing data binding http://www.jgoodies.com/articles/patterns-and-binding.pdf i think this is for swing or not...
>
> So here is the situation we changed. Now we have a
> viewcontroller, which holds in which view we are
> and
> will also handle if there's new data to set and
> data
> to retrieve. It will automatically call the correct
> gui components and set and get the data. This is
> done
> because we now have a class VIEW, in that class we
> hold a ref to the JFrame, the main window (as a
> singleton) and the subclasses are the different
> views. Now together with that each view has a
> datamodel (the dto's from above). We also use
> helpers
> for the containers in the gui, these will be called
> from the view to set and get the data.Of course we
> have also different models for components in the
> gui
> (like tables, list, cb's)
>
> the swing components as a framework already
> implemented in this pattern, you dont have to or
> rathen should go the other way around as they are for
> web applications.
>
> AND NOW THE QUESTION :
> 1. Are these good solutions, or do we miss
> something,
> if 1. yes which is the best
>
> 2. If you go for the second solution. Where should
> i
> put the models for the tables and so on :
> * directly in the component
> (in a JTable)
>* hold in the HelperView
> or a view
> >
> > thx
>
> they are the same pattern.
soulgod, FYI, you can safely ignore anything daFei says. He's just a troll who likes to play pretend.
daf, you're taking this joke too far. It's all good and well in threads where everyone is aware what's going on, but pulling your silly pranks on unsuspecting members looking for a sincere answer is crossing the line. Please stay within the confines of threads that are already a joke anyway.
Lokoa at 2007-7-15 3:24:17 >
> thx for the answers, i think that's my fault that i
> wanted to have a web design pattern on swing.
>
i dont think the pattern is different, it is still MVC. when MVC is used in a web application, changes in M do not get reflected in V by itself because of the stateless characristics of the web. so be aware of this.
> But i don't understand your remarks on the dto's
> (data transfer objects). This is not OO ?
OO typically means operations on private data. DTOs do not have operations, they are merely a data structure, exactly the same like that in c. it is a convienet means of passing mutiple values at one time. only people who have been procedural coders for too long would apprecialte sturcutres but a full object is usually too much for them to comprehend.
the DAO pattern with DTOs is a pattern used like crazy among hardware testers only. DATOs are not objects, they are not OO programming, only structural programming.
if you want to take full advantages of OO programming, use full objects.
> The dtoj
> ust has the data from the server which the app need
> to display to the user. If that's not OO i don't know
> what OO is, This are things they said to use this as
> much as possible (on a course of design patterns,
> giving by java certified guys)
yest, given by java certifies guys, but given to morans because morans can not comprehend OOs, morans would not pay for what they can not comprehend, and would not do what they can not comprehend. it is a baad thing in the field.
> One base class that
> extends another and that can be used client side as
> server side.... Give me an example to replace the
> dto's with... we don't want the adf solution or so,
> typing data, automatically changing on server
>
if you can not comprehend the concet of OO, and have to use half objects like DTOs, then dont complicate it by extending them. inheritance is another fine OO concept that should not be abused, because if you, you screw yourself.
> ok, that i understand, but how does your ui knows
> when your data is updated.
in swing application, the view by default knows the cahnges in its model. in a web application, the view does not by default. and this is the difference.
basically, in MVC, the V displays the M, changes in M should be reflected in V, sometimes you need to write code to make this happen if it does not happen by default. the C controls the M, the changes in M, that is.
Lokoa at 2007-7-15 3:24:17 >
DTOs are for birds that dont no.
Lokoa at 2007-7-15 3:24:17 >
> hi there, we are working on quite a big application
> and the implementation of the gui becomes a bit of a
> spaghetti and we decided to look at the patterns .
> Not so familiar with it and don't find anything good
> for design patterns in swing when using J2EE
> technology. So here is the situation for the moment :
>
>
> I receive a DTO from the server with needed info for
> the app, sometimes its the baseDTO, othertimes an
> extended DTO with much more details (depends what is
> needed for the view) , this is normal i assume.
I have found that it general that is a bad idea.
The basis for inheritence is behavior. A DTO is not a real object (any behavior that it has is trivial.) Because of the inheritance with DTOs is always a convenience. That means it often isn't thought out in conceptual terms but solely it attribute terms. And that leads to required refactoring when something changes.
> that DTO is put in a model, together with extra info
> retrieved from the server (other dto's), also each
> view has it own model, derived from this base model.
> now the gui that needs to be aware of data changes
And why do you feel that they need to be automatically updated?
>
> AND NOW THE QUESTION :
> 1. Are these good solutions, or do we miss something,
> if 1. yes which is the best
>
The patterns are good. Whether they apply to your situation requires much more information than you provided.
> 2. If you go for the second solution. Where should i
> put the models for the tables and so on :
> * directly in the component
> (in a JTable)
>* hold in the HelperView
> * hold in the dataModel for a view
Model? You mean the DTOs? DTOs are disparate objects. The only time one refers to another is via an association. And it would be very unlikely that such an association would be more than one level deep (for example a customer dto might have a collection of telephone dtos.)
> > that DTO is put in a model, together with extra info
> > retrieved from the server (other dto's), also each
> > view has it own model, derived from this base model.
> > now the gui that needs to be aware of data
> changes
>
> And why do you feel that they need to be
> automatically updated?
>
i got an impression that op really wanted to know how to get the views updated once new data is available.
the DTOs you receive from the the server. if the sever is an EJB server with JMS, you can write some code to listen for new data. if the server is just a web server, you are out of luck, you must query it to see if there is new data.
now with your swing application, if you want multiple views to be updated at certain order, you can use wait, notify or implement the observer. in swing, the common practice is use threads, not DTOs. kick out that sun certified DTO moran.
> > > that DTO is put in a model, together with extra info
> > > retrieved from the server (other dto's), also each
> > > view has it own model, derived from this base model.
> > > now the gui that needs to be aware of data
> > changes
> >
> > And why do you feel that they need to be
> > automatically updated?
> >
>
> i got an impression that op really wanted to know how
> to get the views updated once new data is available.
I understood what the OP was asking.
What I asked was why the OP thinks that is needed.
> > > > that DTO is put in a model, together with extra info
> > > > retrieved from the server (other dto's), also each
> > > > view has it own model, derived from this base model.
> > > > now the gui that needs to be aware of data changes
> > >
> > > And why do you feel that they need to be
> > > automatically updated?
> > >
> >
> > i got an impression that op really wanted to know how
> > to get the views updated once new data is available.
>
> I understood what the OP was asking.
>
> What I asked was why the OP thinks that is needed.
i guess op wanted to display the new data.
> > > > I understood what the OP was asking.> > > > What I asked was why the OP thinks that is needed.> > i guess op wanted to display the new data.And again that has nothing to do with what I asked.
> > > I understood what the OP was asking.
> > >
> > > What I asked was why the OP thinks that is needed.
> >
> > i guess op wanted to display the new data.
>
> And again that has nothing to do with what I asked.
i do hope this is the case; otherwise one would be shocked that one would raise such a funny question.
> >
> > And again that has nothing to do with what I
> asked.
>
> i do hope this is the case; otherwise one would be
> shocked that one would raise such a funny question.
There is no one on this site that cares about your technical opinions and your emotional state on any subject is certainly inconsequential.
> > >
> > > And again that has nothing to do with what I
> > asked.
> >
> > i do hope this is the case; otherwise one would be
> > shocked that one would raise such a funny question.
>
> There is no one on this site that cares about your
> technical opinions and your emotional state on any
> subject is certainly inconsequential.
if i dont have a choice, i would prefer being in the state as you described, rather than passing bits by value like an expert.
hey, been on holiday, so i couldn't answer for a couple of days. I just wanted to know if there's a good way to handle data that comes from the server and to put in the fields for the user , like using a design pattern. I was just looking for a certain solutions and to try them . We are aware of the standard java things like listeners and so on, but wanted to see if there are better solutions....
and for the discussions on the dto's , we call them data transfer objects, but as it is, it are transfer objects, and that's a J2EE design pattern, those are just normal pojo's or javabeans, with no functions in it. As far as i can remember inheritance is mostly used for the fields and not to inherit functionality. (with javabeans, not components or so)If you have critics on why we use transfer objects then give me a fully example how you would send and retrieve data to/from a server without writing to much listeners and other stuff in your ui classes. How would you do it when the user wants to save the data from a screen and send it to server, call for each field the server, i don't think so . We need a transfer object for that, with just fields, so a pojo, we don't have to have functionaly in that, the server has not to know what the client have to do and vice versa, why send an object with functionality in it over the network (if you have a lot of users it will also cost performance), the client does what it does with the data and the server does it and they don't have to know of eachother what they do with it, but it has the same structure, so yess it 's a kind of structural data programming, but is just a way to keep our data organized and what we need and as i said, it are just pojo's or javabeans...
> > hi there, we are working on quite a big
> application
> > and the implementation of the gui becomes a bit of
> a
> > spaghetti and we decided to look at the patterns .
> > Not so familiar with it and don't find anything
> good
> > for design patterns in swing when using J2EE
> > technology. So here is the situation for the moment
> :
> >
> >
> > I receive a DTO from the server with needed info
> for
> > the app, sometimes its the baseDTO, othertimes an
> > extended DTO with much more details (depends
> what is
> > needed for the view) , this is normal i assume.
>
> I have found that it general that is a bad idea.
>
> The basis for inheritence is behavior. A DTO is not
> a real object (any behavior that it has is trivial.)
> Because of the inheritance with DTOs is always a
> convenience. That means it often isn't thought out
> in conceptual terms but solely it attribute terms.
> And that leads to required refactoring when
> something changes.
>
>
> > that DTO is put in a model, together with extra
> info
> > retrieved from the server (other dto's), also each
> > view has it own model, derived from this base
> model.
> > now the gui that needs to be aware of data
> changes
>
> And why do you feel that they need to be
> automatically updated?
i meant not automatically updated, but just that the user pressed save, data goes to server, client recieves the saved data again, just find a good way to do it without having to call to much listeners and so
>
> >
> > AND NOW THE QUESTION :
> > 1. Are these good solutions, or do we miss
> something,
> > if 1. yes which is the best
> >
>
> The patterns are good. Whether they apply to your
> situation requires much more information than you
> provided.
>
> 2. If you go for the second solution. Where should
> i
> put the models for the tables and so on :
> * directly in the component
> (in a JTable)
>* hold in the HelperView
> or a view
>
> Model? You mean the DTOs? DTOs are disparate
> objects. The only time one refers to another is via
> an association. And it would be very unlikely that
> such an association would be more than one level deep
> (for example a customer dto might have a collection
> of telephone dtos.)
i mean with model : for each screen we use (which has several components, as other panels, tables and so on) we have a model that will hold a couple of dto's in it (nothing more than 2 or so), the data which is needed for the screen.It's rather difficult to explain how the app works and what is has to do, it's rather complex. this model has also some other models like the tablemodels we need for that view, so, when the server sends some data , this model will set it to the different models it has. I'm just thinking, maybe we 'll have to change the name, isn't it more like a dao that we are using here.
It's just what i wanted is the following : you have a JFrame, that frame has a model (call it DataModel) that holds the data needed for the frame. We have an ActionManager(which contains the different actions for the app, in fact just a hashmap with integers and the according action to it), a ViewManager (which will update the topcontainer when there's a new view available). Each container used in a screen (panels and so) has to implement a Listener(for saving , cancelling and so on)
SO here is a liitle flow of how it happens now
User does some changes in the frame -> user presses save -> ActionManager retrieves the action save from the savebutton --> ActionManager will tell ViewManager to save the currentview--> ViewManager tells the currentview to save it's data --> currentView calls all his components to save their data to their model(here the model of the screen) --> ActionManager will send the data to server (via action) --> Action retrieves updated data from server --> call viewmanager to update the data --> ViewManager will set the data to the correct model and will call the gui that the model has been updated.
Now what i want to get rid of it, is these listeners (save, cancel ...) in my gui components. In fact get the logic out of the gui. And as i read you can do it with viewhelpers. so the flow would be
User does some changes in the frame -> user presses save -> ActionManager retrieves the action save from the savebutton --> ActionManager will tell ViewManager to save the currentview--> ViewManager tells the currentviewhelper to save it's data --> currentView calls all his components to save their data to their model(here the model of the screen) --> ActionManager will send the data to server (via action) --> Action retrieves updated data from server --> call viewmanager to update the data --> ViewManager will set the data to the correct model and will call the helpers that the model has been updated.
not much a change as you can see, but the code for my gui would be much more cleaner and i just have to do it in my helpers to handle the data, while as for now , if i use a component in different views, i still have to check for some functions in which view i am, while with the second solution th
helpers does it and that's it. But the main question is, my helpers has to know all the components of the screen, so is it ok to use Screen.getInstance() in my ScreenHelper to access the components
Best I can get from the above is that this is entirely a gui question and really doesn't have anything to do with DTOs.
And the listeners that are being referred to exist solely in the GUI and are not relying on update notifications from the server.
Given that the question should be rephrased without mentioning DTOs.
