🚀 go-pugleaf

John,

Thanks for your thoughtful answers.

I've read the GoF chapters on Observer/Observable.  But I haven't really
done any GUI stuff in Java and guess I have a lot to get through.

I have started a LoginPanel class that contains the basics (server,
username, password, login button); I'll worry later about Decorators that
might add additional buttons...?

But it sounds like the LoginPanel needs an Authentication object
(application specific, one for Caliber, one for ST, etc.) that will handle
the login.

At least I think that's what you're suggesting at the end.  Let me know if
I'm way off.

Scott



"John McGrath [TeamB]" <ng-b@JPMcGrath.net> wrote in message
news:xn0dzil6p8qysno000@newsgroups.borland.com...
> On 3/7/2005 at 9:30:19 AM, Scott wrote:
>
> > I haven't actually written the code yet.
>
> Then you should start.  Sometimes it is hard to get going when you do not
> know where you are heading.  But at the same time, you will seldom be able
> to know the exact path until you start.  Once you get moving, you will get
> a better feel for where you are heading.
>
> > Let's say my main application does something to a database, but before
> > the operation can occur, the user must login.
> >
> > So form1 is the "do something to the database" form.  Form2 is the
login.
> >
> > I've read that if I use the Dialog class, Form2 (login) requires Form1
in
> > its constructor.
>
> That is one possibility.
>
> However, instead of accepting an argument of type "Form1", you can define
> an interface to use in place of the concrete class.  The interface would
> contain only those methods that the login dialog needs to use to inform
> its caller about what is going on.  This would decouple the two classes
> and allow the same dialog to be used by other "forms" (or code other than
> a form).
>
> In some cases (although I am not sure this is one of them), it may be a
> good idea to make this a settable property rather than a static value
> supplied only with the constructor.  This is a good approach when it makes
> sense for the associated object to change over time.
>
> An even more general version of this approach is using "listeners".
> Rather than only allow a single instance of the interface property to be
> set, you allow any number of them.  You have undoubtedly seen this pattern
> many times in the AWT / Swing components that you have used.
>
> For a modal dialog, it often makes sense to use property "getters" on the
> dialog.  The code shows the dialog, then when it is dismissed, the code
> gets the property values using the getters.  Of course, this only applies
> to the "results" of the dialog, not information the dialog needs to
> perform its work.
>
> > In that case, would I implement a "loginButtonPressed" method in Form1
> > (the main app)?  Or is there a better mechanism?
>
> The goal is to reduce coupling and increase orthogonality in your code.
> In order to accomplish this, each class in your code should have a concise
> and well-defined purpose, and classes should know the absolute least
> possible about how other classes work.
>
> So in this case, what does the main form need to know about the login
> dialog?  More specifically, does it need to know that it the user has
> pressed a "login button", as opposed to press the "enter key"?  Obviously,
> it does not, so at least that name is inappropriate.
>
> So what does the main form do and what does it need to know?  I do not
> know what your application does, but my guess is that it has some
> functionality that it needs to provide, and authenticating the user is not
> the core of what it does.  It probably just needs to know who the
> authenticated user is.
>
> So you probably want a separate class that handles the authentication.  It
> would be the one that knows about displaying a login dialog, although it
> should not know whether the user presses a button, hits Enter, or
> whatever, since the dialog's job is to handle the user interface.
>
> In order to do its job, your dialog will probably need to be able to check
> whether a username/password combination is valid, since you probably want
> to give the user a second chance if he makes an error.  But again, that is
> not its primary function - you probably want the authentication class to
> handle that, or even a separate object provided to it by the
> authentication class.  More than likely, it would provide this object to
> the dialog in its constructor.
>
> All of this probably sounds complicated to you, but it really is not.
> Once you learn to create simple objects that do their own thing (and only
> their own thing), you will find that each little thing is quite easy to
do.
>
> -- 
> Regards,
>
> John McGrath [TeamB]
>
> ---------------------------------------------------
> Before sending me e-mail, please read:
>     http://www.JPMcGrath.net/newsgroups/e-mail.html