Development

This page serves as the hub for discussing ISFDB-related software development. Related resources include:

• the Sourceforge discussion
• the Sourceforge tickets
  • the bugs (obsolete ISFDB Bug List)
  • the feature requests (obsolete ISFDB Feature List)
• ISFDB:Proposed Design Changes‎
• ISFDB:Proposed Interface Changes
• Recent Patch list
• Fixer's Talk page (for Fixer-related issues)
• ISFDB Design Documentation (old)
• ISFDB Downloads (contains links to the installation instructions)
• ISFDB Build Process (explanation of the build/install process)
• ISFDB Page Map — a list of which pages link to which other pages

Developers and Testers

• MartyD — developer
• BLongley — developer
• Kpulliam — developer (of meager ability) / Tester
• Roglo — developer (inactive since mid-2009)
• Ahasuerus — developer, tester and installer/administrator
• Alvonruff — currently unavailable, but has full development and administrative access
• Marc Kupper — has full administrative access and a partial development setup
• JesseW — developer
• Uzume — developer, tester, etc.

The following editors are currently in the process of setting up a local copy of the application:

• Swfritter

Software Development Process

At this time the development process works as follows:

• A Bug or Feature Request ("FR") is created in SourceForge. Anyone can do it, even "anonymous".
• FRs should be discussed on the Community Portal and approved by the community before the work begins. Obvious bugs can be fixed and submitted without a prior discussion.
• Once a developer decides to work on a Bug/FR, he identifies the scripts that are affected and lists the Bug/FR along with the scripts on the Development page under "Outstanding Changes". This helps avoid effort duplication.
• The developer makes changes on his development server and tests them. He then checks the updated modules into SourceForge and adds the new version numbers to the "Outstanding Changes" table.
• The administrator (Ahasuerus in 2009–2013) downloads the changes to his local development server and tests them. In some cases the administrator asks another developer to test the changes.
• If everything works fine, the administrator uses the CVS "tag" command to tag the script(s) that will go into the next build, e.g., "cvs tag r2010-80 script.py". Usually a build includes one or two changes, although occasionally the number is higher. Builds follow the 2010-NN naming convention.
• The administrator signs on to the live server and uses the CVS "export" command to download all scripts for the latest build/tag to a new directory, e.g., "cvs export -r r2010-80 -d r2010-80 isfdb2"
• The administrator tar's the directory up, e.g., "tar -cvf r2010-80.tar *", copies the tarball to /home/avonruff/isfdb2/, untars it and types "make install" (or "make -B install" if the build added new scripts or otherwise requires a complete rebuild.)
• The administrator gzips the tarball and moves it to the archive area.
• The administrator marks the Bug(s)/FR(s) as "Fixed/Completed" in SourceForge.
• The administrator moves the completed change(s) from the list of Outstanding Changes on the Development page to the "Recent Patches" sub-page. "Recent Changes" covers all builds for the current year, so it's a useful page for developers to review.

Changes and Patches

Recent Patches

Patch Archive for previous years

See Development/Recent Patches for the list of changes implemented in 2013.

Outstanding changes

Bug or Feature	Description	Modules and versions	Developer	Tester	Date Passed	Patch
Bug 379	Main search logic doesn't handle submission with invalid "type" argument	biblio/se.py 1.23	Ahasuerus	Ahasuerus	2013-12-22
Bug 380	Make variant doesn't escape some form values at submission creation time	edit/submitmkvar2.py 1.12	Ahasuerus	Ahasuerus	2013-12-22
Bug 381	The process of parsing Title-related input doesn't check that the title ID is an integer	common/titleClass.py 1.12	Ahasuerus	Ahasuerus	2013-12-22
Bug 385	Publication Listing doesn't display the nav bar if no parameters are passed to it	biblio/pl.py 1.62	Ahasuerus	Ahasuerus	2013-12-23
Bug 386	Most-viewed authors page errors out if no parameters are passed	biblio/most_viewed.py 1.4	Ahasuerus	Ahasuerus	2013-12-23

