create new tag
, view all tags

An example of an IndexedThreadedDiscussions

I created this topic using some of the discussion from BeijingRelease to provide a working example of an IndexedThreadedDiscussions. Please ignore the content of the headings I (completely arbitrarily) added to peoples comments. I just wanted to illustrate how comments could have a heading and did not try to accurately reflect your comments.

-- LynnwoodBrown - 08 Aug 2002

Feedback and requests -- PeterThoeny - 04 Dec 2001

Please add below. We need to decide on the strategy, feature set and schedule.

need for better/easier systems administration -- MichaelSparks - 28 Dec 2001

Some comments on the additions I've put above:

  • We tend to use the enhanced definition list format for a number of things - but

one thing it's very useful for is meeting notes - action items, topic headings etc.

  • The need for better/easier systems administration can't be underestimated if

increasing corporate appeal is the goal. Twiki as it stands is too "code hands

on" for systems administration of a Twiki server. The installer I've written

simplifies this rather dramatically to the extent that simplifies the case where

someone is performing authentication using LDAP is simply a matter of answering

a few simple questions.

  • People who want to put lots of attachments on a TWiki server - eg exported

powerpoint presentations - photos from a party - customer supplied archives/files

tend to find the uploading one file at a time laborious. Zip files make life

a lot simpler - but mean you have to download stuff to read it - which slows

things down, and prevents instant access.

We also use a modified TWiki syntax for headings that's much more email like - which

simplifies pasting emails & summarising emails into a TWiki page. Specifically something

more like:

_*Centred Level 1 Heading*_

__Level 1 Heading__

_Level 2 Heading_

*Level 3 Heading*

This does overload the twiki operators again though, and I'd prefer to put these into

a plugin - but then this'd need EnhancedPluginHandling. (Something which is definitely a

better route to go down than continually extending the core.)

Work-flow handling -- JohnRouillard - 01 Jan 2002

I think one thing needed for broad corporate appeal is the ability

to provide some form of workflow handling. I would like to see the ability for:

  • controlling access lists by changing a form (requires processing the form prior to scanning for access lists).

  • ability of plugins to access changes to forms and validate

these changes

  • mechanism for returning the value of a piece of field metadata.

% META% should probably be extended so that % META{"ProcessStage" type="Field"} will return the value of the ProcessStage field item.

I have a particular requirement for approval process support

under TWiki.

Fix rename bug -- JohnRouillard - 01 Jan 2002

Also it would be nice to fix the bug with rename of a page

causing all pages linked to the renamed page to be

marked as changed. This is discussed in DevOpinionPoll.

Include RefreshEditPage -- RichardDonkin - 04 Jan 2002

I really would like to see RefreshEditPage included (i.e. fixing the 'second edit in session loses first edit's changes' problem), even if as a configurable option - I ran into this issue when training a new user with IE5 (which usually doesn't have this) and it's quite disconcerting. It should really be the default, so that TWiki works correctly with browsers such as Mozilla and Opera, not just IE5/6 - currently TWiki is barely usable with Opera because you need to hit Refresh all the time when editing a page. I have tested this patch with various browsers and it works fine.

How about VariableForCategoryDropdown as well -- PeterMasiar - 13 Jan 2002

Is it possible to include VariableForCategoryDropdown to facilitate development of more dynamic search pages? AdrianLynch attached plugin for rewiew in VariableForCategoryDropdown topic. Thanks!

I'll take a look at VariableForCategoryDropdown -- JohnTalintyre - 14 Jan 2002

I'm happy to take a look at VariableForCategoryDropdown and generally at the space of making more use of the TWikiForm system. More shortly.

TWikiForm as a bulleted list? -- RandyKramer - 15 Jan 2002


I'm trying to puzzle out how to display the entries in a TWikiForm as a bulleted list instead of a table. (Not very actively, yet -- and perhaps someone has already told me that it is possible and how to do it -- I just haven't (re)found it.) If it is not possible, I would appreciate it if you could make modifications to allow it.


