Results 1 to 3 of 3

Thread: Help me explain why this should not be done

  1. #1

    Thread Starter
    New Member
    Join Date
    Jan 2018
    Posts
    1

    Help me explain why this should not be done

    Hi,

    I am not very good at explaining myself but usually no when something is wrong or does not make sense. I am having a hard time explaining to my colleagues why.

    We have our Main application that has it's own settings that belong to it. And a component that plugs in with it's own settings as well.

    The main application does it's thing and based on the output of the main application it sends data to another device.
    Now in the main application settings, there are options:

    Send Data if analysis = X? Yes/No
    Send Data if analysis = Y? Yes/No

    The business logic is in the main application as well as the settings. However, from a user stand point it would make sense for the settings to be apart of the component, where all the settings related to it are in a single window. The suggested go ahead is we move the settings to the component and keep the business logic in the main application. My suggested would be to only graphically change the location of the settings to the user is able to see the settings in one window but still keep things where they belong.


    I could be completely on the wrong here but would like some outside input.

  2. #2
    PowerPoster
    Join Date
    Sep 2005
    Location
    Modesto, Ca.
    Posts
    5,206

    Re: Help me explain why this should not be done

    The way I see it,

    Settings that are the same for ALL Users should be kept in the Main program.
    Setting that could vary from User to User should be kept in the component.

  3. #3
    Super Moderator Shaggy Hiker's Avatar
    Join Date
    Aug 2002
    Location
    Idaho
    Posts
    39,039

    Re: Help me explain why this should not be done

    It seems like there are two alternatives, and I don't really have a preference, myself.

    In practice, I have a program that keeps all settings in the same place, though that place is a database table. There is just a field for whether it is a general setting or a user setting. However, that design is largely driven by the convenience of the database. I do prefer the idea that all the settings be in one place, but ONLY if all the settings can be known in advance. The advantage of a database, in this case, is that there is one central location where the settings can be stored that is accessible both by the main program and by any components. The database providers a form of orderly storage. You could do the same thing in the application, and that seems likely to be the most beneficial, but it requires that the application be able to store settings such that it knows which belong to the main program, which come from the component, and any other distinctions. Largely speaking, this seems to mean that the setting storage in the main program has to have some mechanism such that it can accept settings from the component.

    So, I guess I prefer them all be in one place, but various specific situations could change my view.
    My usual boring signature: Nothing

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  



Click Here to Expand Forum to Full Width