Re: [Fle3-dev] Open Bugs

[janne . pietarila]

On Thu, Jul 25, 2002 at 02:28:31PM +0300, Tarmo Toikkanen wrote:
> On 25.07.2002, 12:06:05, Bo Granlund wrote:
> >Moi,
> >
> >I think this can be generalized so, that any such information that
> >is stored as a loose pointer reference to some real zope object,
> >should be handled nonfataly. I.e. if it doesn't exist, try to ignore
> >it, if ignoring would not make sense, try to cleanup, and only after
> >that should an error go back, or something. Assertions are ok in
> >development usage, but they should all be disabled in production
> >version......
> >
> >I guess there are quite a few places where this applies.
> 
> Right. Specifically we need to address bugs #803 and #804, which both
> stem from this same issue - removing a course leaves references and
> link lingering.

I think that my last commit to CourseManager.py fixes #803: I changed
return_course_id_for_user() to check that the course really exists (if
not, it returns course_id for some other course where user is a
participant). Methods redirect_to_kb_on_some_course() and
redirect_to_jm_on_some_course() both call the method mentioned above
so _if_ they are the only methods through which we access the active
course, the problem is solved.

About bug #804 : I can't see how it could be related to state_url,
because all we store to UserInfo objects is just one mystical string (
we do _not_ store any references).

> Janne, could you fix the state_url code? All course specific
> references from the URL and from server should be removed as
> appropriate. Probably we shouldn't try to do this when a course is
> being removed,

I agree, that would be quite impossible.

> but rather use exception handlers whenever we try to
> look up stuff from a course based on the state. An error will cleanly
> and quietly remove the reference from state.

If we talk about the general problem, I think there are at least three 
different ways to solve the problem:

1) Any code that fetches data from state_url should check if it
   is still valid. (The route I took in my solution above.)

2) At the beginning of the each DTML page check that state in the URL is
   really valid, and if not, redirect to same page but with fixed 
   state_url. I think this is ugly and slow.

3) At the moment the state is really stored only in the URL (UserInfo
   is just a backup.) and the class State does not have any state
   information (just methods). We could rewrite State to store several
   states and use state_url in the URL as a key to access them. The 
   validity of state could be then checked at the start of each page or 
   something...  but we wouldn't have to do any redirect.
   If we don't take into account the validity check, this would make
   state handling faster, but would require many changes in the code and
   I am not sure whether they are worth the effort, considering that 
   Zope3 is supposed to have built-in state handling.

I would choose the solution number 1. If that is OK by you, I will go
through the code next week and try to find all the places that need
that fix. Opinions?

-- 
Janne Pietarila