Include DefineUserTopicBeforeRegistration and FileSystemNameClash -- SvenDowideit - 15 Jan 2002

do you want to put in the changes from DefineUserTopicBeforeRegistration and FileSystemNameClash ?

How about MultipleAttachmentsAtOnce -- VitoMiliano - 15 Jan 2002

I noticed MichaelSparks' post from late December commenting about the need for better attachment handling. Is this a good place to plug our MultipleAttachmentsAtOnce post, which allows you upload a .zip file full of attachments, which then get unzipped and added as individual items? smile

We'd love it for it to go into the main codebase. Code's all there, just need someone to tell us how best to turn it over to your guys. Thanks!

BackFromPreviewLosesText in 'nice to have' -- RichardDonkin - 19 Jan 2002

Since I now have a good fix for BackFromPreviewLosesText, I've added it to the above 'nice to have' table - see that page for details. The fix is quite simple, it just sets some extra HTTP headers for the Edit page, solving the problem quite cleanly and thereby avoiding loss of edits. I'd appreciate it if the CoreTeam could review this for inclusion in the BeijingRelease. It depends on the RefreshEditPage changes to work well, but the code is separate.

Revisit MorePluginHooks issue -- MichaelSparks - 03 Feb 2002

Going back to the whole MorePluginHooks issue - I've revamped that page with a few requests, and a simple

mechanism documenting what we have, what's been proposed, and why, whether they're accepted or rejected.

Specifically also the BackFromPreviewLosesText details a problem that's essentially solved by adding extra headers

to do with last mod/expiry - but these can be changed based on included content - which is what the extra

preIncludeHandler hook is designed to help with. The nice side effect of this though is that this enables the "core code fix" to go into a plugin. The flip side to the same thing is at: LastModifiedFieldOfHttpHeader . I've got one

small core diff to add in though for the hook.

The other nice thing this approach allows is for debugging of the system to be done through HTTP headers - the sample plugin for example dumps the last modified header & an X-TWiki-Date header so that we can compare & contrast whether the "correct" last modified header is getting dumped.

Combined with the TopicVarsPlugin this gives all sorts of fun possibilities...

No plugins for browser bugs! -- RichardDonkin - 05 Feb 2002

I'm all for using plugins to add extra headers not needed by most installations, but the BackFromPreviewLosesText problem relates to IE5/IE6, which are by far the most common web browsers on intranets (even though MozillaBrowser works well) - IMO, TWiki should not require installing a plugin to work around this common browser bug. Perhaps there could be some core code to add the headers required for Edit, while a separate plugin does something similar to improve cacheability for View etc? Given that proxy caches are quite common on large intranets and have caused problems for TWiki users in the past (see SavePreviewTextOnServer and BrowserAndProxyCacheControl), it would seem reasonable to add the View cacheability headers to the core code as well, but that's a judgment call really.

Interest in SimplerTWikiDistribution -- DougPhilips - 04 Feb 2002

Any interest in any of the stuff on SimplerTWikiDistribution this time around?

I was thinking that the testenv script, which is tres cool, could actually relock the pages, since that really is a "setup time" thing and not a "ongoing maintenance" thing.

Corporate appeal and appeal for BeijingRelease -- PeterMasiar - 27 Feb 2002

to Add corporate appeal

Since goal of this release is to give TWiki broad corporate appeal, let's check if we can do first something called in managerspeak easy winner:

  • excellent CommentPlugin simplifies user contribution and lowers entry barrier to 0

  • we have patch for create UserWeb for users, cleaning Main (or Hone) web

So I think we have enough nice simple features, and one important bug fix to warrant new release - easy winner. I understand you guys wound like to have better Plugin features and what not, but why postpone new version for that?

One additional feature what I would like to see for broad corporate appeal is ApprovingRegistrations, and maybe ScriptToCreateNewWeb. But even without that, what we already have, TWiki deserves new release.

