Feature Proposal: Create HOMEWEB variable as distinct from MAINWEB

Motivation

It is sometimes desirable to specify a entry web for a site that is not tangled up with the multiple purposes of the Main web. However, we have only one variable that specifies both the entry point for the site (used for top level of "breadcrumb" and logo) as well as other essential system functions such as identifying location for user topics. This makes it difficult to easily specify an alternative entry or home web for the site.

Description and Documentation

Proposed: create a new variable called either HOMEWEB or ENTRYWEB that is used to specify the top-level web for the site. Use this variable in skins for the top level of breadcrumbs, WIKILOGOURL, and WIKIHOMEURL.

Of course, this can be fairly easily implemented by defining the HOMEWEB variable in TWikiPreferences and making small changes in the skin definitions for the breadcrumb display. It would just be nice if this was part of the default distribution.

Examples

Impact and Available Solutions

Implementation

1. Define HOMEWEB variable in TWikiPreferences topic.
2. Revise the top level link in the "breadcrumb" template element in distrubuted skins.
3. Set WIKIHOMEURL to this variable by default.

-- Contributors: LynnwoodBrown

Discussion

-- LynnwoodBrown - 28 Oct 2006

Why not WIKIHOMEWEB ?

-- ArthurClemens - 28 Oct 2006

True, since we already have a WIKIHOMEWEB we could use it consistently, e.g. also as the root of the breadcrumb.

-- PeterThoeny - 28 Oct 2006

I've not seen WIKIHOMEWEB before and I don't find it in a search of TWiki.org. Are you proposing it as the name for this new variable? If so, i'm fine with that name. If it already exist, I'd appreciate if someone could point me to where it's documented. Thanks. I'll be glad to make the change and do the docs if there's any chance of sneaking it into 4.1.

-- LynnwoodBrown - 31 Oct 2006

Indeed, it does not exist; I was confusing it with the existing WIKILOGOURL / WEBLOGOURL variable.

Since it does not exist, let's brainstorm on the use cases and name for a bit.

Use cases, TWiki is used:

• for many projects/services/interest groups, using different webs:
  • Entry point is typically the default Main.WebHome
  • ==> current default setup, e.g. no need to change anything
• for one primary project/service/interest group:
  • Entry point is most likely the web's home, such as FooBarSIG.WebHome (actual use case at a large financial institution)
  • ==> The name of the web needs be set for the home icon link and the first link of the breadcrumb
• as an Intranet replacement:
  • One topic in the Main web or an application web is declared as the Intranet home, such as Main.IntranetHome or News.IntranetHome; an index.html is generated from it by a cron job (actual use case is TWikiNewsPortal)
  • ==> The Web.TopicName needs be set for the home icon link and the first link of the breadcrumb

What is a good name for this? START*, HOME*, WIKIHOME*

What needs to be configurable? Separate out web name and topic name? Configurable Alt text? Configurable link text for breadcrumb home?

This is a small enhancement, it does not require a code change. That is, it does not fall under the feature freeze.

-- PeterThoeny - 31 Oct 2006

From the real world. Our TWiki consists webs for major departments/product groups and special functions. And then there is one web common to all of us. And I called that "Home". So anything with the word Home seems to be a very intuitive choice for the place you go per default. All the wiki-wide variables start with WIKI so the name that falls natural to me is WIKIHOMEWEB

-- KennethLavrsen - 31 Oct 2006

I was proposing it as a name for the new variable.

-- ArthurClemens - 31 Oct 2006

I saw that. And I proposed the same - just with an additional explanation why I also agreed with your proposal. So we all agree then

-- KennethLavrsen - 31 Oct 2006

Great! I'm going to create a bug item so we can finalize actions/approval there.

-- LynnwoodBrown - 31 Oct 2006

Besides WIKIHOMEWEB, I'd add also WIKIHOMETOPIC, WIKIHOMELABEL and WIKIHOMEALT, and modify the breadcrumb home and logo setting (in TWikiPreferences) to use them.

