Feature Proposal: Add PARENTWEB Macro
Motivation
I'm building an application to manage a software project. I want to to package it in a way that a project can be created just by creating a new web with the proper web template.
This application manages four separate aspects of the project: Defect Tickets, Requirements, Iterations and SCM. To keep things organized, I envisioned the following structure:
 |
_Project (Base web) |
 |
 |
SCM |
|
 |
|
Engine - where all the plumbing topics are (forms, templates, includes to list and create, etc) |
|
|
Tickets |
|
|
|
Engine - where all the plumbing topics are (forms, templates, includes to list and create, etc) |
|
|
Requirements |
|
|
|
Engine - where all the plumbing topics are (forms, templates, includes to list and create, etc) |
|
|
Iterations |
|
|
|
Engine - where all the plumbing topics are (forms, templates, includes to list and create, etc) |
The main issue is that SCM and Iterations must list topics that are in Tickets and Requirements, and Tickets and Requirements must list topics in SCM and Iterations, and I don't want to "harcode" the reference to the subwebs.
Description and Documentation
PARENTWEB -- Parent web of the current web
- For subwebs, the Parent web is obtained by striping the web name, using
/ as the web separator. For example:
- for
ParentWeb/SubWeb , %PARENTWEB% will return ParentWeb
- for
RootWeb/ParentWeb/SubWeb , %PARENTWEB% will return RootWeb/ParentWeb
- For webs at the root level,
%PARENTWEB% will return the empty string
- Syntax:
%PARENTWEB%
- Related: BASETOPIC, INCLUDINGWEB, INCLUDE, WEB
Examples
Using the
%PARENTWEB% tag I can use the following query in the SCM subweb to list all the defects scheduled for a given release:
%DBQUERY{"TopicType='Defect' AND ScheduledFor='%TOPIC%'"
web="%PARENTWEB%/Tickets"
header="%STORYHEADER%"
format="%STORYFORMAT%"
}%
Impact
Implementation
The patch for the code is as follows:
Index: lib/Foswiki.pm
===================================================================
--- lib/Foswiki.pm (revision 5193)
+++ lib/Foswiki.pm (working copy)
@@ -1731,6 +1731,8 @@
# are enclosed in % signs
# SMELL: should collapse these into one. The duplication is pretty
# pointless.
+ # No, they should not. This allows for many levels of includes across webs.
+ # it is kind of a convoluted case, but there is a reason BASEWEB appeared.
$prefs->setInternalPreferences(
BASEWEB => $this->{webName},
BASETOPIC => $this->{topicName},
@@ -2649,14 +2651,21 @@
# push current context
my $memTopic = $this->{prefs}->getPreference('TOPIC');
my $memWeb = $this->{prefs}->getPreference('WEB');
+ my $memParentWeb = $this->{prefs}->getPreference('PARENTWEB');
# Historically this couldn't be called on web objects.
my $webContext = $topicObject->web || $this->{webName};
+ my $parentWebContext='';
+
+ if ($webContext =~ /(.*)\/(.+?)/) {
+ $parentWebContext=$1;
+ }
my $topicContext = $topicObject->topic || $this->{topicName};
$this->{prefs}->setInternalPreferences(
TOPIC => $topicContext,
- WEB => $webContext
+ WEB => $webContext,
+ PARENTWEB => $parentWebContext
);
# Escape ' !%VARIABLE%'
@@ -2678,7 +2687,8 @@
# restore previous context
$this->{prefs}->setInternalPreferences(
TOPIC => $memTopic,
- WEB => $memWeb
+ WEB => $memWeb,
+ PARENTWEB => $memParentWeb
);
}
--
Contributors: RafaelAlvarez - 23 Nov 2009
Discussion
In a hierarchical webs secenario, this makes an awful lot of sense. I encountered exactly the same scenario a couple of weeks ago, and ended up having to use spreadshitplugin to do it.
First point is that I'd like this to work for topics - and maybe even attachments - too. So
PARENTWEB is, I feel, the wrong name: perhaps
CONTAINER might be more accurate. I'd also like to see a bit more flexibility in the macro. For example, a parameter, so I can pass something other than the current topic/web. e.g.
%CONTAINER{%CONTAINER{%CONTAINER{"Sandbox/TestOne/WebHome/logo.gif"}%}%}% should give me
Sandbox. Now I see that, perhaps a
scope parameter to give me the Nth container.
%CONTAINER{"Sandbox/TestOne/WebHome/logo.gif" scope="3"}% > =Sandbox.
--
CrawfordCurrie - 24 Nov 2009
I think that even if
%CONTAINER% is implemented,
%PARENTWEB% should be implemented too, because
%PARENTWEB% is a shortcut to
%CONTAINER{"%WEB%"}%
I put in the table below what I understood from your proposal (and may form the basis for the unit tests)
--
RafaelAlvarez - 24 Nov 2009
You've got it. As you say,
%PARENTWEB% is a shortcut to
%CONTAINER{"%WEB%"}%, so
-
Set PARENTWEB = %CONTAINER{"%WEB%"}%
can easily be added to preferences. Not convinced it should be there by default, though; this is a reasonably esoteric thing to want to do.
Excellent to see you are thinking of unit tests! You might also consider a proof-of-concept by implementing it in a plugin.
--
CrawfordCurrie - 24 Nov 2009
"Container" is the kind of generic word you want to avoid, because it can be anything. Also for end users, "container" is not easier to understand than "parent". What would be wrong with
PARENT?
--
ArthurClemens - 24 Nov 2009
I would just like to add that I also needed this feature (my work-around used
FilterPlugin).
We're really talking about a mechanism to dereference something (or access a property of said thing). It would be nice if we could consider the goals of the
TopicObjectModel (will there ever be such things as a
WebOjectModel - a WOM?
while working on this.
--
PaulHarvey - 25 Nov 2009
I totally agree that
CONTAINER is the wrong word. However the problem with the word
PARENT is that "parent" already means the META:PARENT, an unrelated concept. And I think this is outside the scope of the topic object module - it's a text processing macro that basically says "give me all the text in this string up to the Nth /", which is why I ended up using the spreadshitplugin equivalent of
string->substr(0, string->lastIndex('/')).
File::Spec defines methods to do this sort of thing on filesystem paths. For example,
updir
Returns a string representation of the parent directory.
So maybe %UPWEB would be a better choice.
--
CrawfordCurrie - 25 Nov 2009
I will implement a plugin so we can toy with different proposals and syntax.
Which is the best option to "publish" this kind of "throw away" plugins? Attach it here or put it in subversion without publishing it in Extensions web?
--
RafaelAlvarez - 25 Nov 2009
Attach it here, I would think.
--
CrawfordCurrie - 25 Nov 2009
I would be OK with judging the feature just based on the spec.
And I am OK with proposed feature. I am not religious with the name. PARENTWEB is fine for me.
Good idea to extend spec with scope or level option. CONTAINER is a poor name. The result is a WEB name so it should end with WEB. CONTAINERWEB would be OK. UPWEB also OK.
--
KennethLavrsen - 09 Dec 2009
Since we already use the term
subwebs -- how about naming it
SUPERWEB? (My actual preference order would be
PARENTWEB,
SUPERWEB,
CONTAINERWEB, while I don't really like
UPWEB.)
--
MarkusUeberall - 10 Dec 2009
This proposal has been full of concerns about the name of the macro. And I do not see a consensus yet so I cannot judge it to be accepted.
I have put my own name as concern. And my concern is only that there is no clear agreement on the name.
Rafael the best would be that you pick one of the proposals and suggest this clearly above in the proposal text and then we give people one more chance to disagree.
If noone disagrees - we can pass the proposal.
--
KennethLavrsen - 21 Jan 2010
Follow up. This proposal is waiting for
RafaelAlvarez to refactor the proposal with a macro name that we can get consensus for.
--
KennethLavrsen - 17 Feb 2010
Yesterday a user came by on IRC. He needed to know the parent TOPIC. He used META for this. But META can only show parent of current topic. You cannot give it a topic.
So he wanted a PARENT macro. Now parent web is not the same as the one level higher web. If I have a topic with a parent topic in another web, I would consider that other web the parent web. So I am suddenly in the club of people concerned about the PARENTWEB name. It does not do what I would expect it to do.
--
KennethLavrsen - 22 Feb 2010
and when you add
CleanerSyntaxForMetaDataAccess into the feature mix, you probably don't need to create yet another small syntax element.
--
SvenDowideit - 24 Feb 2010
I have tried to get a reaction from Rafael since January. And he has not pushed it since November 2009.
I interpret this as the developer not committed for the moment.
The QUERY feature should cover the need that triggered this feature, so I see no reason seen from a Customer Advocate perspective to spend more energy on this feature proposal.
The spec is still not frozen so I cannot bring it for community vote.
The only option I see is to park it because we waste developer time having to bring it up again and again as we review proposals.
--
KennethLavrsen - 24 Mar 2010
Legal Imprint Privacy Policy