Do not forget we need to agree on SimplerDefaultTemplates and then modify documentation (WelcomeGuest etc) accordingly. So this release will need broad changes in documentation (= time), while Plugin changes are more transparent for newbie.

Can I ask (beg) CoreTeam to add possibly some ready patches, and roll out BeijingRelease? Pretty please?

Who is with me? We want BeijingRelease!

Feature creep -- RichardDonkin - 27 Feb 2002

I agree about a simpler TWiki distribution and with many of the feature requested, although of course feature creep is always an issue... It does seem to be hard to get the many great TWikiPatches into the distribution, even when they are very localised bugfixes for data loss bugs such as RefreshEditPage and BackFromPreviewLosesText - however I'm not on CVS so for all I know they've been fixed on the email list... Presumably the CoreTeam are just very busy?

I've also just written the WindowsInstallCookbook, ported testenv to ActivePerl and got it to provide more info (see CookbookActivePerlTestenv), and fixed a long standing bug with path_info in CobaltRaqInstall (applies to hosted environments as well, where they use cgiwrap, and to IIS). So I'm not just complaining, honest smile

Would it help if I volunteer to work on some of these bugs, and on putting WindowsInstallCookbook into the documentation set under the TWiki web? Or would I need to be a CoreTeam person?

added WindowsInstallCookbook -- RichardDonkin - 03 Mar 2002

I've added WindowsInstallCookbook to the above since it's been tested successfully by three people and works well. Note that it also includes a patch to register that should be applied to BeijingRelease, since register currently doesn't work on Windows (as mentioned near end of AuthenticationProblem) - see step 5 within WindowsInstallCookbook#Editing_the_CGI_scripts.

I've also added:

  • CookbookActivePerlTestenv - the attached testenv now works well on Windows (ActivePerl and CygWin) and Linux/Unix, across various Perl versions. It also tests for path_info problems, checks whether ModPerl is being used, provides better Perl version info, checks the RCS version on Cygwin, and correctly tests for ci.exe etc on Windows.

  • CobaltRaqInstall - the fix here will help in various hosted environments that use cgiwrap, as well as in IIS where the path_info is messed up.

It would also be good to review TWikiPatches for relevant bug fixes - some are very simple to include.

corporate appeal__ but without compromising the stability -- PeterThoeny - 08 Mar 2002

Sorry, very busy lately, could not spend as much time as I wanted on TWiki.

Schedule is not fixed yet, but we have around two releases per year. We could shorten the schedule with less features, or put in more enhancements with longer schedule. Opinions?

This release should give broad corporate appeal but without compromising the stability. So, we should not make major code changes unless tested extensively. The only major code change is RcsLite. John, shall we include it / drop it from this release, or decide later?

Release schedule and frequency -- DavidLeBlanc - 08 Mar 2002

Re: Release frequency. I think it would be nice to have a "2 major, 2 minor" annual release cycle. Sometimes it's hard to find intrim patches or to know if they're necessary or what. My idea would be to have the spring and fall releases be major (and fall more major then spring - see below) and the summer and winter releases be minor. The reason for having the fall release more major then the spring major release is in consideration of how people work: they're settling down in front of their computers for the cold months (ok, N. Hemisphere-centric), and have/will want to spend more time doing TWiki things.

I would also suggest naming them as "TwikiSummer2002", "TwikiFall2002" (for example) and using the solistics and equinoxes as target dates so one doesn't have the weird situation of the 1 Dec 2001 release coming on the 12th or whatever it actually was smile

Agreed: more releases -- VitoMiliano - 08 Mar 2002

Yeah, more releases would be nice. Also, I tidied up the table a bit. Someone broke it.

Core team overstretched? -- MartinCleaver - 09 Jul 2002

On 27 Feb 2002, PeterMasiar said:

But even without that, what we already have, TWiki deserves new release.

Can I ask (beg) CoreTeam to add possibly some ready patches, and roll out BeijingRelease?Pretty please? Who is with me? We want BeijingRelease!