-- PeterThoeny - 31 Oct 2006

What is the performance impact on this? If TWiki has to read 4 additional settings from TWikiPreferences on each page read, does that cost extra execution time?

-- KennethLavrsen - 31 Oct 2006

Make them a configure setting, and create the tags to reference them in topics.

I see no reason of why they should be tags in the TWikiPreferences topic.

-- RafaelAlvarez - 02 Nov 2006

Lynnwood. Are you driving the implementation if this gets decided?

And do we agree on the spec? Ie. 4 settings in configure or 4 more TWikiVariables

-- KennethLavrsen - 08 Apr 2007

I could/would implement it if decied that TWikiVariables is an acceptable approach. I would not know how to implement it in configure.

-- LynnwoodBrown - 09 Apr 2007

OK. We have a clear proposal with TWO options.

• Add the 4 variables in TWikiPreferences
• Add the 4 variables in configure

Lynnwood can implement the first solution. And I am sure I can help Lynnwood with the 2nd if this is chosen instead. With current release schedule proposed this should be a TWiki 5 scope thing.

I think the right thing to do now is bring it up for release meeting.

Let us collect votes now. People can vote here if they cannot make next release meeting.

Name	Decision Configure or TWikiPreferences or None
KennethLavrsen	Will decide at meeting after having heard view on performance

-- KennethLavrsen - 25 Apr 2007

This was discussed at the FreetownReleaseMeeting2007x05x07.

• Some felt that it is important to be able to set logo link per web.
• Question of performance impact on adding to configure vs. adding to TWikiPreferences.

Result:

• Add settings to TWiki.TWikiPreferences, for consistency with existing related settings WIKITOOLNAME, WIKILOGOIMG, WIKILOGOURL, WIKILOGOALT, WIKIHOMEURL.
• Instead of creating new WIKIHOMEWEB and WIKIHOMETOPIC, reuse existing WIKIHOMEURL for breadcrumb.
• Add new WIKIHOMELABEL and WIKIHOMEALT for a nice breadcrumb.
• WIKIHOMELABEL is set to WIKITOOLNAME by default.

-- PeterThoeny - 07 May 2007

FreetownReleaseMeeting2007x05x07: Many good proposals but we feel that Lynnwood as proposer should have a chance to give his views on the proposal topic so decision deferred.

-- KennethLavrsen - 07 May 2007

Lynnwood. I propose based on the previous meeting that you implement the feature using good old TWikiPreferences settings.

The experts told us that there is no performance impact on doing it this way and it enables people to also use the setting in WebPreferences.

-- KennethLavrsen - 21 May 2007

Ok, Trying to revive this topic. I think that a HOMEWEB setting is also necesseary if you want to make a nice, more "web site" site, in conjonction with the ShorterUrlCookbook. This way one could achieve what I think is now needed as we have hierarchical webs:

• http://my.site.com/Main/MyTopic => ...bin/view/Main/MyTopic
• http://my.site.com/Main/ => ..bin/view/Main/WebHome
• http://my.site.com/MyTopic => ..bin/view/Home/MyTopic
• http://my.site.com/ => ..bin/view/Home/WebHome
• http://my.site.com/WebLevel1/WebLevel2/WebLevel3/MyTopic => ..bin/view/WebLevel1/WebLevel2/WebLevel3/MyTopic

It seems to me that to achieve this, it may require rewrite rules and engine & plugins patches, one need really to have a configuration variable similar to $TWiki::cfg{UsersWebName} in the perl code, as today the UsersWebName is used in the perl both for the user web and the home web, the patch should be done anyways in the perl to change this behavior, not as wiki variables.

I will propose an implementation on 4.2 adding a = $TWiki::cfg{HomeWebName}= to restart the discussion

-- ColasNahaboo - 26 Jan 2008

Ok, you can find my patch on http://koalaz.net/homeweb/v1/ : 2 patches for the code & contents files of TWiki 4.2.0 and the resulting distrib. What I have done is:

