Replies inline. :)
could indeed be that I had some double submits
in the javascript, the prevention double-submits has been
removed (eg.
disabling a submit button once it is clicked the first time ) why
is
that?
I took out the submitOnce() JS because double-submit protection is
accomplished elsewhere. First, the spam-protection code embeds a
unique form token that is checked when the form is processed. So if
the spam thresholds are set to require the token (and by default, they
are), it's treated as a validation error and triggers a CAPTCHA.
Second and perhaps more important, Stripes implements a redirect-after-
post pattern that means that you CANNOT actually post to the same
location (and ActionBean) twice.
So functionally, I felt we were probably taken care of. There may be
aesthetic reasons to use submitOnce(). If you feel that is the case,
we can talk about that.
one is missing from the AttachmentTab.jsp, but I'm not sure
whether this
jsp is still used.
AttachmentTab.jsp does not completely work -- it's really the only JSP
that hasn't been totally worked over (that's probably more appropriate
phrase here than "worked on" -- heh). After I get the WikiPath-slash
issue taken care of, I will fix this.
anyway, I run into the problem when using Install.jsp (no
reference here
to an errorPage) and Login.jsp (idem) Is this correct ?
Yes. That will be fixed also -- I have to work out a few kinks in the
error-handling code that we use with Stripes. I'll check this out.
I suggest to take it back at the top. The 'clutter' should be
minimal:
only one extra line with SAVE/CANCEL button and the change-note.
Alternatively, we could embed the buttons in the toolbar as well.
It just seems to me that putting the save button at the top of the
screen breaks the UI paradigm that we have elsewhere in JSPWiki. Every
other form has the save and cancel buttons at the bottom. On balance,
when I compared the two versions side-by-side (one with the buttons
and changenote on top, and one with them on the bottom), the latter
just looked cleaner. I'd suggest you try a side-by-side look for
yourself.
But, to be honest, this is something that is easily changed -- I won't
raise any more fuss if we move it back.
BTW, I would not support putting the save/cancel buttons in the
toolbar. That would be even less consistent with the UI paradigm.
Ok for the info tab.
However, I would prefer to avoid a server-roundtrip for the
attachment
tab.
It would be faster to toggle to the attachment tab to preview
some of the
attachments.
Especially during editing, when previewing attachments you don't
want to
be taken out of the edit session.
I agree, and for exactly the same reason you cited. If you'll take a
look at Edit.jsp you will will see that the attachment tab *is* loaded
when you are editing. It's just not loaded as part of the page when
VIEWING.
Alternatively, we could load the attachment tab through an AJAX
call,
without refreshing the page.
This keeps the initial page-size limited.
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.
Agree. Terminology may be confusing here.
"SKIN=RAW" is not an editor actually -- it just a way to view the
raw
markup of the page. (a link is avaible in the More dropdown)
Actually, the generation of the raw page content could be a
served from a
simple basic JSP as well, as part of the default template.
That makes sense -- maybe a popup window? The most straightforward
thing to do would be to pop a window and use a JSP as you suggest
(Raw.jsp?).
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.
The issue here is in the markup-to-html converter which generates
hardcoded the <a...> links.
Actually the generated link is ok.
However the generated <img ...> needs to be fixed.
As a fix, I suggest to remove the generated <img ..> completely;
and
resolve the presentation of external links completely in the
jspwiki.css.
(so it becomes skin-able as well)
I will commit a fix for this.
I agree. CSS is a much better way to handle this.
dirk
