Tags:
create new tag
, view all tags
InterfaceThread - FeaturesThread

Big Picture: TWiki Code

Overview: This spontaneous critical look at the overall TWiki code base seems valuable. It's spawned a complementary effort Big Picture: User's View, for admin and end-user issues.

Intro

I'm currentlly browsing the various bin and lib files in order to get the big picture of the TWiki code. While doing so, several Q's popped up ... [they're] to be taken as constructive (LetsMakeTWikiBetter), not to shoot holes in the big work provided. I've taken the liberty to collect them here (in a somewhat structured way).

If a Q gets a long thread, we can always move it to it's own page....

BTW, I'm using the 2001 Aug 25th beta. [ Close to the 01-Sep version; subsequent comments should refer to the latest release ]
→ All comments still apply to the 01-Sep version...

-- HansDonner - 02 Sep 2001


General

  • I was always puzzled as to why we prefix method calls with & - I think that style was deprecated when perl 5 came out. -- Main.MartinCleaver - 03 Sep 2001

Bin scripts

In general

I noticed that a lot of variables are duplicated, like $topic.

  • Why isn't the notation $TWiki::topic used?

  • The bin scripts define a 'main' and call it. This makes it exceptionally awkward to get at the functionality of the body of the script itself from elsewhere, and difficult to write tests.
    I'd really like the bin scripts all to be something like:
          my $query = new CGI;
          &TWiki::do_something_useful($query);
    -- Main.CrawfordCurrie - 03 Sep 2001
    • Using a main function in the bin scripts is merely design I think. However, breaking the main in more descriptive/functional parts would help writing and using test -- Main.HansDonner
    • Moving everything into the TWiki Library is not something I would vote for, better to keep the logic in the bin file. If some parts of the bin scripts could be considered to be used more commonly, it would be good to move it to the library. -- Main.HansDonner
      • Well, reviewing the code, almost everything can be put into the TWiki Library -- Main.HansDonner - 28 Sep 2001

view script

  • view contains some error handling regarding the existence of the view template or the template directory. Why isn't the actual reporting of the error not done in TWiki.pm?
  • Why not check the existence of the requested web before the template is being read?
  • Why not break sub main up into more descriptive parts?
  • Why handle skin here? It seems alread be handled by the also called &TWiki::Store::readTemplate
  • Some rendering is done here. Why not have a separate rendering (or template) library, containing the rendering/template handling functions?

preview script

  • PowerEditAddonDev: _Because of the limitations of Java, I have a server script that acts as the target of all communications from the applet. This perl code is responsible for cacheing the topic text and then invoking 'preview' on the cached text. Obviously I want to re-use the existing 'preview' script code instead of copying it. Because preview is coded so it's only usable as a CGI script (taint checks on, &main, sub main defined, $query = new CGI) the script functionality is not available to another perl script (unless you know better).
    At the moment I am (1) loading 'preview' into a variable (2) using s/// to edit off the bits I don't want (&main() and $query=new CGI) and (3) eval'ing the resulting edited script. ... This is clearly horrible.
    I can think of a couple of better ways to do this, but they require changes to the preview script. For example:
    • Support 'preview' of text held in a cache file (created by TWiki::Store::savePreview)
    • Split the 'preview' script into a 'CGI main' and a 'preview' module (implications for all the other scripts in bin, here)

-- CrawfordCurrie - 29 Sep 2001

TWiki library

TWiki.pm

TWiki::initialize

I saw that almost every bin script starts with:

    my $query= new CGI;

    my $thePathInfo = $query->path_info(); 
    my $theRemoteUser = $query->remote_user();
    my $theTopic = $query->param( 'topic' );
    my $theUrl = $query->url;

    my( $topic, $webName, $scriptUrlPath, $userName ) = 
   &TWiki::initialize( $thePathInfo, $theRemoteUser, $theTopic, $theUrl, $query );

  • Why not let &TWiki::initialize figure out the $the... variables? Or even let $query be generated in TWiki.pm?
    • $query cannot be defined in TWiki.pm, it would lose the params passed to binscript. -- Main.HansDonner - 26 Sep 2001
  • I can imagine why it makes sense to return directly $topic and $wbeName and $userName.
    But why return $scriptUrlPath? See also the section bin scripts - In general...

TWiki::Store

TWiki::Store:lockTopic

In order to unlock a topic the syntax is

   &TWiki::Store::lockTopic( $topic, "on" );

  • Does not seem very logical to me...

-- HansDonner - 02 Sep 2001

Plugins/API & AddOns

.

General Conclusions

>

Edit | Attach | Watch | Print version | History: r13 < r12 < r11 < r10 < r9 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r13 - 2003-12-06 - WillNorris
 
  • 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-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.