• Added a new config var $TWiki::cfg{HomeWebName}
• Replaced in code $TWiki::cfg{UsersWebName} by $TWiki::cfg{HomeWebName} when it was used as a default or root web. Did not replace when used as a Users or Group web
• Added a TML constant %HOMEWEB% variable similar to %USERSWEB% and %MAINWEB%
• We distribute an empty Home web, that should be ignored for upgrades
• added a perl function getHomeWebname similar to getMainWebname
• documentation page VarHOMEWEB.txt created

I will more thourouglty test this in the following days.

-- ColasNahaboo - 26 Jan 2008

I have exported my mercurial branch (starting from 4.2.0) on http://hg.colas.nahaboo.net/twiki-colas/420-homeweb/ You can use it to "branch" it on your disk with mercurial by a:

=hg clone http://hg.colas.nahaboo.net/twiki-colas/420-homeweb/=

-- ColasNahaboo - 27 Jan 2008

Colas.

To help me getting this through a decision process, can you raise a fresh new proposal and put yourself as committed developer?

-- KennethLavrsen - 27 Jan 2008

Whoa! I apologize that this completely feel off my radar. Unfortunately, the decision to move ahead with it happened right at the moment I was moving my family across country. I do not fully follow the implications of Colas' introduction of the $TWiki::cfg{HomeWebName} configuration, but I will be glad to help you Colas anyway I can (documentation, etc). Glad to see this feature picked up!

-- LynnwoodBrown - 28 Jan 2008

Sorry Colas butI restored this old agreed proposal back to rev 24. The topic was developing into a new proposal and RandyScales as well as I got totally confused. It took me 15 minutes before I realized that the original proposal got refactored into the solution that we decided NOT to implement.

With the original proposal there was a concern raised and the discussion ended in a decision made at a release meeting which Peter summarized above.

Please raise NEW PROPOSALS if significant changed are made to an originally decided proposal. Otherwise noone has a chance to discuss it. And the reason for decision, the original commit date etc are important data to fall back to.

Naturally this proposal can be cancelled and replaced by a new. DateOfCommitment is the day you put your name as committed developer. The field is used to start the 14-day clock for auto acceptance. So it is not a day in the future.

-- KennethLavrsen - 31 Jan 2008

Ok Kenneth, I think I understand the problem now better. I think that there are 2 underlying issues really that got mixed up, hence the/my confusion.

1. Deep in the perl engine, there are some Web/Topic names that you can change: WebHome, TWiki, Main, ... settable in bin/configure For performance/stability reasons I guess these cannot be set as TWiki vars (otherwise WebHome would be defined as a TWiki Preferences var?)
2. To help webmaster work, there are (skin-dependent) sets of TWiki vars like WIKITOOLNAME, etc...

I guess Lynwood was thinking of 2 and me of 1. And since 1 gives you 2, I was assuming I could merge the issues. But you are right Kenneth, best is for me to create a new, separate Feature request for 1 and propose that 2 be built upon 1. I will do this in the coming days

-- ColasNahaboo - 31 Jan 2008

Ok, my new proposal is at CreateHomeWebConfigVar

-- ColasNahaboo - 10 Feb 2008

It would seem that this proposal is being replaced by Colas' proposal which is beyond my ability to implement. I'll will offer to help with documentation or something for that proposal. If someone sees something left to implement on this proposal, I'll be glad to do so. If not, what should we do with this topic?

-- LynnwoodBrown - 15 Apr 2008

Thanks for following up on this proposal Lynnwood.

If Colas proposal makes yours redundant then we just park your proposal. If Colas never implements his we can always drive the car out of the garage again.

-- KennethLavrsen - 15 Apr 2008

Yes, Colas' proposal renders this one moot so parking this one is appropriate. If that one stalls, this can be revived and implemented easily.

-- LynnwoodBrown - 16 Apr 2008