Fr Sep 10 2010 10:35:26 EDT von samjam @ Uncensored Betreff: Edit drafts, was Re: others messages
Fri Sep 10 2010 9:51:16 am EDT EDT from dothebart @ Uncensored Subject: Edit drafts, was Re: others messages
Fr Sep 10 2010 08:32:44 EDT von samjam @ Uncensored Betreff: Edit drafts, was Re: others messages
Fri Sep 10 2010 7:49:21 am EDT EDT from samjam @ Uncensored Subject: Re: others messagesWe'll have to revert Wilfried's modifications to drafts in "82932fb6b663050ba7812555ddfb526a4fbe98b0" described as "Modification: use force_room instead of creating a new solution" because force_room changes room before reading the message out of the current room. I'll supply a fix for that soon.Well... I'm not sure about that either. Perhaps Wilfrieds answer is best, but then we need an option to explicitly load a message out of the non-current room.
Certainly we can't have tmplput_EDIT_MAIL_BODY() change the room, because a browser refresh would then fail to load the message from drafts as the room will have been changed.
Perhaps the answer is for tmplput_EDIT_MAIL_BODY() to be told the original room as well as message number so that it can read the message from that room by temporarily changing back to the room (after the force room) and then changing back to the force room again.
force-room is the room to enter when posting the message (not neccesarily the one to load the cited message from...) you'd probably have to override the current logic in case of having that header in a mail..
The original room is a header sent with the MSG4 primary answer?
If the X-Citadel-Room header is set, then we go to this room, otherwise we go to _MAIL_ - but, only after fetching the message.
in that case just register a handler to it, add a conditional that returns whether its set or not, and a tmplput that puts it into the template
If tmplput_EDIT_MAIL_BODY() will issue the GOTO to go back to the room containing the message to be edited in order to get the message(after the force room; or for the case where the user clicks refresh) then the message must not come from a password protected room or the user would have to enter their password again.
So we need to be able to get the message to be edited before we change rooms (meaning we can't use force_room, but it seems wrong for a templ_put function to change room).
But if the user then clicks refresh on the browser we will have already left that room and won't be able to fetch it again. If the room whose message we are editing is a password room, we won't be able to go back to that room to get it. Maybe we can add something to the session to allow that message to be reloaded even if we are in the wrong room.
Sam, have a look:
Fr Sep 10 2010 10:35:26 EDT von samjam @ Uncensored Betreff: Edit drafts, was Re: others messages
Fri Sep 10 2010 9:51:16 am EDT EDT from dothebart @ Uncensored Subject: Edit drafts, was Re: others messages
Fr Sep 10 2010 08:32:44 EDT von samjam @ Uncensored Betreff: Edit drafts, was Re: others messages
Fri Sep 10 2010 7:49:21 am EDT EDT from samjam @ Uncensored Subject: Re: others messagesWe'll have to revert Wilfried's modifications to drafts in "82932fb6b663050ba7812555ddfb526a4fbe98b0" described as "Modification: use force_room instead of creating a new solution" because force_room changes room before reading the message out of the current room. I'll supply a fix for that soon.Well... I'm not sure about that either. Perhaps Wilfrieds answer is best, but then we need an option to explicitly load a message out of the non-current room.
Certainly we can't have tmplput_EDIT_MAIL_BODY() change the room, because a browser refresh would then fail to load the message from drafts as the room will have been changed.
Perhaps the answer is for tmplput_EDIT_MAIL_BODY() to be told the original room as well as message number so that it can read the message from that room by temporarily changing back to the room (after the force room) and then changing back to the force room again.
force-room is the room to enter when posting the message (not neccesarily the one to load the cited message from...) you'd probably have to override the current logic in case of having that header in a mail..
The original room is a header sent with the MSG4 primary answer?
If the X-Citadel-Room header is set, then we go to this room, otherwise we go to _MAIL_ - but, only after fetching the message.
in that case just register a handler to it, add a conditional that returns whether its set or not, and a tmplput that puts it into the template
If tmplput_EDIT_MAIL_BODY() will issue the GOTO to go back to the room containing the message to be edited in order to get the message(after the force room; or for the case where the user clicks refresh) then the message must not come from a password protected room or the user would have to enter their password again.
So we need to be able to get the message to be edited before we change rooms (meaning we can't use force_room, but it seems wrong for a templ_put function to change room).
But if the user then clicks refresh on the browser we will have already left that room and won't be able to fetch it again. If the room whose message we are editing is a password room, we won't be able to go back to that room to get it. Maybe we can add something to the session to allow that message to be reloaded even if we are in the wrong room.
Sam, have a look (from this message editing thing i'm just using):
<input type="hidden" name="force_room" value="Citadel Development">
its just posted to the server. If you add an attachment, the message isn't reloaded from the server, but you'll rather get the stuff you just posted next to the upload back into your edit window.
Once you press 'send' it will go to that room, and post the message from there.
(ok, we have one cavehat here: the post button is labeled differently depending on the view of the room, which probably won't work out in some cases, but I realy think we can live with that)
if, instead of THISROOM:NAME (is it? didn't look..) you offer a way to go to CITEROOM instead aren't we just done with it?
please correct me if i'm wrong.
