EmptyPageText

The text that is displayed when a non-existent page is browsed

Ideally, should come in two flavours:

• edit
• display

See OpenNewText for a patch.

The text is currently hard-coded. An improvement would be to make it openly editable, with the text stored in, say

• "Empty Page/Edit?"
• "Empty Page/Display?"
• the page "Empty Page" can explain the system to the user

---

it strikes me that we're defining more and more "special" pages. The base UseModWiki script has for ex, $RCName as a config variable.

How about we streamline this into a hash:

%SpecialPage? = ( Recent => 'RecentChanges' , EmptyEdit? => 'Empty Page/Edit?' ...)

having thought that, how does / can this tie in with MagicPages?

WikiPatches/MagicPages currently calls a module, which calls a package within itself if there's a match with the page title. Keeping magic page scripts in a module strikes me as a good thing. But what if we had:

%SpecialPage? = ( Recent => 'RecentChanges' , EmptyEdit? => 'Empty Page/Edit?' , Wanted => 'Wanted Pages' ...)

with this construction, "Wanted" is the name of the package to call in the module -- that resolves discrepancies between the magic script's package name and the page name. Or is this a bad construction, because data is flowing in TWO ways in this hash? ie:

1. I want a link to the Recent changes page... what is the page name? look up the value of key 'Recent'
2. Is the page I am about to display magic? does one of the values of this hash match my current page name?

Of course, that would lose us the "niceness" of wikihosts being able to "drop in" script into the Magic pages module without editing the main script...

Thoughts from perl gurus? -- tarquin

There are two parts to this. The first part is how the script internally manages global variables. The second part is how the user externally loads the magic pages. With some work, you can do both at the same time.

Here's some pseudocode, to be implemented in MeatBall:InfiniteMonkey.

Launching a module

1. Ask CGI what the action= parameter is. If there is no action parameter, assume it's browse.
2. Check to see the module for that action is loaded.
   1. If it isn't, require the module.
   2. If the module fails to load, fail.
3. Initialize script.
4. Execute the action.

Module initialization

Once a module loads, Perl executes all the top-level code (i.e. not wrapped in a subroutine). This means you can write module initialization in the top-level. So, ...

1. Add associations "MagicPage => action" onto global %MagicPages? hash.
2. Set other global variables.

Browse page

1. Check if page to browse is in MagicPage
   1. If so, return to Launching a module but now with the action being the MagicPage action.
2. Load and display page.

end of pseudocode

Now, a similar strategy could be used to acquire the name of RecentChanges. Right now, Infinite Monkey uses a global parameter $Parameter{RecentChanges} to get the name, although that parameter is set by the RecentChanges module. That's not very elegant, as a better answer might be to ask the RecentChanges module (e.g. &UseMod::RecentChanges::id). However, suppose we wanted to move the RecentChanges package to a separate file. Maybe we could similarly dynamically autoload RecentChanges when we want to query it. I'll have to think about it some more. Dynamic loading is not easy, and it may not be worth it. -- SunirShah

That all is massive overkill for the EmptyPageText feature. Let's focus on that -- it merely requires that the script loads its default text from either of the configured pages when the requested page doesn't exist. (That's also different from MagicPages? in that those are Wiki pages plus generated content, whereas EmptyPageText's special pages just serve as a storage location for Wiki text -- like Unreal:Wiki_Sidebar.) -- MichaelBuschbeck

While I was away I saw the simple solution to my question: the MagicPages? module has its own packages register themselves; it stores data in an array. Simply have the registration procedure store information by adding data to the UseMod package's SpecialPage? hash! baboom! Mych is right, these are two different concepts: pages where content is generated vs. pages whose content is read by something else. But there is a core common feature: the script must know this page by a name, ed "Wanted". But the site host may wish to choose another name. On the other hand, the whole point of the registering function is that the data list can be searched and the script can say "aha! yes, there IS a magic page module for this page I am on! Let's run it!". If the data hash also contains info about non-magic pages, we need to store more data:

1. internal name (and name of a module if magic)
2. is it magic?
3. page name

It's a trade-off: extra data storage vs. unified structure.