1. 07 Jul, 2002 1 commit
  2. 17 Jun, 2002 1 commit
  3. 02 Mar, 2002 1 commit
  4. 14 Feb, 2002 1 commit
    • Leigh B. Stoller's avatar
      A morass of form changes. The main goals are to avoid the loss of info · 9ac3d870
      Leigh B. Stoller authored
      when backing up (cause of an error that needs to be fixed) since not
      all browsers handle this the same. Instead, redraw the form with all
      of the original info and a list of error messages at the top.
      Conceptually simple change, but it turns out to be a pain to implement
      since you need to combine the form and processing code in one page
      (well, its just a lot easier to do that), and then change all of the
      forms to deal with a "default" value. That is, each different kind of
      input tag (text, radio, select, checkbox, etc.) requires slightly
      different changes to do that. Lots of forms, lots of entries on the
      forms, and its a long slow tedious process. Much nicer though, although
      the code is a bit harder to grok. At the same time, I added a lot more
      sanity checks of the information being passed in.
      
      The other change is to deal with how browsers handle the back button
      on a form thats been properly submitted. Not all browsers use
      the cache directives the same, and I was often typing back, only to
      have some form get reposted. Thats a major pain in the butt. The way
      to deal with that is to have the processor send out a Location header,
      which modifies the browser history so that the post is no longer in
      the history. You back up straight to the unposted form (if its in the
      cache). I've done this to only some forms, since its a bit of a pain
      to rework things so that you can jump ahead to a page that spits out
      the requisite warm fuzzies for the specific operation just completed.
      
      I've done newproject, joinproject, update user info, newimageid, and
      newimaged_dz forms.
      9ac3d870
  5. 11 Feb, 2002 1 commit
  6. 08 Feb, 2002 1 commit
    • Leigh B. Stoller's avatar
      Big round of image/osid changes. This is the first cut (final cut?) at · a73e627e
      Leigh B. Stoller authored
      supporting autocreating and autoloading images. The imageid form now
      sports a field to specify a nodeid to create the image from; If set,
      the backend create_image script is invoked. Thats the easy part.
      Slightly harder is autoloading images based on the osid specified in
      the NS file. To support this, I have added a new DB table called
      osidtoimageid, which holds the mapping from osid/pctype to imageid.
      When users create images, they must specify what node types that image
      is good for. Obviously, the mappings have to be unique or it would be
      impossible to figure it out! Anyway, once that image mapping is
      in place and the image created, the user can specify that ID in the NS
      file. I've changed os_setup to to look for IDs that are not loaded,
      and to try and find one in the osidtoimageid. If found, it invokes
      os_load. To keep things running in parallel as much as possible,
      os_setup issues all the loads/reboots (could be more than a single set
      of loads is multiple IDs are in the NS file) at once, and waits for
      all the children to exit. I've hacked up os_load a bit to try and be
      more robust in the face of PXE failures, which still happen and are
      rather troublsesome. Need an event system!
      
      Contained in this revision are unrelated changed to make the OS and
      Image IDs per-project unique instead of globally unique, since thats a
      pain for the users. This turns out to be very messy, since underneath
      we do not want to pass around pid/ID in all the various places its
      used. Rather, I create a globally unique name and extened the OS and
      Image tables to include pid/name/ID. The user selects pid/name, and I
      create the globally unique ID. For the most part this is invisible
      throughout the system, except where we interface with the user, say in
      the web pages; the user should see his chosen name where possible, and
      the should invoke scripts (os_load, create_image, etc) using his/her
      name not the internal ID. Also, in the front end the NS file should
      use the user name not the ID. All in all, this accounted for a number
      of annoying changes and some special cases that are unavoidable.
      a73e627e
  7. 18 Oct, 2001 2 commits