Re: help with v3.0.0-svn-200

[Andrew Jaquith <an...@gmail.com>]

Dirk --

I'd like to suggest an alternative to having a live preview "pane":
popping up the live preview in a separate window. That would allow the
user to put the window anywhere. It could also be one where the
contents are "pulled" from an autosaved version stored on the server.
(Which we need to do sooner or later anyway.)

The WYSIWYG editor would indeed be cool.

Andrew

On Feb 28, 2010, at 4:10, Dirk Frederickx <di...@gmail.com>
wrote:

> About the sneak-preview (or live-preview):
>
> 1) The preview is refreshed periodically, and not anymore when
> clicking
> outside the textarea element.
>
> 2) For v3.x, I'm working on a side-by-side view:  so you will be
> able to see
> the page preview next to the textarea.
>    A new button will allow you to switch between side-by-side or the
> previous vertically-stacked view.
>
>    Additionally I was considering to allow the left-menu to be
> collapsed
> (eg during edit) for an even wider view.
>
>
> Anyway, I think it is key that the live-preview is shown in the same
> screen
> as the editing.  You get immediate feedback of the entered markup.
>
>
> Additionally, I think it would be cool to also have a wysiwyg editor
> which
> immediately 'previews' the wiki-markup  ;-)
>
>
> dirk.
>
> On Sun, Feb 28, 2010 at 9:25 AM, Harry Metske
> <ha...@gmail.com>wrote:
>
>> I agree on the Preview issue with you Andrew, in 2.8 the preview does
>> require a lot of scrolling if your page is larger that half a screen.
>> So let's keep the tab and rename it to preview .
>>
>> regards,
>> Harry
>>
>> 2010/2/27 Andrew Jaquith <an...@gmail.com>
>>
>>> A few comments and clarifications below...
>>>
>>>>> - I get many SPAM errors, even when I'm logged in.  I should
>>>>> 'complete
>>> the
>>>>> challenge' but no challenge is presented.
>>>>> Any cure for that ?
>>>>>
>>>>>
>>>> I don't get them.
>>>
>>> I don't get them either, but I'd like to know what specific
>>> circumstances trigger them for you. The default spam settings (right
>>> now, at least) are very sensitive. A double-submit of a form, for
>>> example could trigger the spam detectors because of the "one-time"
>>> token we embed as a hidden form parameter.
>>>
>>> So, let me know what you do to make it happen, and I'll look into
>>> it.
>>>
>>>>> - During editing, I often get this message:
>>>>> "When you save this page, we will use your profiles e-mail {0}
>>>>> instead
>>> of
>>>>> the cookie value {1}. If you want to use {1} instead, change the
>> e-mail
>>>>> address in your profile"
>>>>> I've not seen this before.
>>>>>
>>>>
>>>> Me too, looks like a bug
>>>
>>> This was an attempt on my part ensure that when the user submits a
>>> page, the e-mail in their profile overrides any value they may have
>>> set in their cookies. We *always* use the profile value -- the
>>> message
>>> is meant to indicate that. However, I'm open to ideas on how to make
>>> this more natural. Maybe just ignore the cookie value? Leave the
>>> option to include an e-mail out?
>>>
>>>>> - ERROR.JSP has been moved inside the template, but mostly it is
>>>>> still
>>>>> referred from the root.
>>>
>>>> me too, is a bug
>>>>
>>>
>>> Whenever this happens, it is a bug. If it's in the JSP markup, that
>>> markup should use the JSTL syntax "${templates['Error.jsp']}" rather
>>> than "/Error.jsp". It's easy to fix, and if you encounter it I'd
>>> just
>>> ask that you commit a fix. I'll look for these myself, although I
>>> thought I'd eliminated them. This was a VERY recent change, so it is
>>> likely there are a few instance of this kicking around.
>>>
>>>>>
>>>>> - I noticed the "preview" functionality has been moved to the view
>> tab,
>>>>> while previously the live-preview was
>>>>> immediately visible below or next to the textarea input field.
>>>>> This requires an extra click if you wanna see the preview.  I'd
>> rather
>>>>> keep the original approach.
>>>>>
>>>>
>>>> +1
>>>
>>> I don't agree. The old sneak/live preview feature was pretty
>>> non-intuitive. It required you to click somewhere ("anywhere")
>>> outside
>>> of the textarea.
>>>
>>> The thought I had was this: if you have to click outside anyway to
>>> see
>>> the page preview, why not just click on a TAB? I "re-used" the View
>>> tab for this purpose... it essentially replaced the Preview.jsp from
>>> the JSPWiki 2.8. I think, in general, that using clicking a tab for
>>> previews is more natural because the rendered text has the same
>>> layout
>>> as the page you are editing, rather than a "squeezed" layout on the
>>> side, or below (which means lots of back-and-forth scrolling).
>>> Putting
>>> it on its own tab seemed nice and clean, and it uncluttered the
>>> editing interface.
>>>
>>> But, maybe we call the tab "Preview" instead to make the preview
>>> feature more obvious. Or put it in a pop-up window like Wordpress
>>> does.
>>>
>>>>>
>>>>> Also the save button and change-note are moved back below the
>>> edit-area,
>>>>> as it was in old jspwiki versions.
>>>>> Why go back ?
>>>>>
>>>>
>>>> +1 for moving (or copying) it to the top
>>>
>>> The UI at the top of the page was very cluttered: it had the save
>>> button, change-note, and toolbar. It seemed simpler and cleaner to
>>> have it at the bottom.
>>>
>>>>> - The "Edit" link (in view context) is now positioned between
>>>>> view and
>>>>> attachment.
>>>>>  Previous discussion on the position of the Edit link indicated
>>>>> that
>>> this
>>>>> was confusing may users.
>>>>>  Therefore it got positioned at the right of the screen was.
>>>>>  I suggest to keep that positioning as before.
>>>>>
>>>>>
>>>> don't care, but if we earlier agreed to keep it right, we should do
>> that
>>>
>>> I placed it next to "View" because of the preview change I made, as
>>> discussed above. But maybe we could put it all the way to the right
>>> (and add a Preview tab to the right of THAT). That would be fine
>>> with
>>> me.
>>>
>>> FYI: one thing that you may note as you peruse the new template JSPs
>>> is that I've deliberately broken up the tabs so that the "view"
>>> feature (eg., Wiki.jsp) only loads the View tab; the other tabs link
>>> to other JSPs e.g., PageInfo.jsp. That is deliberate -- I wanted to
>>> make generating view pages fairly lightweight. But if a user
>>> clicks on
>>> "Info" or "Attachments," then we load the other tabs and make them
>>> clickable via JavaScript. The user won't notice the difference.
>>>
>>>>> - Viewing the raw content of a page is not working anymore.
>>>>> Eg:  http: ... /Wiki.jsp?page=<page>&skin=raw
>>>>>
>>>>>
>>>> me too, looks a bug to me
>>>
>>> This is something I have not done yet. I didn't think it was needed
>>> for the beta. I don't understand what the "raw" editor really does,
>>> and I'm not really sure it is an "editor." What's the rationale for
>>> this feature? If it is needed, then of course we need to get it
>>> working. Whether we need it for Alpha, I don't know.
>>>
>>>>> - The <a class=external>..</a> external page link are still
>>>>> pointing
>> the
>>>>> /images/out.png.
>>>>> /images have been moved inside the template.
>>>>>
>>>>>
>>>>>
>>>> hmm, I get this (isn't that correct) : <img class="outlink"
>>>> src="/templates/default/images/out.png" alt="">
>>>>
>>>
>>> If this occurs, it is a bug. Any code that generates links to
>>> "standard" images should use TemplateManager.getResourceResolver()
>>> to
>>> obtain the path to the image. I thought I caught all of these, but
>>> if
>>> I didn't, please commit a fix.
>>>
>>> Andrew
>>>
>>