openwebwork-devel — WeBWorK development discussion

Re: [WWdevel] Re: [WWcvs] webwork2: 1-liner adding course hiding support.

[Sam H. <sh...@ma...>]

On Dec 3, 2005, at 16:25, Arnold Pizer wrote:

> At 06:35 PM 12/2/2005, Sam Hathaway via activitymail wrote:
>
> Thanks Sam.  Note the file must be named "hide_directory" not  
> "hidden_directory"

That's correct. The typo is in the log message, not the source change.
-sam

>> 1-liner adding course hiding support. place a file named
>> "hidden_directory" in a course directory and it will not show up  
>> in the
>> courses list on the WeBWorK home page. it will still appear in the
>> CourseAdmin module.
>
>
> Prof. Arnold K. Pizer
> Dept. of Mathematics
> University of Rochester
> Rochester, NY 14627
> (585) 275-7767
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through  
> log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD  
> SPLUNK!
> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> _______________________________________________
> OpenWeBWorK-Devel mailing list
> Ope...@li...
> https://lists.sf.net/lists/listinfo/openwebwork-devel

[WWdevel] Re: [WWcvs] webwork2: 1-liner adding course hiding support.

[Arnold P. <ap...@ma...>]

At 06:35 PM 12/2/2005, Sam Hathaway via activitymail wrote:

Thanks Sam.  Note the file must be named "hide_directory" not 
"hidden_directory"

Arnie

>1-liner adding course hiding support. place a file named
>"hidden_directory" in a course directory and it will not show up in the
>courses list on the WeBWorK home page. it will still appear in the
>CourseAdmin module.


Prof. Arnold K. Pizer
Dept. of Mathematics
University of Rochester
Rochester, NY 14627
(585) 275-7767 

Re: [WWdevel] hiding courses from general view

[Arnold P. <ap...@ma...>]

