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
