Skip to content

Historic: OldStart (documenting the original datatracker conversion)

Robert Sparks edited this page May 1, 2023 · 1 revision

PageOutline(2-3)

Replacing IETF web pages with django

For information about checking out code, running a local server, keeping track of work status etc., see ProjectSetup.

Phase 1

Replace all no-authentication-required tools. This is the set of tools in the PublicWebTools subdirectory of the scripts dump.

Wiki Page Milestone
InternetDraftDatabase [milestone:InternetDraftDatabase]
PublicDraftTracker [milestone:PublicDraftTracker]
LiaisonTool [milestone:LiaisonTool]
PublicMisc [milestone:PublicMisc]
MeetingAgenda [milestone:MeetingAgenda]
PublicProceedings [milestone:PublicProceedings]
IPRTool [milestone:IPRTool]
IESGAnnouncements [milestone:IESGAnnouncements]
MailingListManagement [milestone:MailingListManagement]
Redirects Redirects

Django infrastructure:

Python infrastructure:

Testing

Various testing support mechanisms are available, such as support for Python unit-tests, automatic UrlTest support, BuildBot support, and more. See the Testing page.

Status

See the [../roadmap Roadmap page] and the TaskSummary.

Live Development Sites

Bill's Server: compost (dev server) compost (fastcgi server)

Henrik's Server: merlot

NeuStar Server: natasha

Sending Email

  • The tool will send email to test-place when it's in testing/development and real-place when it's real

See Email.

Public tools that send email:

  • ipr.cgi: send_mail("ipr.cgi","IPR USER",$TO,$FROM,$SUBJECT,$email_body2,$CC); #DEPLOY - UNcomment
  • ipr_generic.cgi: send_mail("ipr_generic.cgi","IPR USER",$TO,$FROM,$SUBJECT,$email_body2,$CC); #DEPLOY - UNcomment
  • ipr_notify.cgi: send_mail("ipr_notify.cgi","IPR USER",$TO,$FROM,$SUBJECT,$email_body2,$CC); #DEPLOY - UNcomment
  • nwg_list_submit.cgi: send_mail($program_name,$s_name,$email_to,$email_from,$email_subject,$email_txt);
  • request_approve_mail.cgi: send_mail ("request_approve_mail.cgi",$ad_name,$to, $from, $subject, $mailbody, $cc);
  • request_approve_mail.cgi: send_mail("request_approve_mail.cgi",$ad_name,$to,$from,$subject,$mailbody);
  • request_mail.cgi: send_mail ("request_mail.cgi",$requestor,$to, "IETF Secretariat <[email protected]>", $subject, $mailbody_ad, $cc) unless ($error_occur);

Phase 2

Replace authentication-required tools. This means building an authentication system, hooking into django's authentication framework either with the existing apache authentication or with other. Note that datatracker.ietf.org uses basic authentication, but django doesn't support old-style DES passwords. (Perhaps we can supply our own auth class with its own check_password function - this is to look into)

  • forward-looking: want people to be able to register accounts for themselves, so that e.g. wg secretaries can add comments to documents

Applications

django divides a project into "applications". In general, an application has a model, some URLs, views to go with the URLs, and templates to go with the views.

One challenge is to divide the database model up into applications. It's not crucial to get this right since applications can import models from each other using the normal python "import" syntax.

What we should try to get right from the beginning, is the URL design. Even if we provide Redirects for the old URLs to the new ones, and can do that also for new ones which we would like to change, it would be best if the new URLs are good and stable from the start. More thoughts on URL design are collected on the UrlDesign page.

Steps for each project

  • Model

This is the database model, and is the key to making the views and templates easy. It is written in Python, but requires some amount of understanding of the underlying database.

  • View

This is the code that does the work that a web request asks for. It can look things up in the Models, save updates, etc. It's code written in Python, leveraging the Model definitions.

  • Template

This is generally instantiated by a view to respond to a request. The template language is very simple, so any real work goes in the View. With properly written Models and Views, the actual "code" here is minimal; it's more about formatting than anything.

Avoiding Second System Syndrome

As tempting as it is to do otherwise, this system should strive to replicate the original view as much as possible. A second pass to update the look-and-feel across the board can be done later.

Django Links

Clone this wiki locally