I've begun using IStartup instead of a Bootstrapper. I've been told that
only one Bootstrapper should exist in one environment and the library that
I'm writing is not going to be the direct host so it should go into
IStartup.

I've done this but I need to move the below into IStartup:

Func<TinyIoCContainer, NamedParameterOverloads, IDocumentSession> factory = (ioccontainer, namedparams) => new DocumentSessionProvider().GetSession();

container.Register(factory);

In IStarup there are

IEnumerable<CollectionTypeRegistration> CollectionTypeRegistrations { get; }
IEnumerable<InstanceRegistration> InstanceRegistrations { get; }
IEnumerable<TypeRegistration> TypeRegistrations { get; }

Firstly I'm not sure which one I should put this logic into, I assume TypeRegistrations but then I'm not sure how to configure it to create a new TypeRegistration and pass in the Func. There does not seem to be any documentation on IStartup

Thanks

The reason I ask is that I have a module such as below that needs a session
injecting into it:

public class PostModule : NancyModule
    {

        private readonly IDocumentSession DocumentSession;

        public PostModule(IDocumentSession documentSession)
            : base("/posts")
        {
            DocumentSession = documentSession;

            Get["/"] = parameters => "Hi";
        }
    }

i think IStartup and got renamed to IApplicationStartup in 0.12 and does
not contain CollectionTypeRegistration and those properties you listed.

You can just override ConfigureRequestContainer or
ConfigureApplicationContainer in bootstrapper.

container.Register<IDocumentSession>((c,p) => new
DocumentSessionProvider().GetSession());

It does look like that for 0.12 which means where do I put them as I can't
put them in a BootStrapper

It looks as if there is a IApplicationRegistrations now with the previous
properties I mentioned so the original question still stands.

Thanks

That kind of logic does not work in IStartup (which will be
IApplicationStartup and IApplicationRegistrations in 0.12) because nether
will give you access to the container. Not quite sure of your context so
not sure
what to suggest as an alternative. Why can't you put it in the bootstrapper?

On Tue, Aug 7, 2012 at 11:26 PM, Jonathan Channon <

As I said on Jabbr, you can't use a factory delegate you need to make a
factory class, register that, then take a dependency on it - if you think
about it, it's obvious that we can't support delegate factories in the
startup classes because we're container agnostic - what would happen if you
ran a container that didn't support them?

The one piece of the puzzle that *is* missing though is startup tasks per
request - we avoided adding this because nobody could give us a use case
and there may be potential perf implications, so we'd have to add that in
before this is possible, so my original suggestion of newing up the session
in the module still stands as a workaround.

*But* I still stand by my statement that persistence should be the remit of
the host app, not your library, which removes this problem altogether.

Andreas: he can't use the bootstrapper because this is a "drop in
functionality" dll, not an app.

Ok, so if I move the database stuff to the host app how will it work?

Here is an example of what one of the current routes does in SugarTown
(remember its just a CRUD app):

Post[Route.Root().AnyIntAtLeastOnce("id")] = parameters =>
        {
             var model = DocumentSession.Load<Post>((int)parameters.id);
             this.BindTo(model);
             DocumentSession.SaveChanges();
             return Response.AsRedirect("/posts");
        };

If I move the data storage out how to the host app I'll still need some generic interface to tell it to save the data so IDocumentSession becomes IDatabase?

What about using a Pipeline hook to register the IDocumentSession in
Context.Items? It won't be injected into the constructor but it allows
you to control it at the request level.

On Wed, Aug 8, 2012 at 1:18 AM, Jonathan Channon

I guess if you did that, that would be a roundabout way of
making persistence agnostic as the host app would then be responsible of
passing in a IDatabase instance to whatever storage menchanism they want to
use. Only thing left is what GrumpyDev said about performance, this is
slightly different though.

And the other issue is passing requests from hostapp to other app.