Re: I think I need to jar my thinking vs a global object

Responding to Krug...

My comments below assume your application is not pure CRUD/USER processing (i.e., there is a significant business problem to solve).

Many of the methods of our current project depend upon properties of the
current user.

Most of these are UI issues . . . buttons shown or not shown depending
on whether the current user has sufficient rights to use those
functions.

Separate the UI from the problem solution by encapsulating it in a subsystem or layer. The plethora of UI details are only of interest to the display subject matter. Things like sufficient rights are a matter of business rules and policies and they belong outside the UI representation. If one does that, then...


Right now, we have "currentUser" which is a global object.

One does not have a global abstraction of the User. Assuming the UI is a GUI, then the paradigm for display is Window/Control and the user will be represented by a Window instance with a suite of related Control instances. Those instances would have all the detailed display information, like fonts and background colors.

In the problem solution the notion of User is different and it will be abstracted with attributes that will support business decisions about rights and whatever else the problem involves. Since the UI is encapsulated, there would be no need for that User to understand anything about display issues like fonts. That will simplify the abstractions on both sides of the boundary.

[My blog has a category on application partitioning that goes into these ideas more thoroughly.]


Is there a better way to do this sort of thing?

I'm certain this type of thing comes up all the time with fonts,
localization . .that sort of stuff.

Localization is an interesting topic because I don't think the industry has shaken out yet over the best way to address this. Fundamentally there are three approaches. One is to use parametric polymorphism through configuration files. That is, one provides a generic UI implementation (e.g., unicode strings) and then sources all the strings needed for labels, etc. from an external configuration file that is localized. In a GUI, the resource file that defines windows would employ identity handles to the localization configuration file contents.

Another approach is to simply substitute the UI subsystem implementation for the localization context. Since the interface to the problem solution remains the same, this becomes a matter of DLL deployment. While this gives one more control over detailed rendering, one must fully implement basically the same UI for each localization context. Both of these work OK when the localized text to display is fixed (i.e., the display text for labels, titles, etc. is not dynamically defined).

The third approach is a variation on the first where one provides a "buffer" subsystem between the problem solution subsystems and the UI subsystem. This buffer subsystem handles the localization when the application must provide ad hoc strings that need to be translated on the fly. This allows both the UI and the problem solution to be independent of localization but the translation may be somewhat challenging.

You will note, though, that in all three approaches encapsulating the UI in a subsystem is a crucial piece of the puzzle.


*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@xxxxxxxxxxxxxxxxx
Pathfinder Solutions  -- Put MDA to Work
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
(888)OOA-PATH



.

Quantcast