Is it possible to inject Web Pages into a Web Site via a Module?

Topics: User Forum
Aug 21, 2008 at 2:32 PM
According to the Modularity Guidance documentation, the answer to the question is yes.

Modularity
is the ability to create rich Web client applications from discrete functional units named modules. A module represents a set of related concerns. It can include entities such as Web pages, business logic, page flows, and pieces of the Web infrastructure, such as the ability to log events or authenticate users. Each module is functionally complete and can communicate with other modules to create a complete application.

I am new to the Web Client Software Factory, but I have been working with the Smart Client Software Factory for some time.  In SCSF, I can create a module as an autonomous unit.  I never need to even have a reference to the Shell application to write it.  I can hand off my module and it can be plugged into the Shell without me having ever seen the Shell.  Additionally, I can deploy the SmartClient with only certain modules, or deploy it with all of them and only load certain modules based on user credentials/roles.

The documentation for WCSF leads me to believe the same thing is achievable, but my limited experience is telling me otherwise.

When adding a Web Page (With Presenter) using the Guidance Package, an interface for the view as well as a presenter are added to the module.  Additionally, a web page is added to a corresponding location in the web site itself.   Since the Web Page is added directly to the Web Site, and does not reside in the Module next to it's presenter and interface the Module is no longer an autonomous unit. 

I am hoping to find a way to house the ASPX pages within the modules themselves, then inject them into the web site somehow.


Aug 21, 2008 at 4:19 PM
I hope someone can provide an answer as that's a question I was asking myself when we started the current project.

My thoughts are that you can achieve something like this by having a separate website for your module which then is "deployed" as a (virtual) folder under the target "shell" website. I remember seeing a discussion about multiple websites, prompted by the "website" drop-down selection in the "Add View (with presenter)" recipe. I don't think that discussion ever determined if that's possible...

Due to time constraints, the project I work on did not go that direction. Instead I put all web pages that belong to certain module under its own folder under the root of the website.

Wasn't there a module config section in web.config? That may provide some hints, I guess...

Giorgi
Aug 22, 2008 at 12:05 AM
I hope I can clear this up a bit.  Please bear with me as I may ramble a bit.
Visual Studio is a fantastic development environment, powerful and extensible.  The WCSF team used Visual Studio and the Web Application project type as a starting point for our work.  However, we are using some of the built in functionality in ways that severly stretch how it is supposed to be used.  The bits that are stretched cause confusion.

In an ideal world, you could have a folder under your module (and not the web site) that contains the web pages, user controls, etc, and the IDE would allow you to configure this arbitrary folder as "living" in the web site at a particular location.  Unfortunately this ideal environment does not exist yet. Instead, we made some trade offs.  To allow for a simple(r) development experience, the web pages live in a folder on the web site, and the web site references the module DLLs.  This gives you things like designer support, intellisense, easy compilation, and the ability to run and debug the web app with the push of a button.  The other option was to keep everything related to a module self contained, and then have scripts that compiled the module, copied the pages to the correct folder under the web site, and copied the module DLL to the site Bin folder. Also, for every module, there would have also been a cleanup script that deleted the right files every time and was easily callable.  However, this setup broke several things that developers take for granted (I can't remember what, it was a long time ago, but basically you ended up with a very nice color coded version of Notepad). 

You can get a very similar experience to CAB development by creating a WCSF web site and solution for each module, adding nothing to the Shell module (or having a shared Shell module that you sync between solutions somehow), and doing "true" modular development and deployment.  However, this may become painful fairly quickly.

I hope that helps a bit.  If not, let me know.  Also, if you try this and have a good experience, let me know how you did it.

Michael Puleio - patterns & practices
Blog http://blogs.msdn.com/mpuleio/
Aug 22, 2008 at 1:57 AM
Michael, I appreciate you shedding some light on my situation.

It's entirely possible that what we wanted to do could be done without portable modules.

Our goal was to create a web based administrative portal.  The administration of the core system was to consist of things managing users, core configuration,  roles, permissions, etc.  The underlying system is already extensible.  It allows for assemblies to be injected to facilitate new functionality.  In one "install", we wanted to be able to inject the assemblies into the core system, run any necessary database scripts, and inject new functionality into the web site. 

Alternative solutions for implementing the above are certainly welcome.

I am going to attempt to hack together a functional work around similar to the one you described this weekend.  It may even be possible encapsulate the logic of moving the pages from the module to the website via a build event.   Even if the logic gets dirty, I may be able to write a simple reusable command-line tool in order keep the build events clean.