Tags:
create new tag
, view all tags

Questions on Changes in DevelopBranch

This topic gives a forum for asking (and, hopefully, getting answers to questions regarding requirements changes, code changes, etc., in DevelopBranch with respect to the Cairo release.

In case of doubt, unless explicitly documented differently in DakarReleaseNotes DevelopBranch should behave identically to Cairo.

This topic is organized by files.

Note: These questions are not fix requests, but information questions to allow developers to know whether changes have been made on purpose or inadvertently.

bin/viewauth

  1. Q. Several places reference bin/viewauth, but this file is not present on DevelopBranch.
    • A. so as to avoid checking in duplicated code, and all of the maintainence nighmare of keeping them in sync, build-twiki-kernel.pl creates auth versions of view and diff. are there others as well?
foreach my $auth qw( rdiff view )
{
    cp( $_ = "$installBase/bin/$auth", "${_}auth" ) or warn "$auth: $!";
}
  1. Q. Does this mean one needs to run build-twiki-kernel.pl when installing Dakar? Is this process documented somewhere?
    • A. no, you definitely don't need to run build-twiki-kernel.pl (which automates the build release process) when installing Dakar. this isn't a difference in Dakar, but instead a difference from checking out the source code vs. downloading a "released" tarball (see http://develop.twiki.org/users/develop/pub/BuildDistros/ for DevelopBranch tarballs). this hasn't changed (CVS doesn't have the auth versions checked in either), although at least you get the webs data in AlphaReleases now wink

lib/TWiki/Form.pm

  1. Q. The name of formfields is now identical to the title of the formfield, while in Cairo only the characters A-Za-z0-9_\. were used for the name. Many operations are keyed of the name, so no existing form data will work on DevelopBranch. --TW
    • A. OK, reverted to Cairo behaviour. --CC
  2. Q. Text cannot any longer be initialized from query parameter text . --TW
    • A. OK, it should work as expected now. If not, please give me a testcase (at the minimum, a URL and an expected outcome)
  3. Q. Possible values for fields could be defined as a comma-separated list of values. This has changed to [,\s]+ with the effect that when the empty value is not the leading value, it will not initialize a field to the empty value. --TW
    • A. Good point - fixed it
  4. Q. Initial values for fields are not any longer taken from the form definition for radio and select fields. --TW
    • A. For select fields, the first possible value is always the default. For radios, the value field defines all possible radio buttons; what should the initial values be? Or do you mean it isn't picking up any values?
    • The line $type !~ /^(checkbox|radio|select)/ ) { should be changed to $type !~ /^checkbox/ ) { Have Fix
    • Are you sure? - can you explain the logic please? Giving defaults to radio and select seems strange given that they are single value, and will always default to the first.
    • Trust me, your change broke the initialization. If you don't do this, you get an empty value there.
  5. Q. The select fields does not work any more after deleting leading and trailing white space from the possible field values was taken out of the code. Have Fix
    • A.
  6. Q. When rendering form, there is no more div around it with style twikiform resulting in that a table box is drawn around the form. I think the older version looked better. Have Fix
    • A.

-- ThomasWeigert - 24 Apr 2005

Sorry, Crawford, I forgot to mention that I already had all the fixes implemented in my version... I just wanted to know the answers so I knew whether there was an intentional change...

-- ThomasWeigert - 25 Apr 2005

Plugins

  1. Q. In order to convert plugins to the Dakar style, could you please explain the decision process as to what plugin code goes into the plugin pm file, and what goes into the plugin/Core.pm file? There seem to be a lot of extra files in Dakar...
    • A. It's based on what must be compiled versus what can be compiled when the plugin is actually required. i.e. anything you don't need to compile until a EDITPREFERENCES tag is actually encountered can be in the Core.pm. The core.pm should be lazy-included using require and not use so it is only compiled when needed. -- CrawfordCurrie - 09 May 2005

Edit | Attach | Watch | Print version | History: r15 < r14 < r13 < r12 < r11 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r15 - 2005-06-21 - SvenDowideit
 
  • 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.