Tags:
create new tag
view all tags

Question

What are the advantages and disadvantages of using sub-webs instead of creating another normal web.

We have requests for securing some a webs topics and we have the above choice.

Can users share their experiences?

Environment

TWiki version: TWikiRelease04x01x02
TWiki plugins: DefaultPlugin, EmptyPlugin, InterwikiPlugin
Server OS: RH
Web server: apache
Perl version: 5.8
Client OS: XP, Linux, Mac
Web Browser: IE, Firefox, Safari
Categories: Deployment

-- PeterJones - 28 May 2008

Answer

ALERT! If you answer a question - or someone answered one of your questions - please remember to edit the page and set the status to answered. The status selector is below the edit box.

I personally never use sub-webs, and I cannot recommend it for large installations. Reasons:

  • Easier to cross-link between webs with simple Web.TopicName syntax
  • Flat web list works well, even if large (I have seen a TWiki with over 1000 webs)
  • Companies reorganize often, e.g. a nice web hierarchy gets out of sync quickly. You could rename/move the webs, but this will break all links pointing into TWiki. Better to have a stable flat list of webs, and to create a logical hierarchy of webs by org chart. This logical list is maintained manually, e.g. you can rearrange and weed out stale webs as needed. See for example "Browse by webs facet" screenshot at HomePageNavigation.
  • Easier to manage access control, e.g. visit the web's WebPreferences and you know what the access control is (no need to see what access control settings are done in higher webs.)
  • Better performance with {EnableHierarchicalWebs} configure setting turned off if you have large webs (> 10K pages each.)

For special circumstances it might make sense to use hierarchical webs, such as when maintaining an external website in TWiki with sub-directories.

-- PeterThoeny - 28 May 2008

I would agree with Peter. On where the subwebs may be useful is when a team has a web, and want some auxiliary webs such as a blog, task list, ...

You definitely want to avoid mirroring your company orgchart as wiki webs, otherwise you will suffer and break URLs every time there a re-org, as Peter says.

-- ColasNahaboo - 03 Jun 2008

I am considering the possible future creation of a "Projects" web, with subwebs for each client. What would the experts recommend for this type of division? I'm trying to take a long view toward eventually having the type of project dashboards I frequently see discussed and thinking that to kind of tracking that we need will require many thousands of topics. So, in my mind, the subwebs might help keep general navigation lighter and search results faster.

-- DavidWolfe - 03 Jun 2008

Also in this case you can use a flat list of webs and organize them logically. In your Projects web you could add a SEARCH listing all active project webs. That could be identified with a PROJECT_STATUS preferences setting in each web's WebPreferences. Values could be Active and Closed. The SEARCH would identify all "PROJECT_STATUS = Active" webs. See SiteMap for inspiration.

-- PeterThoeny - 03 Jun 2008

Very cool, and looks easy enough to do. Thanks for the tips. It will be a while before we're ready to try to implement our Project Management stuff. We've got lots to learn yet. But this, I think, will help with organization. The next logical step to me would be that we could list our active projects as you have shown, then maybe provide a link to another topic that SEARCHes for inactive projects, for the times someone needs to look up information about something that's not in progress.

-- DavidWolfe - 03 Jun 2008

Change status to:
Edit | Attach | Watch | Print version | History: r6 < r5 < r4 < r3 < r2 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r6 - 2008-06-03 - DavidWolfe
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2026 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.