Loading ...
Sorry, an error occurred while loading the content.

RE: [fitnesse] "rename this page" from top level to sub wiki

Expand Messages
  • Micah Martin
    Bishop, The refactorings are still in the works and the functionallity you expected will be possible with the Move Page refactoring.... coming soon! The
    Message 1 of 6 , Sep 2, 2003
    • 0 Attachment
      Bishop,

      The refactorings are still in the works and the functionallity you
      expected will be possible with the "Move Page" refactoring.... coming soon!
      The "Rename Page" refactoring will only do in-place renaming meaning it will
      not change the structure of the wiki pages.

      Micah

      > -----Original Message-----
      > From: Bishop, Murray [mailto:murray.bishop@...]
      > Sent: Sunday, August 31, 2003 5:08 PM
      > To: 'fitnesse@yahoogroups.com'
      > Subject: [fitnesse] "rename this page" from top level to sub wiki
      >
      >
      > Thanks for FitNesse, I'm enjoying learning how to use it!
      >
      > It looks a bit like the "rename this page" refactor won't
      > move pages from
      > top level Wiki to SubWiki.
      >
      > With fitnesse20030728.zip, I'm getting a null pointer
      > exception from trying
      > to refactor "rename this page" existing page
      > http://mbishop-tecra:8080/OmsStories?refactor to
      > OperationsManagementSystem.OmsStories.
      >
      > After I press the refactor button, I get
      > http://mbishop-tecra:8080/OmsStories?renamePage=&newPageName=O
      perationsManag
      ementSystem.OmsStories showing:

      Error Occurred
      java.lang.NullPointerException
      fitnesse.responders.RenamePageResponder.makeResponse(Unknown Source)
      fitnesse.FitnesseServer.makeResponse(Unknown Source)
      fitnesse.FitnesseServer.serve(Unknown Source)
      fitnesse.socketservice.SocketService$ServerRunner.run(Unknown
      Source)
      java.lang.Thread.run(Unknown Source)

      and wind up with a directory named OperationsManagementSystem.OmsStories
      rather than OperationsManagementSystem\OmsStories.

      Using windows explorer to rename the directory .\OmsStories to .\
      OperationsManagementSystem\OmsStories does do what I want though ;-).


      Best,
      Murray



      To unsubscribe from this group, send an email to:
      fitnesse-unsubscribe@yahoogroups.com



      Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
    • Stephen
      Hey Micah, How will you be doing the Move? The two options I see are: 1. Get page data, delete page, create page with new page data (low impact on low-level
      Message 2 of 6 , Sep 3, 2003
      • 0 Attachment
        Hey Micah,

        How will you be doing the Move? The two options I see are:

        1. Get page data, delete page, create page with new page data (low
        impact on low-level objects, but loses version info)
        2. Move folder and clear cache (for the FileSystemPage, anyway) (high
        impact on low-level objects, but retains version info)
        3. (variation on 1) Add ability to retrieve the versions as a
        Version[] (or List) and also the ability to store them into new pages.

        The first option has no effect on the FileSystem/Database Pages, while
        the second will have to be thought about carefully, at least on the
        Database side. One can move a page anywhere in the hierarchy by
        changing the left/right indices in the index, which is a very fast
        operation. But, the algorithm isn't intuitive. :-). It would take
        me 4 hrs to write that bit on the Database side if you do it the hard
        (and best, imho) way.. hehe. The third (and most hacky) way is easy.
        Very easy. Hehe.

        -S.

        P.S. We've been using the Database back-end for 2 weeks now, with no
        problems (at least no loss of data..hehe). I did put one update in,
        which will have to be reintegrated with the code base should y'all
        decide to put it in.
      • Micah Martin
        I agree that option 2 (the hard way) is the right way to go. Paul, one of out summer apprentices, did a good amount of work on this story before he went back
        Message 3 of 6 , Sep 5, 2003
        • 0 Attachment
          I agree that option 2 (the hard way) is the right way to go. Paul, one of
          out summer apprentices, did a good amount of work on this story before he
          went back to school. I haven't seem the code yet but I belive that "moving"
          the page is better than deleting and recreating it. We definately want to
          maintain all the versions through the move.

          Thats good news on the database back-end. I want this add-on to be usabale
          by everyone else in the next release.

          Micah

          -----Original Message-----
          From: Stephen [mailto:firepoet78@...]
          Sent: Wednesday, September 03, 2003 7:48 AM
          To: fitnesse@yahoogroups.com
          Subject: [fitnesse] Re: "rename this page" from top level to sub wiki


          Hey Micah,

          How will you be doing the Move? The two options I see are:

          1. Get page data, delete page, create page with new page data (low
          impact on low-level objects, but loses version info)
          2. Move folder and clear cache (for the FileSystemPage, anyway) (high
          impact on low-level objects, but retains version info)
          3. (variation on 1) Add ability to retrieve the versions as a
          Version[] (or List) and also the ability to store them into new pages.

          The first option has no effect on the FileSystem/Database Pages, while
          the second will have to be thought about carefully, at least on the
          Database side. One can move a page anywhere in the hierarchy by
          changing the left/right indices in the index, which is a very fast
          operation. But, the algorithm isn't intuitive. :-). It would take
          me 4 hrs to write that bit on the Database side if you do it the hard
          (and best, imho) way.. hehe. The third (and most hacky) way is easy.
          Very easy. Hehe.

          -S.

          P.S. We've been using the Database back-end for 2 weeks now, with no
          problems (at least no loss of data..hehe). I did put one update in,
          which will have to be reintegrated with the code base should y'all
          decide to put it in.



          To unsubscribe from this group, send an email to:
          fitnesse-unsubscribe@yahoogroups.com



          Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
        • Stephen
          This will be an interesting problem with the database stuff. I assume there was a movePage method implemented in RawPage? How soon can the database stuff be
          Message 4 of 6 , Sep 7, 2003
          • 0 Attachment
            This will be an interesting problem with the database stuff. I assume
            there was a "movePage" method implemented in RawPage?

            How soon can the database stuff be merged in so I can implement the
            new move code? :-)

            -S.

            --- In fitnesse@yahoogroups.com, Micah Martin <micah@o...> wrote:
            > I agree that option 2 (the hard way) is the right way to go. Paul,
            one of
            > out summer apprentices, did a good amount of work on this story
            before he
            > went back to school. I haven't seem the code yet but I belive that
            "moving"
            > the page is better than deleting and recreating it. We definately
            want to
            > maintain all the versions through the move.
          • Micah Martin
            ... Good question. Things are extremely busy here at Object Mentor leaving us no time to work on FitNesse. I ll be sure to inform you when I ve had the time.
            Message 5 of 6 , Sep 8, 2003
            • 0 Attachment
              > -----Original Message-----
              > From: Stephen [mailto:firepoet78@...]
              > Sent: Sunday, September 07, 2003 11:25 AM
              >
              > How soon can the database stuff be merged in so I can implement the
              > new move code? :-)
              >

              Good question. Things are extremely busy here at Object Mentor leaving us
              no time to work on FitNesse. I'll be sure to inform you when I've had the
              time. It won't be for at least a couple weeks I'm afraid.

              Micah
            Your message has been successfully submitted and would be delivered to recipients shortly.