At 12:04 PM 12/1/2005, Sam Hathaway wrote:
>On Nov 29, 2005, at 10:21, Arnold Pizer wrote:
>
>>At 06:17 PM 11/22/2005, Sam Hathaway wrote:
>>
>>Hi,
>>
>>Does anyone have an objection if we implement Sam's suggestion:
>>
>>>The simplest thing I can think of is: if a course directory contains
>>>a file named hide_course, hide the course. I would like to support a
>>>hierarchical courses directory at some point as well, but that's a
>>>whole 'nother problem.
>>>-sam
>>
>>This is simple, it should not interfere with any customized setups
>>people have, and it can be used by professors to hide their own
>>courses.  I would suggest that the file be named hide_directory (or
>>maybe allow both hide_course and hide_directory) . E.g. it could
>>also be placed in subdirectories which are not courses ( e.g.
>>http://webwork.rochester.edu/webwork2/templates ).  The fact that
>>these are listed is a bug which Sam's idea would fix.
>
>I'm hesitant to add multiple options that do the same thing, so
>perhaps "hide_directory" is the way to go. On the other hand, why are
>there directories that are not courses in the webwork2/courses
>directory in the first place?
>-sam

I don't know why it's there (drwxrwxr-x    9 gage     webwork   1536 
Jan  3  2005 templates)
but I do not think we should preclude people from adding 
subdirectories (e.g. old_courses).
I also would prefer "hide_directory"

Arnie


>-------------------------------------------------------
>This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
>for problems?  Stop!  Download the new AJAX search engine that makes
>searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
>http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
>_______________________________________________
>OpenWeBWorK-Devel mailing list
>Ope...@li...
>https://lists.sf.net/lists/listinfo/openwebwork-devel

Prof. Arnold K. Pizer
Dept. of Mathematics
University of Rochester
Rochester, NY 14627
(585) 275-7767

Re: [WWdevel] hiding courses from general view

[Arnold P. <ap...@ma...>]

At 12:04 PM 12/1/2005, Sam Hathaway wrote:
>On Nov 29, 2005, at 10:21, Arnold Pizer wrote:
>
>>At 06:17 PM 11/22/2005, Sam Hathaway wrote:
>>
>>Hi,
>>
>>Does anyone have an objection if we implement Sam's suggestion:
>>
>>>The simplest thing I can think of is: if a course directory contains
>>>a file named hide_course, hide the course. I would like to support a
>>>hierarchical courses directory at some point as well, but that's a
>>>whole 'nother problem.
>>>-sam
>>
>>This is simple, it should not interfere with any customized setups
>>people have, and it can be used by professors to hide their own
>>courses.  I would suggest that the file be named hide_directory (or
>>maybe allow both hide_course and hide_directory) . E.g. it could
>>also be placed in subdirectories which are not courses ( e.g.
>>http://webwork.rochester.edu/webwork2/templates ).  The fact that
>>these are listed is a bug which Sam's idea would fix.
>
>I'm hesitant to add multiple options that do the same thing, so
>perhaps "hide_directory" is the way to go. On the other hand, why are
>there directories that are not courses in the webwork2/courses
>directory in the first place?
>-sam
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
>for problems?  Stop!  Download the new AJAX search engine that makes
>searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
>http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
>_______________________________________________
>OpenWeBWorK-Devel mailing list
>Ope...@li...
>https://lists.sf.net/lists/listinfo/openwebwork-devel

Prof. Arnold K. Pizer
Dept. of Mathematics
University of Rochester
Rochester, NY 14627
(585) 275-7767

Re: [WWdevel] hiding courses from general view

[Sam H. <sh...@ma...>]

On Nov 29, 2005, at 10:21, Arnold Pizer wrote:

> At 06:17 PM 11/22/2005, Sam Hathaway wrote:
>
> Hi,
>
> Does anyone have an objection if we implement Sam's suggestion:
>
>> The simplest thing I can think of is: if a course directory contains
>> a file named hide_course, hide the course. I would like to support a
>> hierarchical courses directory at some point as well, but that's a
>> whole 'nother problem.
>> -sam
>
> This is simple, it should not interfere with any customized setups  
> people have, and it can be used by professors to hide their own  
> courses.  I would suggest that the file be named hide_directory (or  
> maybe allow both hide_course and hide_directory) . E.g. it could  
> also be placed in subdirectories which are not courses ( e.g.  
> http://webwork.rochester.edu/webwork2/templates ).  The fact that  
> these are listed is a bug which Sam's idea would fix.

I'm hesitant to add multiple options that do the same thing, so  
perhaps "hide_directory" is the way to go. On the other hand, why are  
there directories that are not courses in the webwork2/courses  
directory in the first place?
-sam

Re: [WWdevel] hiding courses from general view

[Arnold P. <ap...@ma...>]

At 06:17 PM 11/22/2005, Sam Hathaway wrote:

Hi,

Does anyone have an objection if we implement Sam's suggestion:

>The simplest thing I can think of is: if a course directory contains
>a file named hide_course, hide the course. I would like to support a
>hierarchical courses directory at some point as well, but that's a
>whole 'nother problem.
>-sam

This is simple, it should not interfere with any customized setups 
people have, and it can be used by professors to hide their own 
courses.  I would suggest that the file be named hide_directory (or 
maybe allow both hide_course and hide_directory) . E.g. it could also 
be placed in subdirectories which are not courses ( e.g. 
http://webwork.rochester.edu/webwork2/templates ).  The fact that 
these are listed is a bug which Sam's idea would fix.

If we come up with a more comprehensive solution, that would be fine 
but it will require some good ideas.

Arnie


Prof. Arnold K. Pizer
Dept. of Mathematics
University of Rochester
Rochester, NY 14627
(585) 275-7767

Re: [WWdevel] hiding courses from general view

[John J. <jj...@as...>]

What Davide describes sounds pretty good.  How much change was needed
for that?  Also, how does it determine the current semester?  If you
make a course for the next semester ahead of time, will that become
current, or does it look at the current date?

For our part, I don't think webwork can make a useable homepage for
ASU.  We present a single home page for courses distributed across
multiple servers.

John


>>>>> Michael Gage writes:

 > Hi,
 > Does anyone have ideas or suggestions for a way to build a Home.pm
 > module so that various options
 > for a homepage can be implemented with a minimum of programming (none
 > would be nice :-)  )

 > It seems to me that folks are going to want to be able to customize
 > their home page for a WeBWorK server much more than we allow right at
 > the moment.

 > As a start it seems to me from the comments so far that we will want
 > to break the tight link between the directory structure of the
 > courses and what is listed on the home page.

 > Take care,

 > Mike


 > On Nov 22, 2005, at 6:26 PM, Davide P. Cervone wrote:

 >>>> If you look at e.g. http://webwork.rochester.edu/webwork2 you
 >>>> will see a long list of courses most of which (in my opinion)
 >>>> should be hidden from general view.  I think in this general
 >>>> location only courses of interest to students should appear.
 >>>> Does someone have in mind a good mechanism to do this?  It could
 >>>> be as simple as having a directory "hidden" (which shouldn't
 >>>> appear on the list) and then the URL  http://
 >>>> webwork.rochester.edu/webwork2/hidden/old_course would give
 >>>> access to a hidden old course.  Or maybe there could be a
 >>>> directory "archive" (which maybe would appear on the list) which
 >>>> would need a password to enter.  Another question is whether or
 >>>> not the Course Administration course should appear in such a
 >>>> public place.
 >>> 
 >>> The simplest thing I can think of is: if a course directory
 >>> contains a file named hide_course, hide the course. I would like
 >>> to support a hierarchical courses directory at some point as well,
 >>> but that's a whole 'nother problem.
 >>> -sam
 >> 
 >> At Union, we use a naming scheme for our courses that includes the
 >> year and term (e.g., 05FA-MTH115-01 is Fall term 2005 Math 115
 >> section 01).  Our home page only shows the current term (and a
 >> custom "past courses" page shows past terms).  When the courses for
 >> the next term are creatd, they automatically show up as the current
 >> courses and the others are relegated to the past courses without my
 >> intervention.  Courses that don't match the naming scheme are not
 >> shown anywhere (they are considered to be "test" courses).  I also
 >> have special "library" courses that allow our professors to view
 >> the various libraries more easily, since we don't have all of them
 >> linked into the main courses.  The is a custom page that lists
 >> these as well.
 >> 
 >> Anyway, it seems to have worked pretty well here.
 >> 
 >> Davide
 >> 

 > "Only dead fish swim with the stream."

Re: [WWdevel] hiding courses from general view

[Michael G. <ga...@ma...>]

Hi,

Does anyone have ideas or suggestions for a way to build a Home.pm  
module so that various options
for a homepage can be implemented with a minimum of programming (none  
would be nice :-)  )

It seems to me that folks are going to want to be able to customize  
their home page for a WeBWorK server much more than we allow right at  
the moment.

As a start it seems to me from the comments so far that we will want  
to break the tight link between the directory structure of the  
courses and what is listed on the home page.

Take care,

Mike


On Nov 22, 2005, at 6:26 PM, Davide P. Cervone wrote:

>>> If you look at e.g. http://webwork.rochester.edu/webwork2 you  
>>> will see a long list of courses most of which (in my opinion)  
>>> should be hidden from general view.  I think in this general  
>>> location only courses of interest to students should appear.   
>>> Does someone have in mind a good mechanism to do this?  It could  
>>> be as simple as having a directory "hidden" (which shouldn't  
>>> appear on the list) and then the URL  http:// 
>>> webwork.rochester.edu/webwork2/hidden/old_course would give  
>>> access to a hidden old course.  Or maybe there could be a  
>>> directory "archive" (which maybe would appear on the list) which  
>>> would need a password to enter.  Another question is whether or  
>>> not the Course Administration course should appear in such a  
>>> public place.
>>
>> The simplest thing I can think of is: if a course directory  
>> contains a file named hide_course, hide the course. I would like  
>> to support a hierarchical courses directory at some point as well,  
>> but that's a whole 'nother problem.
>> -sam
>
> At Union, we use a naming scheme for our courses that includes the  
> year and term (e.g., 05FA-MTH115-01 is Fall term 2005 Math 115  
> section 01).  Our home page only shows the current term (and a  
> custom "past courses" page shows past terms).  When the courses for  
> the next term are creatd, they automatically show up as the current  
> courses and the others are relegated to the past courses without my  
> intervention.  Courses that don't match the naming scheme are not  
> shown anywhere (they are considered to be "test" courses).  I also  
> have special "library" courses that allow our professors to view  
> the various libraries more easily, since we don't have all of them  
> linked into the main courses.  The is a custom page that lists  
> these as well.
>
> Anyway, it seems to have worked pretty well here.
>
> Davide
>

"Only dead fish swim with the stream."

Re: [WWdevel] hiding courses from general view

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

>> If you look at e.g. http://webwork.rochester.edu/webwork2 you will  
>> see a long list of courses most of which (in my opinion) should be  
>> hidden from general view.  I think in this general location only  
>> courses of interest to students should appear.  Does someone have  
>> in mind a good mechanism to do this?  It could be as simple as  
>> having a directory "hidden" (which shouldn't appear on the list)  
>> and then the URL  http://webwork.rochester.edu/webwork2/hidden/ 
>> old_course would give access to a hidden old course.  Or maybe  
>> there could be a directory "archive" (which maybe would appear on  
>> the list) which would need a password to enter.  Another question  
>> is whether or not the Course Administration course should appear  
>> in such a public place.
>
> The simplest thing I can think of is: if a course directory  
> contains a file named hide_course, hide the course. I would like to  
> support a hierarchical courses directory at some point as well, but  
> that's a whole 'nother problem.
> -sam

At Union, we use a naming scheme for our courses that includes the  
year and term (e.g., 05FA-MTH115-01 is Fall term 2005 Math 115  
section 01).  Our home page only shows the current term (and a custom  
"past courses" page shows past terms).  When the courses for the next  
term are creatd, they automatically show up as the current courses  
and the others are relegated to the past courses without my  
intervention.  Courses that don't match the naming scheme are not  
shown anywhere (they are considered to be "test" courses).  I also  
have special "library" courses that allow our professors to view the  
various libraries more easily, since we don't have all of them linked  
into the main courses.  The is a custom page that lists these as well.

Anyway, it seems to have worked pretty well here.

Davide

Re: [WWdevel] hiding courses from general view

[Sam H. <sh...@ma...>]

On Nov 22, 2005, at 12:12, Arnold Pizer wrote:

> If you look at e.g. http://webwork.rochester.edu/webwork2 you will  
> see a long list of courses most of which (in my opinion) should be  
> hidden from general view.  I think in this general location only  
> courses of interest to students should appear.  Does someone have  
> in mind a good mechanism to do this?  It could be as simple as  
> having a directory "hidden" (which shouldn't appear on the list)  
> and then the URL  http://webwork.rochester.edu/webwork2/hidden/ 
> old_course would give access to a hidden old course.  Or maybe  
> there could be a directory "archive" (which maybe would appear on  
> the list) which would need a password to enter.  Another question  
> is whether or not the Course Administration course should appear in  
> such a public place.

The simplest thing I can think of is: if a course directory contains  
a file named hide_course, hide the course. I would like to support a  
hierarchical courses directory at some point as well, but that's a  
whole 'nother problem.
-sam

[WWdevel] hiding courses from general view

[Arnold P. <ap...@ma...>]

Hi,

If you look at e.g. http://webwork.rochester.edu/webwork2 you will 
see a long list of courses most of which (in my opinion) should be 
hidden from general view.  I think in this general location only 
courses of interest to students should appear.  Does someone have in 
mind a good mechanism to do this?  It could be as simple as having a 
directory "hidden" (which shouldn't appear on the list) and then the 
URL  http://webwork.rochester.edu/webwork2/hidden/old_course would 
give access to a hidden old course.  Or maybe there could be a 
directory "archive" (which maybe would appear on the list) which 
would need a password to enter.  Another question is whether or not 
the Course Administration course should appear in such a public place.

Arnie


Prof. Arnold K. Pizer
Dept. of Mathematics
University of Rochester
Rochester, NY 14627
(585) 275-7767

Re: [WWdevel] Re: [WWcvs] webwork2: changes to links subroutine: * sublists are now within list

[Michael G. <ga...@ma...>]

Hi Sam,

As it turned out I hadn't updated the ur.css style sheets.  Once I  
had done
that (and refreshed pages a couple of times to clear the Safari  
caches) things
looked much better.

thanks for the note on how to change the indentation for those that  
want to.

thanks.

Take care,

Mike

On Nov 21, 2005, at 9:30 PM, Sam Hathaway wrote:

> On Nov 21, 2005, at 20:23, Michael Gage wrote:
>
>> Hi Sam,
>>
>> I have one complaint about how this looks -- in general I like how  
>> it behaves.
>> Can we lower the indent size for the lists on the left hand side?   
>> It looks like
>> there are automatically 12 spaces
>> before the Classlist Editor, homework sets edit and so forth.   
>> This seems like
>> a lot of screen real estate.  (I know most screens are large these  
>> days, so this is not
>> as crucial as it was 3 or 4 years ago, but stingy habits die  
>> hard. :-)  )
>>
>> I dimly remember constructing this by hand with
>>   to minimize the width of the left margin.  Can we adjust  
>> the CSS specificiation
>> in this region to make the indent size for each of the lists 2  
>> spaces instead of 4 or more?
>
> The size is controlled by this line in the ur.template stylesheet  
> (htdocs/css/ur.css):
>
> div.Links ul { list-style: none; margin-left: 0; padding-left: 0; }
> div.Links ul ul { list-style: none; margin-left: 0.5em; padding- 
> left: 0; }
>
> The indentation of sublists is 0.5em, which is (apparently) half  
> the width of the letter M in the font being used. It looks like  
> about 2 or 3 spaces to me, have you updated the stylesheet? If not,  
> you might be seeing the default indentation for nested lists.
>
> Here it is in Safari:
>
> <pastedGraphic.tiff>

"Only dead fish swim with the stream."

Re: [WWdevel] Re: [WWcvs] webwork2: changes to links subroutine: * sublists are now within list

[Sam H. <sh...@ma...>]

On Nov 21, 2005, at 20:23, Michael Gage wrote:

> Hi Sam,
>
> I have one complaint about how this looks -- in general I like how  
> it behaves.
> Can we lower the indent size for the lists on the left hand side?   
> It looks like
> there are automatically 12 spaces
> before the Classlist Editor, homework sets edit and so forth.  This  
> seems like
> a lot of screen real estate.  (I know most screens are large these  
> days, so this is not
> as crucial as it was 3 or 4 years ago, but stingy habits die  
> hard. :-)  )
>
> I dimly remember constructing this by hand with
>   to minimize the width of the left margin.  Can we adjust the  
> CSS specificiation
> in this region to make the indent size for each of the lists 2  
> spaces instead of 4 or more?

The size is controlled by this line in the ur.template stylesheet  
(htdocs/css/ur.css):

div.Links ul { list-style: none; margin-left: 0; padding-left: 0; }
div.Links ul ul { list-style: none; margin-left: 0.5em; padding-left:  
0; }

The indentation of sublists is 0.5em, which is (apparently) half the  
width of the letter M in the font being used. It looks like about 2  
or 3 spaces to me, have you updated the stylesheet? If not, you might  
be seeing the default indentation for nested lists.

Here it is in Safari:

[WWdevel] Re: [WWcvs] webwork2: changes to links subroutine: * sublists are now within list

[Michael G. <ga...@ma...>]

Hi Sam,

I have one complaint about how this looks -- in general I like how it  
behaves.
Can we lower the indent size for the lists on the left hand side?  It  
looks like
there are automatically 12 spaces
before the Classlist Editor, homework sets edit and so forth.  This  
seems like
a lot of screen real estate.  (I know most screens are large these  
days, so this is not
as crucial as it was 3 or 4 years ago, but stingy habits die  
hard. :-)  )

I dimly remember constructing this by hand with
  to minimize the width of the left margin.  Can we adjust the  
CSS specificiation
in this region to make the indent size for each of the lists 2 spaces  
instead of 4 or more?

-- Mike



On Nov 21, 2005, at 4:41 PM, Sam Hathaway via activitymail wrote:

> Log Message:
> -----------
> changes to links subroutine:
> * sublists are now within list items, as required by html spec
> * use &makeLinks helper to generate links (makes the code easier to  
> read)
> * hilite the "active" link item with a strong tag and the "active"  
> class
> * change the way displayMode and showOldAnswers are preserved, and
>   preserve them in all the links. (see comments in code)
> changes to help subroutine:
> * add alt-text for help icon (" ? ") to conform to html spec
>
> As of now, all the code generated by template functions in this  
> file is
> XHTML 1.0 Transitional compliant. The same cannot be said for the code
> generated by other content generators or PG.
>
> Modified Files:
> --------------
>     webwork2/lib/WeBWorK:
>         ContentGenerator.pm

"Only dead fish swim with the stream."

Re: [WWdevel] webwork page caching

[Michael G. <ga...@ma...>]

>
> One low-impact improvement would be to place the timestamp more  
> prominently on the page, and perhaps label it "Generated" or  
> "Current as of" rather than "Updated" or something.
> -sam
>
>
>> P Gavin LaRose wrote:
>>
>>
>>> Hi Sam,
>>>
>>> The biggest reasons I was thinking this could be a problem were:
>>>  - On gateway tests I maintain a timer on the page indicating how  
>>> much
>>>    time is left.  At the moment I'm doing this as a countdown  
>>> from the
>>>    amount of time left when the page is first loaded---going back  
>>> to this

For the high tech answer:

aren't there some java or javaScript clocks out there that could
keep the time continuously e.g.  http://javaboutique.internet.com/ 
countdown/

Take care,

Mike

Re: [WWdevel] webwork page caching

[Sam H. <sh...@ma...>]

On Nov 3, 2005, at 11:02, John Jones wrote:

> Hi all,
>
> I also use the back button frequently, so I kind of like things the  
> way they are.
> For students who use the back button and then are mislead by what  
> the page says (be it "you still have 10 minutes to finish" or "you  
> have 2 attempts left on this problem"), I think that those students  
> don't deserve much sympathy since they did something to create the  
> problem situation.  Moreover, understanding what has happened with  
> web forms and the back button is no longer just for geeks.  With  
> internet shopping, it is now more of a basic life skill.
>
> That said, I would not be strongly opposed to adding no-cache,  
> especially if it were just for students (I sense another addition  
> to the permissions hash - which makes it easily reconfigured on a  
> course-by-course basis).

One low-impact improvement would be to place the timestamp more  
prominently on the page, and perhaps label it "Generated" or "Current  
as of" rather than "Updated" or something.
-sam

> P Gavin LaRose wrote:
>
>> Hi Sam,
>>
>> The biggest reasons I was thinking this could be a problem were:
>>  - On gateway tests I maintain a timer on the page indicating how  
>> much
>>    time is left.  At the moment I'm doing this as a countdown from  
>> the
>>    amount of time left when the page is first loaded---going back  
>> to this
>>    page therefore results in the student thinking that s/he has  
>> more time
>>    than is the case.  I can work around this if need be, but I  
>> think it's
>>    really part and parcel of the second comment, viz.,
>>
>>  - In general, when going from page to page working a problem the  
>> previous
>>    page's information won't reflect the current state of a  
>> problem.  This
>>    is particularly relevant when there are a fixed number of  
>> attempts at a
>>    problem, so that going 'back' makes it appear that one has more
>>    attempts than is actually the case.
>>
>> I agree that being able to go back through the browser's history  
>> is very useful, however.  One option would be to no-cache student  
>> pages, or for students only.
>>
>> I'm not entirely familiar with where WeBWorK is using GET vs POST,  
>> so I don't know where that becomes an issue.
>>
>> Gavin
>>
>> On Wed, 2 Nov 2005 at 23:35 Sam Hathaway wrote:
>>
>>> On Nov 2, 2005, at 11:34, P Gavin LaRose wrote:
>>>
>>>> Hi all,
>>>>
>>>> Watching some of our gateway testing, the following occurred to  
>>>> me: it would be good to avoid students being able to use the  
>>>> browser's "back" button to navigate.  And then I thought that  
>>>> this should be a desirable state of affairs in general.  Because  
>>>> WeBWorK pages contain state data, we don't really want people  
>>>> going back to previous pages.  I use this occasionally when I'm  
>>>> working as a course administrator, but on student pages I think  
>>>> it's something we don't want happening.
>>>>
>>>> Would it make sense to add a 'no-cache' command to the header of  
>>>> all WeBWorK pages, so that it would force the browser to go back  
>>>> to the server to get each new page?
>>>
>>>
>>> Is the problem just that there could be out-of-date information  
>>> on cached pages? (Like the case where a user attempts a problem  
>>> for the first time and then hits back to return to the problem  
>>> list and it tells her that she hasn't attempted it?) Or are there  
>>> more dangerous cases? (If there are those should be removed  
>>> regardless of whether we add no-cache.)
>>>
>>> I actually like being able to quickly pop back to the previous  
>>> page and then forward to the current one one without reloading.
>>>
>>> If we added no-cache we would also want to be more careful about  
>>> when we use POST versus GET. Good browsers warn you when a POST  
>>> request needs to be resubmitted (like in the case of no-cache)  
>>> and this is annoying when the re-POST isn't actually dangerous.
>>> -sam

Re: [WWdevel] webwork page caching

[John J. <jj...@as...>]

Hi all,

I also use the back button frequently, so I kind of like things the way 
they are. 

For students who use the back button and then are mislead by what the 
page says (be it "you still have 10 minutes to finish" or "you have 2 
attempts left on this problem"), I think that those students don't 
deserve much sympathy since they did something to create the problem 
situation.  Moreover, understanding what has happened with web forms and 
the back button is no longer just for geeks.  With internet shopping, it 
is now more of a basic life skill.

That said, I would not be strongly opposed to adding no-cache, 
especially if it were just for students (I sense another addition to the 
permissions hash - which makes it easily reconfigured on a 
course-by-course basis).

John


P Gavin LaRose wrote:

> Hi Sam,
>
> The biggest reasons I was thinking this could be a problem were:
>  - On gateway tests I maintain a timer on the page indicating how much
>    time is left.  At the moment I'm doing this as a countdown from the
>    amount of time left when the page is first loaded---going back to this
>    page therefore results in the student thinking that s/he has more time
>    than is the case.  I can work around this if need be, but I think it's
>    really part and parcel of the second comment, viz.,
>
>  - In general, when going from page to page working a problem the 
> previous
>    page's information won't reflect the current state of a problem.  This
>    is particularly relevant when there are a fixed number of attempts 
> at a
>    problem, so that going 'back' makes it appear that one has more
>    attempts than is actually the case.
>
> I agree that being able to go back through the browser's history is 
> very useful, however.  One option would be to no-cache student pages, 
> or for students only.
>
> I'm not entirely familiar with where WeBWorK is using GET vs POST, so 
> I don't know where that becomes an issue.
>
> Gavin
>
> On Wed, 2 Nov 2005 at 23:35 Sam Hathaway wrote:
>
>> On Nov 2, 2005, at 11:34, P Gavin LaRose wrote:
>>
>>> Hi all,
>>>
>>> Watching some of our gateway testing, the following occurred to me: 
>>> it would be good to avoid students being able to use the browser's 
>>> "back" button to navigate.  And then I thought that this should be a 
>>> desirable state of affairs in general.  Because WeBWorK pages 
>>> contain state data, we don't really want people going back to 
>>> previous pages.  I use this occasionally when I'm working as a 
>>> course administrator, but on student pages I think it's something we 
>>> don't want happening.
>>>
>>> Would it make sense to add a 'no-cache' command to the header of all 
>>> WeBWorK pages, so that it would force the browser to go back to the 
>>> server to get each new page?
>>
>>
>> Is the problem just that there could be out-of-date information on 
>> cached pages? (Like the case where a user attempts a problem for the 
>> first time and then hits back to return to the problem list and it 
>> tells her that she hasn't attempted it?) Or are there more dangerous 
>> cases? (If there are those should be removed regardless of whether we 
>> add no-cache.)
>>
>> I actually like being able to quickly pop back to the previous page 
>> and then forward to the current one one without reloading.
>>
>> If we added no-cache we would also want to be more careful about when 
>> we use POST versus GET. Good browsers warn you when a POST request 
>> needs to be resubmitted (like in the case of no-cache) and this is 
>> annoying when the re-POST isn't actually dangerous.
>> -sam
>
>

Re: [WWdevel] webwork page caching

[P G. L. <gl...@um...>]

Hi Sam,

The biggest reasons I was thinking this could be a problem were:
  - On gateway tests I maintain a timer on the page indicating how much
    time is left.  At the moment I'm doing this as a countdown from the
    amount of time left when the page is first loaded---going back to this
    page therefore results in the student thinking that s/he has more time
    than is the case.  I can work around this if need be, but I think it's
    really part and parcel of the second comment, viz.,

  - In general, when going from page to page working a problem the previous
    page's information won't reflect the current state of a problem.  This
    is particularly relevant when there are a fixed number of attempts at a
    problem, so that going 'back' makes it appear that one has more
    attempts than is actually the case.

I agree that being able to go back through the browser's history is very 
useful, however.  One option would be to no-cache student pages, or for 
students only.

I'm not entirely familiar with where WeBWorK is using GET vs POST, so I 
don't know where that becomes an issue.

Gavin

On Wed, 2 Nov 2005 at 23:35 Sam Hathaway wrote:

> On Nov 2, 2005, at 11:34, P Gavin LaRose wrote:
>
>> Hi all,
>> 
>> Watching some of our gateway testing, the following occurred to me: it 
>> would be good to avoid students being able to use the browser's "back" 
>> button to navigate.  And then I thought that this should be a desirable 
>> state of affairs in general.  Because WeBWorK pages contain state data, we 
>> don't really want people going back to previous pages.  I use this 
>> occasionally when I'm working as a course administrator, but on student 
>> pages I think it's something we don't want happening.
>> 
>> Would it make sense to add a 'no-cache' command to the header of all 
>> WeBWorK pages, so that it would force the browser to go back to the server 
>> to get each new page?
>
> Is the problem just that there could be out-of-date information on cached 
> pages? (Like the case where a user attempts a problem for the first time and 
> then hits back to return to the problem list and it tells her that she hasn't 
> attempted it?) Or are there more dangerous cases? (If there are those should 
> be removed regardless of whether we add no-cache.)
>
> I actually like being able to quickly pop back to the previous page and then 
> forward to the current one one without reloading.
>
> If we added no-cache we would also want to be more careful about when we use 
> POST versus GET. Good browsers warn you when a POST request needs to be 
> resubmitted (like in the case of no-cache) and this is annoying when the 
> re-POST isn't actually dangerous.
> -sam

-- 
P. Gavin LaRose, Ph.D.  Program Manager (Instructional Tech.)
Math Dept., University of Michigan
gl...@um...                        "There's no use in trying," [Alice]
734.764.6454                             said. "One Can't believe impossible
http://www.math.lsa.umich.edu/~glarose/  things." "I daresay you haven't had
                                          much practice," said the Queen.
                                                               - Lewis Carrol

Re: [WWdevel] webwork page caching

[Sam H. <sh...@ma...>]

On Nov 2, 2005, at 11:34, P Gavin LaRose wrote:

> Hi all,
>
> Watching some of our gateway testing, the following occurred to me:  
> it would be good to avoid students being able to use the browser's  
> "back" button to navigate.  And then I thought that this should be  
> a desirable state of affairs in general.  Because WeBWorK pages  
> contain state data, we don't really want people going back to  
> previous pages.  I use this occasionally when I'm working as a  
> course administrator, but on student pages I think it's something  
> we don't want happening.
>
> Would it make sense to add a 'no-cache' command to the header of  
> all WeBWorK pages, so that it would force the browser to go back to  
> the server to get each new page?

Is the problem just that there could be out-of-date information on  
cached pages? (Like the case where a user attempts a problem for the  
first time and then hits back to return to the problem list and it  
tells her that she hasn't attempted it?) Or are there more dangerous  
cases? (If there are those should be removed regardless of whether we  
add no-cache.)

I actually like being able to quickly pop back to the previous page  
and then forward to the current one one without reloading.

If we added no-cache we would also want to be more careful about when  
we use POST versus GET. Good browsers warn you when a POST request  
needs to be resubmitted (like in the case of no-cache) and this is  
annoying when the re-POST isn't actually dangerous.
-sam

[WWdevel] webwork page caching

[P G. L. <gl...@um...>]

Hi all,

Watching some of our gateway testing, the following occurred to me: it 
would be good to avoid students being able to use the browser's "back" 
button to navigate.  And then I thought that this should be a desirable 
state of affairs in general.  Because WeBWorK pages contain state data, we 
don't really want people going back to previous pages.  I use this 
occasionally when I'm working as a course administrator, but on student 
pages I think it's something we don't want happening.

Would it make sense to add a 'no-cache' command to the header of all 
WeBWorK pages, so that it would force the browser to go back to the server 
to get each new page?

Thanks,
Gavin

-- 
P. Gavin LaRose, Ph.D.  Program Manager (Instructional Tech.)
Math Dept., University of Michigan
gl...@um...                        "There's no use in trying," [Alice]
734.764.6454                             said. "One Can't believe impossible
http://www.math.lsa.umich.edu/~glarose/  things." "I daresay you haven't had
                                          much practice," said the Queen.
                                                               - Lewis Carrol

Re: [WWdevel] invisible (vs. unpublished) sets

[P G. L. <gl...@um...>]

Hi Mike,

Thanks for your comments.  I think you're right.  I wonder if there's any 
reason that a proctored test should show up on the problem list page.  My 
initial thought is to take your suggestion and make a configuration option 
which would default to making the 'take a new proctored test' option not 
show up on the problem list page.  That would, however, then require some 
documentation for people seeking to use proctored tests.

Any thoughts?

Thanks,
Gavin

On Wed, 26 Oct 2005 at 11:17 Michael Gage wrote:

> Hi Gavin,
>
> I think there is some use in having having a set invisible implies that 
> it cannot be worked on -- for example I've made sets invisible because 
> there was a glitch in one of the problems and I wanted to prevent 
> further student frustration until I'd fixed the set.  So I didn't want 
> them either seeing or doing the set.
>
> If we have write "is_a_gatewayquiz_set()" function (does this exist 
> already)  we could pretty easily add something to the course 
> configuration that determines whether or not gateway tests are listed on 
> the front page or not. That wouldn't interfere with the current behavior 
> of non-gateway sets and I think would do what you want.  Invisible vs. 
> visible wouldn't be involved at all.  An Invisible gateway set would not 
> show up but would also not be doable. Implementing it would involve some 
> changes to ProblemSets.pm, global.conf and course.conf but not much 
> else.
>
> take care,
>
> Mike

-- 
P. Gavin LaRose, Ph.D.  Program Manager (Instructional Tech.)
Math Dept., University of Michigan
gl...@um...                        "There's no use in trying," [Alice]
734.764.6454                             said. "One Can't believe impossible
http://www.math.lsa.umich.edu/~glarose/  things." "I daresay you haven't had
                                          much practice," said the Queen.
                                                               - Lewis Carrol

Re: [WWdevel] Fwd: UMM_math2111_tuba --reporting bugs in problems

[John J. <jj...@as...>]

Hi,

In thinking about the suggestions, first is if someone clicks Save As 
for a problem which is currently in a set.  The problem editor knows if 
it is looking at a problem because it is problem n of set X.  So, it 
would not be too hard to introduce a mechanism for people to specify 
that they want the copy to replace the original as the file for this 
problem.  This could be done as a javascript pop-up, or by adding a 
checkbox to the interface in PGProblemEditor.  Either way, I can see 
this as being generally useful.

A second suggestion is to have a mechanism to set all attempt numbers to 
0 for an individual problem.  I don't think that would be used so often 
since most webwork problems are probably used with unlimited attempts.

Finally, there is the mechanism for reporting bugs in problems.  I 
handle e-mails of this sort all the time.  Surprisingly, the best bug 
reports for problems only have a couple of lines: which problem it is, 
what seed causes the problem, and a sentence as to why it is wrong.  
Except in very rare cases, saying more wastes time for all parties.

So, to make it easier for people to send bug reports on problems, maybe 
there could be a button at the bottom of PGProblemEditor for just this 
purpose.  The reporter would have to somehow type the sentence saying 
why the problem is wrong, but webwork knows the path to the problem 
being looked at, and it knows the current seed.  Webwork even knows the 
name and probably the e-mail address of the person reporting the bug.  
So, almost all of the information needed for the bug report could be 
supplied by webwork.

It would be nice if the reports went directly into bugzilla, but it 
would be ok with me if the reports worked something like feedback 
e-mails - just a short description of the error had to be typed, webwork 
then appends the rest of the information and e-mails it to a generic 
address (database_problems-bugs@...) which ultimately comes to me.  
Naturally, the special button for doing this should only appear if the 
path to the problem starts Library/ since I don't plan on debugging 
everyone's webwork problems.

By any chance, does bugzilla have a mechanism for accepting bug reports 
sent via e-mail?  If webwork itself generates the e-mail, it could 
format the first few lines with special information needed to enter the 
bug.  Then, we could have both ease of use and automatic tracking of 
bugs by bugzilla.

John



Michael Gage wrote:

> here are some suggestions from Imre Tuba about simplifying the 
> reporting of bugs in problems.
>
> Take care,
>
> mike
>
>
> Begin forwarded message:
>
>> *From: *Imre Tuba <it...@mo... <mailto:it...@mo...>>
>> *Date: *October 19, 2005 1:06:56 PM EDT
>> *To: *Michael Gage <ga...@ma... 
>> <mailto:ga...@ma...>>
>> *Subject: **Re: Fwd: UMM_math2111_tuba --things should be fixed now*
>>
>>
>>> Thanks for the info on isolating the problem.  We have it fixed for now.
>>> The change we made in the CSS file was supposed to reduce the number 
>>> of problems listed in the left margin, once that list
>>> got big.  Apparently some browsers can't handle that CSS code.
>>> We'll try something else.
>>>
>>
>> Thanks. Also thanks for simplifying the procedure of replacing broken 
>> library problems with corrected local copies.
>>
>> Here is another suggestion along these lines. Bugs in problems are 
>> typically discovered by students. When a bug is discovered I usually 
>> have to
>>
>> 1. Investigate the problem and see if I can fix it. I usually can.
>>
>> 2. Fix the problem, make a local copy of the file, and replace the 
>> broken problem in the homework set with the local copy.
>>
>> 3. If the problem allowed limited attempts, I need to give students 
>> some extra attempts. I can do this individually for each student, 
>> which is painful. Or I can just increase the number of attempts 
>> allowed for everyone. This is not fair because those students that 
>> have not attempted the problem benefit more than those who have 
>> wasted some of their attempts in diagnosing the problem. It would be 
>> better if the attempt counters could all be reset to 0.
>>
>> 4. I need to notify the students that there was a mistake.
>>
>> 5. I need to file a bug report on bugzilla.
>>
>> Overall, this is a very time consuming process. As mistakes in the 
>> library files are rather common, I've had to go through it many times 
>> this semester. I wish it could be streamlined. Adding the new option 
>> to edit the library file, save a local copy, and replace the problem 
>> in the set with the local copy greatly reduced the workload in 2. 
>> Simplifying the filing of bug reports would be great. The bugzilla 
>> forms are long and awkward, and really do not encourage people to 
>> file bug reports. It would be much easier if there was a button on 
>> the problem edit page which could be clicked to file a bug report, 
>> where a commment can quickly be entered and a corrected source file 
>> can be attached. I am convinced this would greatly speed up the 
>> process of weeding the bugs out of the library problems.
>> -- 
>>     Imre
>>
>>
>

Re: [WWdevel] Fwd: Corrupted homework set

[John J. <jj...@as...>]

Hi,

I think an automated undo seems pretty involved.  The case in hand 
involved a set which was active, so any undo mechanism would involve 
holding student data in case a problem was deleted, and then you wanted 
to undo that.  So, I would just log information and let the instructor 
sort it out.  They can get to the logs from the file manager.

We could make use of the activity log.  If you have it turned on, it 
already writes an entry for every click, including changes saved in 
problem set detail.  Unfortunately, the default log entry is a generic 
dump of cgi parameters.  I think that some values are not visible in the 
log because they are really arrays of values.  I haven't needed that 
fixed, but changes in problem set detail might be a place where that 
would be important.  So, one possibility would be to fix that and let 
the instructor piece things together from the log entries.

Another way to improve the activity log's contents is to have a 
specially written entry for the set-detail module.  The code for the 
activity log lets a module override the default method.  With this 
approach, it could write an entry which included things like "old-value 
changed to new-value" to make it easier for an instructor to understand 
what happened when reading the log.

In either case, if one uses the activity log, it would take some 
patience and/or skill with grep to find what you want in it since there 
will be tons of other entries in there.  On the other hand, if you do 
know how to use grep, it is easy to pull all entries which come from 
problem-set-detail on a particular set by looking for the url.

If you create a separate log for set-detail changes in a given set, you 
could overwrite it keeping a fixed number of backups (the ww 1.9 way).  
Or, you could just keep adding to the same file - one log file per set name.

In any case, if separate log files are used, it will be easy to give 
instructors control over whether or not to have the logs.  If you are 
overwriting the log and keeping backups, the instructor can control how 
many backups to keep.  In both cases, just have entries for the 
variables in global.conf, and entries for them in Constants.pm for the 
configuation module.  Since the config module lets you enter 
documentation for the variable, it is easy to have/explain conventions 
like "this is the name of the file for logging ... no log entries are 
kept if this value is blank".

Some problems with having instructors control these values is that they 
may be unaware of the logs until they need it, at which point it is too 
late to turn it on.  If someone does tune it, they might as well turn it 
on with lots of backups.  There is no downside for the instructor - it 
is the person who runs the server who worries about disk space.

All in all, I would lean to using a custom entry for the activity log.  
It is part of why it is there, so why not make use of it.

John




Michael Gage wrote:

> A suggestion from Imre Tuba about safety backups for sets.  I'm not 
> sure exactly what happened but the result was the loss of the paths to 
> several files while trying to change the number of answers allowed.  
>
> We had something like this in WW1.9 since backups of set definition 
> files were automatically saved.  
> Any thoughts on how to implement this?
> In particular I worry that too frequent automatic backups run the risk 
> of overwriting a good backup with a succession of errors.
>
> Thoughts?
>
> Take care,
>
> Mike
>
> Begin forwarded message:
>
>> *From: *Imre Tuba <it...@mo... <mailto:it...@mo...>>
>> *Date: *October 25, 2005 11:31:08 PM EDT (CA)
>> *To: *Michael Gage <ga...@ma... 
>> <mailto:ga...@ma...>>
>> *Subject: **Re: Corrupted homework set*
>>
>>
>> Hi Mike,
>>
>> Thanks for the quick help. The log file you sent me must be for my 
>> other class (Math 2111), but I believe I managed to recover the 
>> problems partly from memory, partly based on the answer log.
>>
>> I understand that adding an undo feature will take quite some work. 
>> But here is a suggestion that should be easy to implement. Webwork 
>> could just automatically save a backup copy, or several backup copies 
>> of a homework set that is changed in the course directory. Then it 
>> would be quite easy to recover the last version. If you want to be a 
>> little fancier, you can let the user configure whether they want 
>> backups to be saved.
>> -- 
>>     Imre
>>
>
> "Only dead fish swim with the stream."
>
>

Re: [WWdevel] invisible (vs. unpublished) sets

[Michael G. <ga...@ma...>]

Hi Gavin,

I think there is some use in having having a set invisible implies  
that it cannot be worked on -- for example I've made sets invisible  
because there was a glitch in one
of the problems and I wanted to prevent further student frustration  
until I'd fixed the set.  So I didn't want them either seeing or  
doing the set.

If we have write   "is_a_gatewayquiz_set()" function (does this exist  
already)  we could pretty easily add something to the course  
configuration that
determines whether or not gateway tests are listed on the front page  
or not.  That wouldn't interfere with the current behavior of non- 
gateway sets
and I think would do what you want.  Invisible vs. visible wouldn't  
be involved at all.  An Invisible gateway set would not show up but  
would also not be doable.
Implementing it would involve some changes to ProblemSets.pm,  
global.conf and course.conf but not much else.

take care,

Mike


On Oct 26, 2005, at 9:03 AM, P Gavin LaRose wrote:

> Hi all,
>
> Here is an issue that has come up in my continued testing of the  
> Gateway module for WeBWorK.  Sets currently have a 'published'  
> characteristic, which determines whether (a) students can see the  
> set, and (b) they are allowed to work the set.  The distinction is  
> significant because of WeBWorK2's ability to directly go to a set  
> using a URL.
>
> In playing with Gateway testing, it occurred to me that I'd rather  
> not have proctored gateway sets (which students have to go to a lab  
> to take) show up in their problem set list.  (When they go to the  
> lab, they start from a page that points them directly to the  
> proctored test.)  One way of doing this is to make the set  
> unpublished, but then, according to rule (b) above, the students  
> should then also not be able to take it.
>
> So I'm curious whether you have an opinion about this: should  
> proctored gateway tests by default be invisible on the problem set  
> list page? Should the gateway test module ignore part (b) of the  
> unpublished description?  Should I give up on this and just have  
> the proctored tests show up in the set list?
>
> Thanks,
> Gavin
>
> p.s. FYI: currently, the set list for gateway tests appears  
> something like the following:
>   Take new DerivativeGW test          open, due 11/16/2005 at  
> 11:59pm EST
>   DerivativeGW (test1)         1/7     Sun Oct 23 21:30:28 2005
>   DerivativeGW (test2)         0/7     Mon Oct 24 08:15:49 2005
>   ProctoredDerivGW (test1)     0/7     Mon Oct 24 08:22:38 2005
>   ProctoredDerivGW (test2)     0/7     Mon Oct 24 08:23:33 2005
>
> The first is a link to take a practice test; the next two are  
> practice tests that have been taken and can be reviewed (and  
> checked, but not resubmitted); the last two are proctored tests  
> that have been taken and can be reviewed (and checked, but not  
> resubmitted).  The link that's omitted because the set is  
> unpublished is the "Take new ProctoredDerivGW test".
>
> -- 
> P. Gavin LaRose, Ph.D.  Program Manager (Instructional Tech.)
> Math Dept., University of Michigan
> gl...@um...                        "There's no use in  
> trying," [Alice]
> 734.764.6454                             said. "One Can't believe  
> impossible
> http://www.math.lsa.umich.edu/~glarose/  things." "I daresay you  
> haven't had
>                                          much practice," said the  
> Queen.
>                                                               -  
> Lewis Carrol
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by the JBoss Inc.
> Get Certified Today * Register for a JBoss Training Course
> Free Certification Exam for All Training Attendees Through End of 2005
> Visit http://www.jboss.com/services/certification for more information
> _______________________________________________
> OpenWeBWorK-Devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openwebwork-devel
>
>

Re: [WWdevel] Fwd: Corrupted homework set

[Arnold P. <ap...@ma...>]

<html>
<body>
At 11:44 PM 10/25/2005, Michael Gage wrote:<br><br>
In WW 1.9 important files which are backed up never overwrite older
backups.&nbsp; The successive backups have extensions .bak1, bak2,
etc.&nbsp; The same thing in done in WW 2 for the totals file.&nbsp; One
could do the same thing when sets are built, i.e. make a set def file and
make backups when something is changed.&nbsp; Maybe you can just create
the set def file when a set is assigned to at least one person and make a
new set def (and backup the old) when assigned sets are changed.&nbsp;
That way you don't make a lot of copies when a set is first being
built.&nbsp; This would also be useful in setting up new courses since
you often want to import set def but for this now someone has to remember
to first export the current assignment otherwise you might be copying an
out of date set def.<br><br>
The only draw back to this is that it might leave a lot of bak files
around.&nbsp; I think it would be a good idea to have a clean up function
that would delete all tmp files (for non active users) and bak files in a
course (WW 1.9 has this for tmp files, not bak files).&nbsp; I don't
think WW 2 has an easy way to do this for tmp files.&nbsp; This might be
something a prof could do for his/her course and a super user could do
for the whole WW 2 system.<br><br>
Another thing that should be able to be cleaned up is backups of .pg
files. I believe when editing a problem, the original is backed up and
then if any additional editing is done to that problem, the current
original is appended to the backup.&nbsp; At the end of a semester, there
is no real reason to keep these around.<br><br>
Arnie<br><br>
<br>
<blockquote type=cite class=cite cite="">A suggestion from Imre Tuba
about safety backups for sets.&nbsp; I'm not sure exactly what happened
but the result was the loss of the paths to several files while trying to
change the number of answers allowed.&nbsp; <br><br>
We had something like this in WW1.9 since backups of set definition files
were automatically saved.&nbsp; <br>
Any thoughts on how to implement this?<br>
In particular I worry that too frequent automatic backups run the risk of
overwriting a good backup with a succession of errors.<br><br>
Thoughts?<br><br>
Take care,<br><br>
Mike<br><br>
Begin forwarded message:<br><br>
<blockquote type=cite class=cite cite="">
<font face="Helvetica, Helvetica"><b>From: </b>Imre Tuba
&lt;<a href="mailto:it...@mo...">it...@mo...</a>&gt;<br>
<b>Date: </b>October 25, 2005 11:31:08 PM EDT (CA)<br>
<b>To: </b>Michael Gage
&lt;<a href="mailto:ga...@ma...">ga...@ma...</a>
&gt;<br>
<b>Subject: Re: Corrupted homework set<br>
</b></font><br><br>
Hi Mike,<br><br>
Thanks for the quick help. The log file you sent me must be for my other
class (Math 2111), but I believe I managed to recover the problems partly
from memory, partly based on the answer log.<br><br>
I understand that adding an undo feature will take quite some work. But
here is a suggestion that should be easy to implement. Webwork could just
automatically save a backup copy, or several backup copies of a homework
set that is changed in the course directory. Then it would be quite easy
to recover the last version. If you want to be a little fancier, you can
let the user configure whether they want backups to be saved.<br>
-- <br>
&nbsp;&nbsp;&nbsp; Imre<br>
</blockquote><br>
&quot;Only dead fish swim with the stream.&quot;<br><br>
</blockquote>
<x-sigsep><p></x-sigsep>
Prof. Arnold K. Pizer <br>
Dept. of Mathematics <br>
University of Rochester <br>
Rochester, NY 14627 <br>
(585) 275-7767<br>
</body>
</html>