Re: [WWdevel] WeBWorK 2.2 prerelease, code freeze in a branch?

[Davide P. C. <dp...@un...>]

>> Then there is the issue of opening new windows, which I always  
>> found terribly confusing, and I think may have been the real  
>> source of problem for our professors   For example, if you edit a  
>> problem then view it, you get a new window (fine) and in that  
>> window there is "Edit this problem", and pressing this gets me an  
>> editor in the same window.  I now have two edit windows that I  
>> think of as being the same file, but they aren't.  The new window  
>> opened a view of a TEMPORARY file, and we are now editing the  
>> temporary file as a SECOND temporary file.
> Is this really true?

Yes, I was testing it as I wrote so that I would get it right.

Here's what I did:

1.  I started with the Library Browser and selected a problem to  
which I have write access.  Then used the "Edit it" link from the  
Library Browser.  This brings up the editor in the same window.  I  
get the "editing in .... .pg" message.

2.  Then I viewed the problem (the default action).  You get a new  
window in which you see the problem as a student would see it.  I see  
the "Saved to ... .pg.dpvc.tmp" and "viewing  
temporary .... .pg.dpvc.tmp" messages you mentioned.

3.  Now press the "Edit this problem" link at the bottom of the  
problem in the new window (which should be the font-most window).   
Now the editor comes up (in the window where I clicked) with the  
"Editing in ... .pg.dpvc.tmp" (note that I'm now editing the .tmp  
file not the original).  I now have two edit windows showing, one for  
the original .pg file and one for .pg.dpvc.tmp.

4.  Now use the view action (in the editor editing the .tmp file,  
which should be the front-most window).  This views the file in the  
SAME window (not a new one, as before), and I see a "Saved  
to ... .pg.dpvc.tmp.dpvc.tmp" and message and am told I'm "Editing  
in ... .pg.tmp.dpvc.tmp".  Note the double ".dpvc.tmp".  Continuing  
to edit and view in this same window gets me more and more  
".dpvc.tmp" suffixes.

5.  Saving the file (in the window editing ".pg.dpvc.tmp", the front- 
most window) gets me a message "Saved to ... .pg.dpvc.tmp" (not to  
the original .pg file) and a warning about not  
finding .pg.dpvc.tmp.dpvc.tmp, then a message saying I'm editing  
".pg.dpvc.tmp.dpvc.tmp".  At this point I give up in frustration,  
unable to cope with all the temporary files and lack of consistency  
about new windows.

> I though that a save operation always saved to the original file  
> (the one without a .tmp extension).

Yes, but when there are multiple .dpvc.tmp suffixes, the "original"  
file is not the one you might expect.

> You may want to change the name of the temporary file in order to  
> force the browser to refresh the data --
> we had a problem a while ago where the data being displayed by the  
> browser would not reflect the latest updates.

Oh, I can certainly get around it, but the general faculty are  
confused by this behavior, and I don't blame them.

> There is one problem with controlling the viewing and editing  
> windows which we didn't know how to solve at the time, but perhaps  
> can be solved now.  What you would like is a window named EDITOR  
> and a window named "PREVIEW"
> and you would like each to be properly linked to the other and you  
> would like them to always contain current data.  You could bring up  
> the second window as "PREVIEW" but there was no way to determine or  
> assign the name of the first window.

I get around this by targeting EVERY edit action to a window called  
"WW_Editor" and EVERY view action to "WW_View".  The first attempt to  
make an edit opens the edit window, and the first view opens the view  
window.  Then the two can bounce between each other as much as they  
want.  This does mean that I can only edit one file at a time, but I  
rarely have two open simultaneously anyway.  One could be more  
sophisticated about pairing edit and view windows if you wanted to,  
but I haven't tried to do that.

> In the early days we also used javaScript as little as possible --  
> it's possible we could relax that now in order to fix this problem.

It doesn't require JavaScript to do it, though I did add some so that  
"Revert" and "Save a copy as" don't target a new window, but "View",  
"Add" and "Save" do, because they show the actual problem or header,  
not the editor.  (I also added a "in a new window" checkbox, and have  
those radio buttons set that -- I also hooked up the onChange stuff  
-- and when that checkbox is checked, the form's target is set, and  
when unchecked, the target is cleared.)

Finally, you mention making the header problem 0, but I don't think  
this really helps.  From the professor's standpoint, it is still a  
different item, and will be thought of as different.  Saying "Editing  
set Orientation/ problem 0" will be confusing, I think (I have it say  
"Editing header info in ...").  Also, you have a course_info file  
that is still a special case, and there could be other such files (I  
have added an info panel to the options page that includes advice on  
not using your email password and so on, so that is another special  
case for me).  Since you are going to need them anyway, I don't see  
that handling the header too is all that much extra.

In any case, I would like to see some of this straightened out before  
the 2.2 release.

Davide