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 some attachment questions
Date Sat, 06 Mar 2010 21:17:16 GMT
Andrew, e.a.,

The latest version seems much improved.  I'm still seeing too many SPAM
issues being thrown when editing pages  --  do we have the SPAM-logic
somewhere documented  ?


Here are some new questions/issues, based on v3.0.0-svn-213.

1)
The handling of inline images/attachments seem not to function properly, but
probably I need to adjust links to jcr/priha ?
   <img> is not generated when just specifying the attachment name
[attach.png]
   <img> is generated when specfiying [page/attach.png]  but the rendered
link ".../attach/attach.png"  is not working.
???


2)
The attachment tab generates the list of attachments.
Normally jspwiki renders attachment links automatically with a
class='attachment'.   This label is used by slimbox to recognise which links
to decorate.
However, the current AttachmentsTab.jsp uses a stripes <s:link> tag, which
not automatically generates the correct jspwiki link.
I simply added the class in the jsp, which resolved the issue.  (ok)
But I was wondering why the <wiki:linkTo> is not used anymore, which
automatically  ensured that attachment links are generated consistently ?


3)
I was surprised to see that attachment links now end in a "?download="
string.
Is this behaviour correct ?
I will need to update the javascript which actually was relying on the
pattern of an image "src" attribute ending in  "...xxxxx.<image-type".


4)
JSON
I noticed that JSON calls, used by the new Stripes.submitFormEvent, requires
the 'evalResponse' to be set to 'true'.
This is because the ajax bean  returns a piece of executable javascript;
rather than a passive json object.
(this is generated via the Stripes "JavaScriptResolution" class.

I'd rather prefer that the server returns a passive JSON object, to avoid JS
injection security issues.
In this case, it should just return a simple string:  { result:"long string"
}  There is no need for more complex data passing.
WDYT ?


dirk

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