Automatic page ID's

[erijvordt]

Hi,

A question about the feature that automatically assigns an object ID to pages defined in the application context: how can you have multiple pages with the same base name in a web app?

I noticed that when I have a page:

<object type="~/Path1/ProcessData.aspx"> ... </object>

then it doesn't matter what URL I use to refer to this page, I can use any path as long as it ends with "/ProcessData.aspx". This means that I can't have another page object like this:

<object type="~/Path2/ProcessData.aspx"> ... </object>

because it has the same auto-ID as the first one, overwriting the registration of the first page. I tried specifying a distinct ID in both objects, but then it seems I have to use that ID to invoke the page as well, in which I could just as well name both pages differently in the first place.

Any suggestions?

Regards,
Edwin

[Aleks Seovic]

Solution to your problem is to use hierarchical contexts and put each page definition in a different context.

For example, instead of creating definitions for both pages in root Web.config (or external file referenced from it), you should create separate Web.config files within Path1 and Path2 directories and place appropriate definitions within those files.

There will be no id clashes because sibling contexts don't see definitions from one another. On the other hand, PageHandlerFactory will always try to lookup page definition in the most specific context (the one that is defined in the page directory) if one exists, and only if it doesn't find definition there it will look it up in the parent or root context.

What we will probably do before official release is create a strategy interface for page id determination from the URL. Default implementation will continue to exhibit the current behavior, but you will be able to create your own implementation that calculates page id any way you want.

That said, approach mentioned above should solve your problem and is a recommended way of building Spring.Net web applications because it allows easy information hiding between various components while still providing easy access to common objects defined in the root application context.

HTH,

Aleks