jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Harry Metske <harry.met...@gmail.com>
Subject Re: help with v3.0.0-svn-200
Date Sun, 28 Feb 2010 08:25:08 GMT
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 .


2010/2/27 Andrew Jaquith <andrew.r.jaquith@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
> >> /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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message