incubator-jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dirk Frederickx <dirk.frederi...@gmail.com>
Subject Re: help with v3.0.0-svn-200
Date Sun, 28 Feb 2010 09:33:59 GMT
SPAM

> 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.

>>>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?


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.

>>>one is missing from the AttachmentTab.jsp,  but I'm not sure whether this
jsp is still used.
>>>anyway, I run into the problem when using Install.jsp  (no reference here
to an errorPage) and Login.jsp (idem) Is this correct ?




> 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.

>>> 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.


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.

>>>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.

>>>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.




> 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.


dirk

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