Managing library project, iternationalization and errors

Discussion in 'Java' started by Karsten Wutzke, Sep 3, 2007.

  1. Hello!

    I'm not quite happy with a current design aspect in my software. I use
    an own library into which I put a bunch of packages and classes for
    reuse in other projects.

    For each specific project, I created one huge centralized class
    containing ALL keys of localizable (GUI) elements, which currently are
    all strings. By creating one big file, I can refer to only one file
    and forget about knowing many. Is that a good idea? I keep remembering
    "OOP promotes distributed programming" and what I do/did (using one
    centralized class) is pretty much the contrary.

    Does anyone have a good advice how to manage the GUI keys? I already
    use property files with resource bundles, so I mean where to put the
    property file keys/identifiers which refer to a localized resource/
    string when writing the actual code

    GuiElem.OK_ACTION_NAME_KEY
    GuiElem.CANCEL_ACTION_NAME_KEY

    ^^all centralized in project specific class

    2. I didn't have to care much about error messages thus far, I don't
    mean those which go to the log file, those are *not* localized anyway.
    But what about those which will be displayed to the user?

    I have some custom classes to ease server communication, an
    abstraction which is part of the API. If that fails for some reason,
    it is supposed to log and return some indicator what went wrong. I'm
    not sure but error codes come to my mind. On demand the client using
    the class/object/method can decide what to do with the returned code.

    Again, this raises the question for how to design error codes, that
    is, where to put them -> centralized vs. uncentralized...

    I'd gladly appreciate if you could share your experiences with me
    considering this is so trivial. Some pros cons discussion is welcome
    as well as best practices...

    Karsten
    Karsten Wutzke, Sep 3, 2007
    #1
    1. Advertising

  2. Karsten Wutzke

    GArlington Guest

    On 3 Sep, 13:02, Karsten Wutzke <> wrote:
    > Hello!
    >
    > I'm not quite happy with a current design aspect in my software. I use
    > an own library into which I put a bunch of packages and classes for
    > reuse in other projects.
    >
    > For each specific project, I created one huge centralized class
    > containing ALL keys of localizable (GUI) elements, which currently are
    > all strings. By creating one big file, I can refer to only one file
    > and forget about knowing many. Is that a good idea? I keep remembering
    > "OOP promotes distributed programming" and what I do/did (using one
    > centralized class) is pretty much the contrary.
    >
    > Does anyone have a good advice how to manage the GUI keys? I already
    > use property files with resource bundles, so I mean where to put the
    > property file keys/identifiers which refer to a localized resource/
    > string when writing the actual code
    >
    > GuiElem.OK_ACTION_NAME_KEY
    > GuiElem.CANCEL_ACTION_NAME_KEY
    >
    > ^^all centralized in project specific class
    >
    > 2. I didn't have to care much about error messages thus far, I don't
    > mean those which go to the log file, those are *not* localized anyway.
    > But what about those which will be displayed to the user?
    >
    > I have some custom classes to ease server communication, an
    > abstraction which is part of the API. If that fails for some reason,
    > it is supposed to log and return some indicator what went wrong. I'm
    > not sure but error codes come to my mind. On demand the client using
    > the class/object/method can decide what to do with the returned code.
    >
    > Again, this raises the question for how to design error codes, that
    > is, where to put them -> centralized vs. uncentralized...
    >
    > I'd gladly appreciate if you could share your experiences with me
    > considering this is so trivial. Some pros cons discussion is welcome
    > as well as best practices...
    >
    > Karsten


    Usually you should have resource packages per language, when you
    install the application or the applet is loaded it should read the
    language settings on the client and load appropriate resource per
    language.
    Further more you might want to separate resources by something like:
    Res.Messaging - all messaging localised strings, Res.Common - all
    common localised strings, GUI.Common - all common forms elements and
    labels (there are not too many), GUI.ApplicationSpecific - application
    specific localised strings...
    GArlington, Sep 3, 2007
    #2
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Mark Goldin

    Errors, errors, errors

    Mark Goldin, Jan 17, 2004, in forum: ASP .Net
    Replies:
    2
    Views:
    942
    Mark Goldin
    Jan 17, 2004
  2. horseface
    Replies:
    2
    Views:
    306
    Anton Spaans
    Jan 20, 2005
  3. mathieu

    Managing large python/c++ project

    mathieu, Jun 20, 2008, in forum: Python
    Replies:
    0
    Views:
    427
    mathieu
    Jun 20, 2008
  4. Philipp

    Managing a software project

    Philipp, Nov 12, 2008, in forum: Java
    Replies:
    1
    Views:
    269
    Jason Cavett
    Nov 12, 2008
  5. Stuart Hungerford
    Replies:
    0
    Views:
    111
    Stuart Hungerford
    Mar 14, 2006
Loading...

Share This Page