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 <[email protected]> > 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 >
