[sork] Patch for vacation forwards-driver (.forward-parser)

[Eric Rostetter]

Quoting Espen Jürgensen <espen at hhkol.dk>:

>> > However, there are some problems related to the way _getUserDetails
>> > exits, and these problems affect the parser. Currently, it seems like it

How do they affect which parser.

>> > is difficult to trigger an error. Even ftp errors do not get shown. I

What do you mean by "trigger an error" ?

>> > believe the problem is related to the structure of the driver, where
>> > _getUserDetails gets called twice.

The code hasn't changed much from back when it was only called once, so I
doubt it has anything to do it being called twice.

>> If $this->_details is set, then it'll just be returned, so you can set it
>> to
>> false or an empty array or what have you.

Yes, and in doing so, you can "return an error value".  Not sure how that
differs from "trigger an error" though.

> I have taken an extra look at how to trigger an error message from
> getUserDetails (in the Vacation module), and it seems to be a bit tricky.

Still don't know what that means, or what is trying to be accomplished.

> The whole design around Driver.php and getUserDetails doesn't really seem to
> allow an error to be triggered - or am I mistaken?

Not sure.  It allows you to return an error indicator.  But what you mean
by "trigger" I have no idea.

> It seems a bit odd, since
> there is plenty of error handling inside getUserDetails, but errors 
> just won't trigger any message.

The original use of the routine was just to check to see if it could tell
if you had set a vacation notice or not.  As such, it didn't need to display
any error messages, and would have been an incredible annoyance if it did.

It was then expanded to retrieve the user information to pre-fill in the
vacation info form.  Again, reporting errors here would be an annoyance
to the user really.

So there was never a need to produce any output for an error condition.
But it does provide error notice via the return value.

> I might be able to hack something together, which will show errors from just
> the parser, but it would be quite ugly.

Or, as perhaps should have been done before, there should be more than one
routine to handle these tasks?  And have each return display error information
or not as appropriate to its task?

> So my question is, if there is any general plan/idea on how to fix this?

I still not sure what "this" is so I have no general plan or idea on how
to fix it.

> Regards,
> Espen

--
Eric Rostetter
The Department of Physics
The University of Texas at Austin

Why get even? Get odd!