incubator-jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Jaquith <andrew.r.jaqu...@gmail.com>
Subject Re: some attachment questions
Date Sat, 06 Mar 2010 23:30:45 GMT
> 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  ?

The org.apache.wiki.content.inspect package JavaDoc has the
documentation for the spam package. jspwiki.properties is where you
set the "weights" for each check. You can effectively turn spam
checking "off" by setting the threshold limit to something very low,
like -1000, that the score would never reach even if all inspectors
failed.

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

Dirk -- give me a quick step-by-step to reproduce this, and I will
take a look at it.

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

Yes. You can add a 'class' attribute to the s:link tag; that should
solve that particular problem.

I don't have any special attachment to s:link, except that it is
guaranteed to generate a valid link even if we change the URL scheme.
We should check wiki:linkTo to make sure it works this way, although
it SHOULD because it calls the URLConstructor which in turn uses the
same Stripes UrlBuilder that s:link calls.

If you get better results with wiki:LinkTo, we can use that instead.
(Though I'd like them both to work interchangeably.)

>
> 3)
> I was surprised to see that attachment links now end in a "?download="
> string.
> Is this behaviour correct ?

That link is not correct. If you omit the "event='download'" attribute
from s:link, it won't append the "?download=" (which is the Stripes
event name). Omitting the event attribute will make the ActionBean
link point to the default event, which (as it happens) is the
"download" event. So the event attribute can be safely omitted.

In general, attachment downloads are not working the way they should
at the moment, and this was something I was planning to fix soon. This
is related to the email I sent out about 2 weeks ago asking for
comments on WikiPath delimiters.

> I will need to update the javascript which actually was relying on the
> pattern of an image "src" attribute ending in  "...xxxxx.<image-type".

Well, I hope you don't have to. :)  Just try omitting the event
attribute from s:link, or use wiki:LinkTo.

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

I'm glad we are talking about this. I hoped we would sooner or later,
because you are our resident JavaScript guru. :)

The goal with Stripes.submitFormEvent was to cause a StripesActionBean
form event to be called, and to provide way for any errors or messages
(plus the response) to propagate back to the client. We call the
ActionBean event by submitting the form in the background (AJAX) and
supplying an event to execute. The response object has three
properties:
- the response itself (which for simplicity's sake I have been
assuming would ALWAYS be HTML)
- the "errors" string (which we generate in the same manner as the s:errors tag)
- the "messages" string (which we generate in the same manner as the
s:messages tag)

All three of these are concatenated together, wrapped in a <div>, and
injected into the div we want. That means any Stripes validation
errors or messages we get from the AJAX call are propagated back to
the browser. Neat, huh?

If you want to see this in action, by the way, just run the Installer
and try to configure the LDAP userdatabase. Because you (probably!)
don't have an LDAP server running locally, when you test the
connections you'll get an error. That error is propagated back and
displayed via Stripes.submitFormEvent.

Now, in terms of HOW that information is propagated back, I chose to
send back a JavaScript statement that could be eval'ed. This is
accomplished by the EventResolution class, which essentially wraps the
JavaScriptResolution response type, and does some nice formatting of
the errors and messages stuff. I did this because it was the simplest,
fastest way I knew how.

I don't really care how the information is propagated back to the
client. If JSON is easier, that's fine. I'd ask that if you do this,
please make appropriate changes to EventResolution and
Stripes.submitFormEvent so that we can do it everywhere.

Some suggested guidance if you want to change the "message transport" to JSON:

- EventResolution, NOW, wraps a JavaScriptResolution that emits the JS
object. You will, instead, want to wrap and return a
StreamingResolution that emits an JSON-notated object.

Here's the JavaDoc for StreamingResolution:
http://stripes.sourceforge.net/docs/current/javadoc/net/sourceforge/stripes/action/StreamingResolution.html

- If possible, I'd like to preserve the default client-side behavior
of Stripes.submitFormEvent -- where if there is NO callback function
supplied, the default behavior is to concatenate the errors, messages,
and response together and inject the whole thing into the target div.
But if there IS a supplied callback function, we call that instead
(which can do whatever it wants).

- If it makes sense, maybe the "response" property of eventResponse
should be a JavaScript object instead of a string? If so, the default
behavior of Stripes.submitFormEvent (when there is no callback method
supplied), should safely coerce the response JS object into a String.
(That is a guess...)

Does that make sense? Ultimately, I think we have a lot of flexibility here.

Andrew

Mime
View raw message