• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

general GUI design question

 
Ranch Hand
Posts: 308
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
hi,

i think that is not a technical merely a general GUI design question, that's why i put this post into this forum.

i am working on a desktop application similar to an installation routine (with buttons back and next).

with these applications you usually collect properties the user enters.
in my case i just made a class Settings with static fields which represent the stuff the user entered. i did this because i got fed up to pass around a Settings object to respective classes.
in the application itself there is only one user per JVM, so there is no danger of conflicts with static vars.

what do you think, is that alright to represent properties and collect them with public static global variables which are inside my class Settings?
maybe a security issue if everybody can manipulate the Settings fields as he has the .jar with Settings class accessible?
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'd avoid the static variables & methods and make a "real" object instance.

How have you structured your view & model that makes it a problem to "pass around a Settings object"? Maybe that's the place to look.
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by manuel aldana:

i am working on a desktop application similar to an installation routine (with buttons back and next).



I guess you are talking about what we call a "wizard". We have lots of them in our application, some of them quite complex. We always hold all the settings in one or more regular objects, and don't find this to a problem.

So, like Stan, I'd like to know more about why that would trouble you...
 
Ranch Hand
Posts: 81
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It depends on your design. There is no general rule of thumb that applies to all designs.

Static methods and attributes are useful things for any kind of Object(s) (and its variables) that is/are required across the scope of the application. Certainly, having an "instance" class in such a case would be a foolish waste of system resources and require extra code.

If you are concerned about security, then write code in the class that represents the single instance to check for violations and prevent them. For example, if you class has static variable indicating the state of user authentication and the username/password for example in the client, then once initialized with a value, no changes I would think should ever be allowed...thus you could disallow it by throwing an exception when some rogue code tries to change it.
 
manuel aldana
Ranch Hand
Posts: 308
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
i chose to use a global static class to make adjust settings possible the easiest way.

my wizard is build up through the State pattern, where next backward buttons force a transition to a new state of my wizard. i chose the State pattern because it makes things easier to understand and states are better to configure as in one big GUI class.

maybe you are right to make a proper Settings object out of my static vars being accessible from everywhere. to me it seems better design, that one wizard flow has one Settings object it refers to.

in the first place i chose statics because i could not pull up a Settings instance to the State superclass because after every state transition i am creating a new State instance and therefore need to initialize a new Settings object.

i think i will create a new Settings object in my first wizard state and will pass it to the other states.

thanks for your thoughts.
 
You'll never get away with this you overconfident blob! The most you will ever get is this tiny ad:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic