incubator-jspwiki-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bob Paige" <>
Subject Re: creating new pages
Date Wed, 18 Jun 2008 01:15:49 GMT

Well spoken response.

In my workplace we have many projects (say, 15) with one or two new ones
added each year. They are all similar, though the implementations vary
(different back-ends, etc.) and all are actively maintained. Thus, I foresee
new pages being added at a slow but steady pace, and existing ones
continuously refined.

Since my user-base is not especially inclined to writing documentation, I
want to make this all as automatic as possible. Thus, I feel that things
like tags and namespaces can go a long way to automating the linking
process. JSPWiki provides good search capability, so I am not as concerned
about 'lost islands of pages'.

I imagine the usage would work something like this:
1. there is a one page that lists all active projects as links to those
project pages
2. on each project page (in addition to text describing the scope and
audience of the project) are lists of links to related documentation. This
includes marketing analysis/description and technical implementation.
2a. alternately the project page consists of a list of major project
features with analysis/description/implementation broken down by feature
(I'm not sure which structure will win out, so I may just leave it open for
the users to decide)
3. each feature/implementation page will have some tag on it identifying the
feature, to facilitate comparison of similar features in other projects.

I see the implementation something like this:
1. the ProjectList page uses the WikiTags plugin to display all pages tagged
as a project
2. each project page uses the Namespaces plugin to list pages related to it
2a. similar-feature pages can have similar names in the namespace, i.e.
Project1.login, Project2.login, etc..
3. key details of each page could be tagged, i.e. DatabaseAccess,
Encryption, etc. for cross references

Once the ProjectList page is created, new projects are added by creating new
pages (see #1), rather than everyone editing and re-editing the ProjectList
page. Same for pages related to the project; you name it appropriately (for
the Namespaces plugin) and it "magically appears" in the right places.

Do you see where I am coming from?

The next step would be to provide templates for certain types of pages so
they have similar structure.


On Tue, Jun 17, 2008 at 5:43 PM, Murray Altheim <>

> Bob Paige wrote:
>> I have been playing with the Namespaces plugin and the WikiTags plugins,
>> and
>> have a question: how can I provide an easy way for my users to create new
>> pages?
> Yes, certainly. Any plugin that creates a link like
> (i.e., with "Edit.jsp" in the URL) creates a link to a new page. It's
> also possible to code a plugin to create a page programmatically (it's
> relatively easy). I have a plugin that pops up a dialog box, asks for
> a new page name, and generates a page. But it's not a solution to a
> common user scenario (or at least one in my idealistic wiki mode that
> I agree with).
>  The scenario is this: using tags and namespaces, I want to set up a
>> hierarchy of pages within my wiki (this is for technical documentation).
>> These plugins automatically insert links between pages, so it is unlikely
>> users will be defining links to non-existent pages and clicking on them to
>> create the pages.
>> I tried some embeded javascript (which naturally gets filtered out). Is
>> there some plugin or some other workflow thing that I am missing? How do
>> your users typically create new pages in your wiki?
> I think the answer to that last question is that they do it traditionally,
> by creating a link to a page and then clicking on it. This has the
> disadvantage of making it more difficult than say, Microsoft Word, in
> that there's no "New Document" button. People are forced to think about
> how a new page links into the corpus of pages, i.e., where they're going
> to place that link. Some people think that requirement is artificial,
> others essential. I've on occasion had to explain *why* wikis don't have
> that button to people. The advantage is that one's wiki is less likely to
> develop islands of disconnected pages. With good search tools this isn't
> such a problem as on early wikis.
> I've spent the last few years working on tools to assist in creating
> structure among wiki pages, most of it in the form of tags or assertions,
> the latter providing the ability to create hierarchies when the predicate
> used is by nature hierarchical or at least transitive.
> But I think it would be helpful if you were to further flesh out what
> you're looking for. Do you want people to actually create pages, or just
> links to pages? Do you want to make it easy to create a *lot* of pages via
> program control, with all the potential dangers that incurs? Generate a
> set of pages or links to pages based on a preexisting structure provided
> to a plugin? etc.  How are you thinking the structures would be
> represented? in wiki text?
> I'm curious as to how you envisage the automation of either link or page
> creation, as that can be approached in so many ways. E.g., one could
> provide some form of structured TOC and autogenerate all the pages for
> that TOC, with links (up, down, previous and next) on the autogenerated
> pages. That's certainly doable. But it also is potentially rather
> complicated for users and potentially dangerous (e.g., allowing a single
> user to create hundreds of pages with a single command invites abuse).
> Murray
> ...........................................................................
> Murray Altheim <murray07 at>                           ===  =
> =
>                                     = =
>  ===
> SGML Grease Monkey, Banjo Player, Wantanabe Zen Monk               = =  = =
>      Boundless wind and moon - the eye within eyes,
>      Inexhaustible heaven and earth - the light beyond light,
>      The willow dark, the flower bright - ten thousand houses,
>      Knock at any door - there's one who will respond.
>                                      -- The Blue Cliff Record

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message