Multiple Web Applications Scenarios

Topics: Web Client Software Factory
Feb 5, 2007 at 8:08 PM
Hi,

I'm new to this WebSF and couldn't find information on scenarios involving multiple web applications.

Scenario: Your organisation has many public web applications built by various teams but leveraging a common look & feel.

One team is actually responsible for the main page and the look & feel.

I can think of two solutions:

Solution #1: One major Solution (.sln) with every projects (WebSF module) under it. (ouch, no?)
Solution #2: Send each team the Home Page & look & feel as a test home page. When their files are deployed, they're merged with the main site.

An example of various web apps could be Microsoft's web site(s): hardware, server, OS, msdn, technet, etc.

Any ideas?

Pat
Coordinator
Feb 5, 2007 at 10:47 PM
The factory was designed to support Solution #2. Here is a link to previous post that discusses how to accomplish this: http://www.codeplex.com/websf/Thread/View.aspx?ThreadId=3858.

As stated in this post, we discussed creating a recipe to deploy modules, but it did not make the scope cut. Additionally the current RI has the modules in one solution so it may not be as obvious the factory supports Solution #2 listed above.

If need more information, please let us know.

blaine
Feb 6, 2007 at 7:53 PM
Edited Feb 6, 2007 at 7:55 PM

The factory was designed to support Solution #2. Here is a link to previous post that discusses how to accomplish this: http://www.codeplex.com/websf/Thread/View.aspx?ThreadId=3858.

As stated in this post, we discussed creating a recipe to deploy modules, but it did not make the scope cut. Additionally the current RI has the modules in one solution so it may not be as obvious the factory supports Solution #2 listed above.

If need more information, please let us know.

blaine



Interesting.

The one solution for all will be difficult to implement in our side (politics).

How about this: there's one solution (.sln) for the home page project and serves as a basis for project's modules. This home page project could contain core business modules, of course.

Each project team creates their own Websf project, but use the core web app. They just need to put their "business" in their Folders to prevent two teams to use the same filenames.

core.sln
  • - Modules
    • - Core Shell
  • - Web
    • - CoreWeb

project a.sln
  • - Modules
    • - Core Shell
    • - Module A
  • - Web
    • - CoreWeb
    • - /ProjectA/web files

When the core releases a new version, individual projects might/could integrate the new files in the project.

Is this a clean approach? It just becomes a known and best practice to never change Core Files as it's guaranteed that changes made to them will not be deployed in the production site anyway.

Pat
Mar 20, 2007 at 4:10 PM
What about in the case of a module having a dependency to another module? For example, if Module A needed something from Module B, then now the Module A solution will have the CoreWeb and ModuleB. Should these be read-only project references? How would this work from a source-control point of view?