-
- 1. 이전 수정본을 보고 있는 상태에서 마우스 더블 클릭을 하면 해당 수정본 편집 화면으로 이동
-
-
- 1.1. wiki.pl 수정
-
- 1.2. 추가 업데이트 내역
-
- 1.3. 사용자 의견
-
1. 이전 수정본을 보고 있는 상태에서 마우스 더블 클릭을 하면 해당 수정본 편집 화면으로 이동
마우스 더블 클릭을 할 경우 페이지 수정 화면으로 이동을 하는데, 페이지의 최신 버전을 볼 때나 이전 버전을 볼 때나 더블 클릭하면 항상 최신 버전을 수정하는 화면으로 이동한다. 이게 아무래도 직관적이지 않은 것 같아서, 더블 클릭하는 시점에 보고 있던 버전을 수정하는 화면으로 이동하게 하였다. JuanmaMP의 의견 반영.
1.1. wiki.pl 수정
sub GetHtmlHeader {
...
if ($ClickEdit) {
if ($FreeLinks) {
$id = &FreeToNormal($id);
}
my $revision = GetParam('revision','');
if ( $revision ne '' ) {
$bodyExtra .= qq| ondblclick="location.href='$ScriptName${\(&ScriptLinkChar())}action=edit&id=$id&revision=$revision'" |;
}
else {
$bodyExtra .= qq| ondblclick="location.href='$ScriptName${\(&ScriptLinkChar())}action=edit&id=$id'" |;
}
}
...
}
1.2. 추가 업데이트 내역
Hi Raymundo, how are over there?
I notice under action "diff", double click is functional, but if a page has sections, there's no edit section link under action "diff". I think if double click is possible for edit, maybe must be appear edit section link, otherwise double click won't be possible for edition for action "diff" nor edit section link there will visible. Could I have explained?
- Maybe you're right, or maybe not.
Currently, the target link of "double-clicking" depends on the existence of "revision" argument in the current URL.
1) If a user is browsing the current revision of a page, double-clicking will bring the user to "edit current page"
2) If a user is browsing an old revision (say, for example, revision=3) of a page, double-clicking will bring him/her to "edit the content of revison 3"
(This is from your idea. Before you gave me it, double-clicking meant always "edit current page" for both cases)
However, I couldn't apply the idea to "edit section" feature. Let's assume this situation:
- A user is browsing an old revision (e.g. revision=3) of a page,
- Then, he clicks "edit section" link in the Heading "2.3"
Now the quesion is:
1) Should the user edit "section 2.3 of revision 3", or "section 2.3 of current revision"(It may not even exist)??
2) After he completes editing and clicks commit button, where should the content be inserted in the page? The content should be inserted in "current revision" of the page. But there is NO GUARANTEE that 'section 2.3 of revision 3' is same section 2.3 in the current revision.
So, I chose "NO edit-section link, when browsing OLD revisions"
I still don't know how to solve the question. So if I want to improve consistency, the only thing I can choose is to disable double-clicking for old revision.
Hmmm, I wanted to do refer to this one (not for editing section), for instance:
http://gypark.pe.kr/wiki?action=browse&diff=1&id=UseModWiki소스수정%2F이전수정본화면에서더블클릭&revision=3&diffrevision=2 What about define $ClickEdit = 0 on?
- You mean "disabling click-edit when URL contains "diff=" parameter. I'll consider later, now now.
About the other cuestion, allow editing for old section, I think is a good feature (always that user know what is really doing, sometimes editing an old section can be a good idea, thereby is a feature). Have i explained myself better?.
- I still don't know HOW I can implement it. Let me show you an example:
- "Sample" page's history is like this:
Revision 1: Revision 2:
== Section 1 == == Section 1 ==
content A content A
== Section 2 == == Section 2 ==
content B content C
== Sectino 3 ==
content B
(In revision 2, new content C is inserted between A and B)
- Now let's assume a user is browsing "revision 1" of "Sample" page. He sees:
== Section 1 [edit section 1] ==
content A
== Section 2 [edit section 2] ==
content B
- Then he would click "edit section 2" and edit the section:
-----(edit form)------
== Section 2 ==
content B', modified by him
----------------------
- Then he clicks commit button. Now, what should the revision 3 of this page be?
Revision 1: Revision 2: Revision 3:(expected) Revision 3:(in real)
== Section 1 == == Section 1 == == Section 1 == == Section 1 ==
content A content A content A content A
== Section 2 == == Section 2 == == Section 2 == == Section 2 ==
content B content C content C content B', modified (HUH?)
== Sectino 3 == == Section 3 == == Section 3 ==
content B content B', modified content B
- The user might have wished to improve "content B" and applied it to current page, but the result is losing content C and getting B as well as B'. Because wiki engine can't distinguish the user's intent. (Maybe it's in a scope of.. Artificial Intelligence or Text Analysis?)
- As you said, "user knows what he is doing". But wikiengine doesn't know what the user is doing.
I think now I Understand you: you prefer allow editing to the whole old revision, not for section. Isn't it?
- Yes :-), because I couldn't implement section editing of old revision, as I shows an illustration above.
- Yes, it could it be. I had not seen that. I am using a wiki with double click for reviews and old sections, too. My assumption was that the user assumed that editing of old section implies to be saved its "enviroment", it is saved with the other old sections; regardless if they are edited or not edited. But, strictly it is an assumption.
- I understand your rationale. Thanks for details. --JuanmaMP
- May I look around that wiki? Anyway, I see what you mean. In my illustration, revision 3 would be:
Revision 1: Revision 2: Revision 3:(JuanmaMP's)
== Section 1 == == Section 1 == == Section 1 ==
content A content A content A
== Section 2 == == Section 2 == == Section 2 ==
content B content C content B', modified
== Sectino 3 ==
content B
- Am I right? Well, that may be one of several implementation policies. Just I didn't choose it.:-)
- You're right. That is just what I have in mind when editing old revisions.
- In regard to my wiki, along some days, I can put on my homepage here, some snapshots with this subject treated here, and other "exotics" features. :)
- (Still it isn't mature so far, because I have pending exactly 100 major bugs or patchs, others 100 minor bugs or patchs, and 50 minor tweaks. It's still a wiki tangled and matted). But the snapshots is a good beginning. ;)
::: Best regards, --JuanmaMP
Other subject: where I can begin fix from to avoid in copy-paste urls like:
http://gypark.pe.kr/wiki/UseModWiki소스수정/이전수정본화면에서더블클릭, not become like: http://gypark.pe.kr/wiki/UseModWiki%EC%86%8C%EC%8A%A4%EC%88%98%EC%A0%95/%EC%9D%B4%EC%A0%84%EC%88%98%EC%A0%95%EB%B3%B8%ED%99%94%EB%A9%B4%EC%97%90%EC%84%9C%EB%8D%94%EB%B8%94%ED%81%B4%EB%A6%AD
For the time being, I have to paste in two steps, first, the latin characters, then paste korean characters beside it.
Thanks
- Hmm... what do you want exactly, the former form(with multibyte character) or the latter form(with %-encoded)? If you like the latter, use "Permalink" link in the bottom of every page. If you prefer the former... as far as I know, it depends on the behavior of web browser. Firefox always convert URL to %-encoded form. IE doesn't. I don't know how to control it.
- Really? Then, users that use, for instance, korean, chinese, japanese, only for that cause, have one more reason for browsing with Explorer. D'oh! --JuanmaMP
Hi, Raymundo,
I was having a look at URLs converted to percent enconding, and if I decoding (thanks to a snippet code from you: &DecodeUrl). I turn again to decoding at:
sub DoPostMain {
...
$string =~ s/$FS//g;
+ $string = &DecodeUrl($string);
$summary =~ s/$FS//g;
...
then WYSIWYG ! on textareas and saving texts, and urls goes well.
Otherwise, Don't touching the encoding saved texts, but,
sub BrowsePage {
...
- $fullHtml .= &WikiToHTML($Text{'text'});
+ $Text{'text'} = &DecodeUrl($Text{'text'});
+ $fullHtml .= &WikiToHTML($Text{'text'});
...
}
The first option (before) doesn't preserves the encoding but it's more eye-friendly. Heterodoxal, I guess.
Good morning.
- I'm sorry but I can't understand what the purpose of this patch is. Could you please explain or show me example about the difference between before and after this patch?
Of course. There's 3 snapshot.
In 1, I copy and paste url like this page.
In 2, after Preview, and with the patch.
In 3, after Preview, without the patch.
if there's url that mixes latin and korean characteres. Then it encodes to %-encoded form, as you know. With this patch, the characters are as I see them in the url (without %-encoded). Have I explained it better?.
The purpose is more eye-friendly if there's no side effects, and it can be applied functionally in other purpose, for example I need decoder for edit with double clic when the page is all korean characters, because encodes to %-encoded. But I see that this last don't happen to you. My core script is still based on Usemod, and I use to browse, Chromium. But the first effect (snapshot 3) still hapen from here with your website.
Now, the snapshots ...
Here: https://picasaweb.google.com/109809234853259868273/19DeJulioDe2012
- Ooops, I was thinking "Encode url" until now... Yeap, I see what you are saying now. :-D
I'm not sure what side effects this patch may bring, so I need time to consider it. But it is a good idea, I think. Thank you!
ok :)
위키위키분류