DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Results 1 to 2 of 2

Thread: Architecture & Secuirty

  1. #1
    Dave Green Guest

    Architecture & Secuirty


    Were developing an App, at the moment using a 3 tier approach, and there is
    a need to stop data users from changing key information from the UI, but
    if an administrator accesses the UI they are allowed to change the key information.

    How can I stop the button which accesses the form to change the information
    being available to Data Users. I have coded the application so they cannot
    execute the Business Object but dont know how to hide the button, in a neat
    way as there are many buttons which shouldn't be available

    Thanks in advance
    Dave

  2. #2
    willy van den Driessche Guest

    Re: Architecture & Secuirty


    "Dave Green" <dsgreen57@aol.com> wrote:
    >
    >Were developing an App, at the moment using a 3 tier approach, and there

    is
    >a need to stop data users from changing key information from the UI, but
    >if an administrator accesses the UI they are allowed to change the key information.
    >
    >How can I stop the button which accesses the form to change the information
    >being available to Data Users. I have coded the application so they cannot
    >execute the Business Object but dont know how to hide the button, in a neat
    >way as there are many buttons which shouldn't be available
    >
    >Thanks in advance
    >Dave


    We have coded "Buttons" as actions. It is the business layer that decides
    at any time which actions are available. It is the windows layer that decides
    how to display the actions (toolarbuttons, menus, buttons, ...).

    For deciding which actions are available, we pass the "current selection".
    In a Grid this is a list of selected items, in a detail screen this is the
    object being edited.

    This mechanism works for us for two reasons : building the selection is quick
    and deciding on the availability is also quick. If we can't decide quickly
    we leave the action available but let if fail in the business layer, which
    pops up an error message in the window layer.

    In our case all actions are of the same class. If would have been better
    (yet less understandeable) to make all actions separate classes that implement
    a common interface. Then the actions can decide for themselves whether they
    are available or not. We implemented the latter in a quick Java prototype
    of our app. The actions "observed" the selection. Link objects observed
    the action status and [enabled/disabled], [changed cpation], [changed tooltip],
    [changed picture] of the Windows Widgets. As I said, while this latter approach
    was more flexible, it was also much more cumbersome to "get right" once in
    code.

    Anyway, it's up to you to implement it for your specific situation.

    Willy.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center