Planned changes

Bug or Feature	Description	Modules and versions	Developer	Tester	Date Passed	Patch
Bug 3183863	Static and dynamic content cannot be "rehomed" correctly	TBD	Uzume

Current Activity

JesseW

Rename the three PrintNavBar's to distinguish them

See FR 3115118. It'd be very easy, but I want some feedback before I do it. JesseW 05:58, 22 November 2010 (UTC)

Clarify the license

See Bug 3115153; it's not good that the actual files make no mention of the license the code is released under. JesseW 07:09, 22 November 2010 (UTC)

Kevin

Change Clone and Edit 'Submit' Buttons

Change the text in the Clone Submit and the Edit Submit button to be clear to the editor which is being submitted. Discuss at ISFDB:Proposed Interface Changes#Change Clone and Edit 'Submit' Buttons

MartyD

Concentrating on bugs, clean-up/consolidation, and small features. If anything ever comes of the tagging discussion at ISFDB:Community Portal#Title type tags in bibliography display, I will revisit the tagging used, too.

Tips and Tricks

General Principles

The ISFDB code base is over 1.5MB in size and has a number of dependencies, which are not always obvious. For example, the JavaScript generator affects dozens of Web pages and even a simple change may have unexpected side effects. For this reason, developers should follow the "if it ain't broken, don't fix it" principle. Developers should also try to address one problem at a time. If a feature or a bug fix requires mass changes, discuss it with other developers and the administrator first.

Coding style

Among the developers, there is a wide variety of backgrounds and levels of Python experience. Due to this, it's important to take care to keep the code understandable without a high level of Python-specific knowledge. Using basic structured programming constructs (i.e., def, if, while, etc.) and simple classes rather than heavy object-orientation or more esoteric functional programming tricks is recommended. If you need to create a complex class, method or functions, you may want to discuss it with other developers and the administrator first and then document the code thoroughly.

Where is db defined?

Whenever SQLparsing.py is imported, a database connection is created, and assigned to the variable db. SQLparsing.py is copied by the makefiles from common/ into all the other directories, and imported by more or less everything, often multiple times. This is may be suboptimal.

Code Format

• The code appears to use 'TAB' instead of 'SPACE SPACE SPACE SPACE' to indent the code. (Some online python tutorials indicate a preference for one or the other.) You should use TABS for this project to indent because Python uses the indent level to define code blocks and sub steps. Mixing tabs and spaces in a File/project can cause the compiler to misunderstand where the functions and loops start and stop.
• In other ways the code should probably adhere to PEP 8: Style Guide for Python Code

Duplicate Functions and Duplicate Filenames

WARNING — There are duplicate file names and duplicate functions. The function PrintNavBar for instance, appears in /biblio/common.py (with 5 arguments) and in /edit/isfdblib.py (with 2 arguments) and again in /mod/isfdblib.py (with no arguments). Be sure to watch your directory of the file you are editing, and you cannot count on a function in one directory behaving the same when working in another directory.

Indeed. When looking for "SQLwikiLinkExists" it turns out we have five of them, and rather too many "SQLparsing.py" files. We could do with some comparisons and centralisation, although this obviously has possibly far-ranging effects and would need lots of regression testing. BLongley

Files living in common are master files and are copied to the other parts of the tree during the build process. The good news is, CVS won't let you commit the others, as they don't actually exist in those directories in CVS. TortoiseCVS distinguishes them as local files with a different icon.... —MartyD 20:48, 14 June 2009 (UTC)

This isn't a case of common files. This is duplicate file and function naming. Kevin 03:25, 15 June 2009 (UTC)

I have begun the first step in the journey to fixing the PrintNavBar duplication problem. I've created a new common/navbar.py and made all of the other directories share it. We can slowly move NavBar things into it. —MartyD 21:14, 5 July 2009 (UTC)

Related Projects

• Solr Powered ISFDB