Bank Teller sample

[Bil Simser]

Hi guys,

I'm looking at the Bank Teller sample as ideas on using the framework
(mainly the UI composition). Any thoughts on how you would wire in a
splash presenter/view into this? The current sample only starts the
login presenter in the main form which is pretty minimal. Not sure how
you would wire something new in and chain the presenters together
(should there be a ShellPresenter or something?).

[David Laribee]

Hey Bil,

I know I owe you an email.

I'd just put this in the ApplicationContext. Say you wanted to show a splash until some reference data got loaded or something. I'd load that data up in a ShellPresenter that fired an event saying "loaded" (in the CustomStart method), subscribe to that event in ApplicationContext, then display the shell.

So the sequence could be: Splash, Load Data, Data Loaded, Login Form, Logging In, Display Shell

You could also use a single ApplicationController if the context thing bothers you. There's probably a point in time where this is sensible. Even so, I find the code there so minimal that I just go with the flow until it gets big.

We're big fans of keeping it simple ;)

--


/ Dave

http://thebeelog.com

[Bil Simser]

I'm all for minimalism. Thanks for the ideas.

Bil "der Rohe" Simser

On Apr 29, 8:07 am, "David Laribee" <da...@laribee.com> wrote:
> Hey Bil,
>
> I know I owe you an email.
>
> I'd just put this in the ApplicationContext. Say you wanted to show a splash
> until some reference data got loaded or something. I'd load that data up in
> a ShellPresenter that fired an event saying "loaded" (in the CustomStart
> method), subscribe to that event in ApplicationContext, then display the
> shell.
>
> So the sequence could be: Splash, Load Data, Data Loaded, Login Form,
> Logging In, Display Shell
>
> You could also use a single ApplicationController if the context thing
> bothers you. There's probably a point in time where this is sensible. Even
> so, I find the code there so minimal that I just go with the flow until it
> gets big.
>
> We're big fans of keeping it simple ;)
>

[Bil Simser]

Dave,

ShellContext starts the ShellPresenter in an adapter. Would
ShellContext create two presenters then (one for the shell and one for
the splash?) and start them both?

On Apr 29, 8:07 am, "David Laribee" <da...@laribee.com> wrote:

> Hey Bil,
>
> I know I owe you an email.
>
> I'd just put this in the ApplicationContext. Say you wanted to show a splash
> until some reference data got loaded or something. I'd load that data up in
> a ShellPresenter that fired an event saying "loaded" (in the CustomStart
> method), subscribe to that event in ApplicationContext, then display the
> shell.
>
> So the sequence could be: Splash, Load Data, Data Loaded, Login Form,
> Logging In, Display Shell
>
> You could also use a single ApplicationController if the context thing
> bothers you. There's probably a point in time where this is sensible. Even
> so, I find the code there so minimal that I just go with the flow until it
> gets big.
>
> We're big fans of keeping it simple ;)
>

[David Laribee]

Yeah. You'd have (probably) one WindowManager and two WindowAdapters, one for each presenter (WindowManger creates adapters which is simply an abstraction for window, see WindowManager and WindowAdapter specifications).

Each presenter has a DisplayIn method that takes a suitable WindowAdapter. Figure each WindowAdapter coorespnds to one Window.

What I'd do is use a single WindowManager (really just a factory for returning adapter which, again, act on a single window). Create the splash and DisplayIn it's own WindowAdapter. Next retrieve whatever startup data you need (maybe user preferences?) or Start the Login or Shell. Once that's started (is there an event? should be) then Finish the SplashPresenter (which should close the WindowAdapter it's displayed in). From there call DisplayIn on your next presenter.

Rinse and repeat as necessary. Hope this makes sense...

[Laribee]

Heh, cute.

[Bil Simser]

Hmmm. This makes sense but I'm finding I have to create a lot of
classes that do very little to get this to work. SRP is great, but it
seems the framework takes it to the next level.

The IWindowFactory implemenatation (that gets called by the
WindowManager to create the adapter) has no way to tell what kind of
adapter to create. So if I go on the principle that I create one
WindowAdapter per presenter (makes sense) I have a WindowFactory per
adapter.

With a single WindowManager, I have to pass it an IWindowFactory to
create it. So I'm going to have to new up my WindowManager each time I
need an adapter?

Here's what I see having to write to create my first presenter
(SplashPresenter):

IWindowManager manager = new WindowManager(new
SplashWindowAdapterFactory());
SplashWindowAdapter adapter = (SplashWindowAdapter) manager.Create(new
WindowOptions(true, 200, 200));
SplashPresenter presenter = new SplashPresenter();
presenter.DisplayIn(adapter);
presenter.Start();

Then I do it all over again for the ShellPresenter:

IWindowManager manager = new WindowManager(new
ShellWindowAdapterFactory());
ShellWindowAdapter adapter = (ShellWindowAdapter) manager.Create(new
WindowOptions(false, 800, 600));
ShellPresenter presenter = new ShellPresenter();
presenter.DisplayIn(adapter);
presenter.Start();

And I can't use IoC to resolve things like the WindowManager because I
have to pass it a different factory for each adapter I want. I almost
want to create an AbstractPresenterFactory that going to create all
this stuff for me, which seems somewhat complex. Am I off here or
there is something I'm missing?

> http://thebeelog.com- Hide quoted text -
>
> - Show quoted text -

[David Laribee]

You should only need one implementation of IWindowFactory. It's responsibility is to build up a WindowAdapter. Keep in mind that a WindowAdapter is an abstraction of a window and its implementation will generally only vary based on the UI technology you're using (Silverlight, WPF, WinForms).

See the code for the sample client WindowFactory:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

using System; using System.Collections.Generic; using System.Text; using XF.UI.Smart; namespace BankTeller.UI.Smart {   public class WindowFactory : IWindowFactory   {      public IWindowAdapter Create()      {         return new WindowAdapter();      }   } }

You should really only have to implement this once. You can certainly IoC this sucker if you want.

WindowManager is a bit of a future proofing thing. We're going to add (shortly) some features that let you manage "indexed windows" (e.g. I only want one of a window matching this key, focus it if it's displayed again, etc.) You may have multiple WindowManagers in your application but I'd be surprised if you have more than 2-3. We're also going to add a "display memory" feature in here that, when you ask for an WindowAdapter, will set the position and size of the WindowAdapter.

All of this should be IoC-friendly. Which container are you using?