At two releases per year, we are going to make the other one hard work at this rate. smile

Perhaps the core team is overstretched? Maybe it is time to introduce a shared responsibility for releases? CoreTeam - if people offered to take this responsibility, would you accept? What would the work entail, is the process documented and how much effort would you reckon for this release?

Where are you CoreTeam? -- MaximRomashchenko - 11 Jul 2002

ALERT! We want BeijingRelease too! CoreTeam, where are you?

We're here! -- PeterThoeny - 12 Jul 2002

Don't worry, we are here smile , just very busy and can't spend hours a day on TWiki wink

I am currently certainly very busy with other stuff, but try to keep up as good as I can.

Best chance to get enhancement requests included in the code is by submitting tested code. TWiki has a high quality standard, the core team cannot take any code just like that into the core.

Yes, it is time for the BeijingRelease. We might need to skip some features to speed up the process. What needs to be in is SimplerDefaultTemplates, EnhancedSkinHandling and a a little EnhancedPluginHandling.

SimplerDefaultTemplates will be excellent! -- PeterMasiar - 12 Jul 2002

To have SimplerDefaultTemplates will be excellent! Many newcomers (like me smile ) also complain that topic should be renamed to page and web to anything, like maybe zone (RenameWebToZone). IMHO it may increase appeal and help to get buy-in. It might be good time to settle page/topic and web/zone issue now, because we (I can volunteer time for it now) will need to review all docs and refer to action links on new, simpler templates. It looks to me that CoreTeam is reluctant to get involved into this discussion?

Release soon, drop features -- DarrylGreen - 17 Jul 2002

All this focus on appearance (SimplerDefaultTemplates, EnhancedSkinHandling) doesn't seem (that) important to at least 1 user. I'm having problems getting serious uptake of twiki as a part of our systems (more than getting users to enter content) by being able to confidently say - yep, I can do that on the wiki. "Do that" usually means to do something a bit more sophisticated re. content organisation that a free-form wiki. To do this SearchWithAnd and FormattedSearchWithNesting are essential. Treat this as a (completely selfish smile )vote for release soon - drop features.

How about a Beta release? -- JohnRouillard - 29 Jul 2002

Rather than getting BeijingRelease out the door, maybe a new Beta could be released. The reason

I am asking is that there have been changes (well at least one change, ConfigurableLogo

add RenameTestWebToSandboxWeb to the list --JohnRouillard 30Jul2002)

to TWiki in TWikiAlphaRelease

that needs corresponding changes in the TWiki web and pub files. I have been trying to track

all the changes and pull them from twiki.org, but my new twiki still isn't configured quite right.

Alternatively, is there someway to get the files in pub and TWiki web that correspond

to the current TWikiAlphaRelease?

Sounds good -- MartinCleaver - 1 Aug 2002

We need to name the next two releases and push back any features that we know for definite are not going to be in BeijingRelease. It's August here in Kuala Lumpur.

Code name for upcoming releases -- PeterThoeny - 02 Aug 2002

OK, lets decide on the code name for the upcoming releases: See Vote in CoffeeBreak#CodeNamesAfterBeijingRelease.

Also, it is time for the next Beta release. RichardDonkin, do you have time to finish up SettingLibPath before I create the next Beta?

How soon next beta release? -- ZeljkoBlace - 03 Aug 2002

How far is to to next BETA? I would like to install TWiki on my mm-void.sf.net tommorow

(including some of the plugins for DMOZ and discussions),

but I can wait an extra week if this would give me some of the new features.

Peter any esstimates???

SettingLibPath is now in CVS -- RichardDonkin - 03 Aug 2002

SettingLibPath is now in CVS - seems to work for the testing that I've done, but since the code is the same for all scripts it shouldn't cause problems. The view script on donkin.org has been using it for months anyway ...

Edit | Attach | Watch | Print version | History: r5 < r4 < r3 < r2 < r1 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r5 - 2008-08-23 - TWikiJanitor
  • 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-2018 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.