Prism and TiddlySpot

[Weidner]

This question has been posed before, but I wasn't able to find a
resolution.

I've been playing with Prism recently and have found that I am not
able to use the "Save to web" feature of my TiddlySpot. I thought it
might be just my tiddlyspot, so I created a couple more to test with
and found that it doesn't seem to matter which version or plugins I'm
running, the save feature just doesn't work.

The same error is displayed on both XP and Vista (haven't tried it on
OS X or Linux) - "Error : Username or Password do not match". If I
download the TW, I am able to save it locally using "Save changes" in
the Sidebar.

I've checked and rechecked my upload username (txtUploadUserName in
AdvancedOptions) and tiddlyspot password in the Options dialog. Both
are correct - or at least the same as I type into Firefox - but the
error appears every time I try to save.

I'm fairly sure this will mean something to one of you gents, but I
don't know where to begin tracking this down... Looking at
AdvancedOptions; in Firefox, the pasUploadPassword field exactly
mimics what is seen in Options; in Prism, the pasUploadPassword field
is blank. In addition, several items show "(unknown)" instead of a
description in the Description column.

Thanks,
Steve W.

[spacev...@gmail.com]

Steve - for what it's worth, I'm having the same problem - scanned the
group,
but did not bother asking - just every now and then upload the TW via
firefox..... looking forward to one of the guru's cracking this
nut :-)
-Juergen

[Xavier Vergés]

Steve,
I would bet on missing UniversalBrowserRead privileges

If you have the inline javascript plugin
http://www.tiddlytools.com/#InlineJavascriptPlugin
this script, after asking for permission should list your privileges
for different urls
http://tiddlywiki.pastebin.com/f2c96f668

To get those privileges, you could edit user.js in prism's profile
dir.
This script could help; again, it will ask for your persmission
http://tiddlywiki.pastebin.com/f3bba2e0c

Warning: pure speculation... still on webrunner

-Xv

[Eric Shulman]

> If you have the inline javascript pluginhttp://www.tiddlytools.com/#InlineJavascriptPlugin

> this script, after asking for permission should list your privileges

> for different urlshttp://tiddlywiki.pastebin.com/f2c96f668

> To get those privileges, you could edit user.js in prism's profile
> dir.
> This script could help; again, it will ask for your persmissionhttp://tiddlywiki.pastebin.com/f3bba2e0c

Nice scripts!!!

I've adapted them for use as an instant bookmarklet (displayed via
alert() dialog box instead of wikified output)

http://www.TiddlyTools.com/#InstantBookmarklets

enjoy,
-e
Eric Shulman
TiddlyTools / ELS Design Studios

[Xavier Vergés]

Thanks!

Eric, I've noticed a bug and one inconsistency in the InlineScript
plugin

bug: when a label is provided, the wrong "place" is passed to _out().
The link is passed instead of the containing tiddler. This seems to
fix it.

link.code="function _out(place){"+fixup
+"\n};_out(story.findContainingTiddler(this));"

insconsistency/feature request:
when a label is provided, the return value is discarded. I tried to
work around this by using document.write(wikify*...) but I get quite
lost when dealing with the wikify* family. I understand the reasoning
about considering the return value the rc from a click handler, but
would it be possible to accept as the return value an object with the
click handler rc and something to be wikified like it is for unlabeled
scripts?

Thanks in advance for considering it.

-Xv

[Eric Shulman]

> bug: when a label is provided, the wrong "place" is passed to _out().
> The link is passed instead of the containing tiddler. This seems to
> fix it.
>
> link.code="function _out(place){"+fixup
> +"\n};_out(story.findContainingTiddler(this));"

This is NOT a bug, and is correct as-is. Inline scripts can occur in
NON-tiddler DOM elements (such as mainMenu, header, sidebar). The
"place" value that is used is the immediately containing element in
which the script is evaluated. For 'onclick' scripts, this element is
the 'link' itself (as you noted). This is BY DESIGN: it allows you to
directly reference or modify the link text to reflect any 'stateful'
conditions set by the script:

<script label="enable">
if (place.innerHTML=="enable") {
config.options.txtSomething="some value";
place.innerHTML="disable";
} else {
config.options.txtSomething="some other value";
place.innerHTML="enable";
}
return false;
</script>

Using document.write() doesn't actually make any sense in a TiddlyWiki
document and if it was left alone, it would *completely overwrite the
entire document*!!! As a convenience when pasting in scripts from
other sources, InlineJavascriptPlugin automatically converts
document.write() to "place.innerHTML=(...)" so that it won't corrupt
the document, but you should avoid using document.write() whenever you
can.

As you already know, to render wiki-syntax output for regular (non-
click) inline scripts you can simply return a text string containing
wiki-syntax.

> when a label is provided, the return value is discarded. I tried to
> work around this by using document.write(wikify*...) but I get quite
> lost when dealing with the wikify* family. I understand the reasoning
> about considering the return value the rc from a click handler, but
> would it be possible to accept as the return value an object with the
> click handler rc and something to be wikified like it is for unlabeled
> scripts?

The return code from an onclick script is NOT discarded! It is
returned directly to the browser that invokes the script.. and MUST be
a BOOLEAN (not a text string). This return value is usually equal to
FALSE, indicating that the click event was processed. This is
critically important for InternetExplorer. Without returning 'false',
IE will try to navigate away from the current document!!! If there
are tiddler changes, this triggers the 'unsaved changes' warning
message, and if there aren't tiddler changes it just makes an
unexpected 'page transition' sound (sometimes referred to as "IE click
disease")

To render output from 'onclick' scripts, you absolutely SHOULD use
wikify()... it's easy:

<script label="something to click on">
var out="... wiki-syntax content...";
wikify(out,place.parentNode);
return false;
</script>

Note the use of "place.parentNode" in the example above... as noted
above, "place" is the link text... and therefore "place.parentNode" is
the containing *element* in which that link text occurs, and
wikify(out,place.parentNode) appends content to THAT containing
element. Of course, if you want to append to the end of the
containing *tiddler*, you can always write:
wikify(out,story.findContainingTiddler(place));

By using the coding techniques described above, you should be able to
accomplish what you want without making changes to the plugin...
(which would BREAK all sorts of existing scripts!)

HTH,

[Xavier Vergés]

Eric, you should note that your docu does not reflect the important
differences beween how labeled and unlabel script behave.

I believe that the code in
http://tiddlywiki.pastebin.com/m4ea07f70
provides a much more consistent experience for the script writers, no
matter if they chose to label/defer or not their scripts. At least, I
think that you should add the "return false;" part in the exception
handler.

-Xv

[Eric Shulman]

> Eric, you should note that your docu does not reflect the important
> differences beween how labeled and unlabel script behave.

I will be updating the documentation shortly...

> I believe that the code inhttp://tiddlywiki.pastebin.com/m4ea07f70

> provides a much more consistent experience for the script writers, no
> matter if they chose to label/defer or not their scripts. At least, I
> think that you should add the "return false;" part in the exception
> handler.

Because InlineJavascriptPlugin is one of the most widely used
TiddlyTools plugins and, by its very nature, permits technically-
sophisticated people (such as yourself) to create complex and subtle
scripts to address very specific needs, I have to be extremely careful
to consider ALL possible use cases before I make ANY changes in how
things currently work.

My concern is that your suggestions will alter both the behavior and
the resulting DOM contents in ways that can potentially break existing
scripts:

* sometimes an onclick script does need to return TRUE (or at least
NOT return FALSE).

For example, this script dynamically sets its link's href to
automatically open an online document based on the current TW
username, except if the username is set to "YourName" (i.e., the
default value)

<script label="go to my online page">
if (config.options.txtUsername=="YourName")
place.href="http://www.example.com/login/";
else
place.href="http://www.example.com/
users/"+config.options.txtUsername
place.target="_blank";
return true; // allow browser to follow href
</script>

* onclick scripts current do not automatically *create* any DOM
elements. Dynamically inserting a "span" (NOT a "div" -- which would
force a linebreak in the output) could adversely effect any DOM-
relative scripting that follows it. For example, a regular inline
script could refer to "place.lastChild", but if an onlick script has
generated an extra DOM element, that script would have to be re-
written to refer to "place.lastChild.previousSibling"

Although I am hesitant to change the plugin implementation, your
suggestions DO have merit, and I will *very* carefully consider
them...

[Xavier Vergés]

>
> * sometimes an onclick script does need to return TRUE (or at least
> NOT return FALSE).

I don't think that nothing in the suggested change prevents this
behaviour. It is true that it would break scripts that return a string
intended to behave as a true rc for the click handler; but I would be
surprised if anyone is doing that on purpouse.

> Dynamically inserting a "span" could adversely effect any DOM-

> relative scripting that follows it.

To minimize the risks of breaking existing scripts,
-the "document.write(" could be changed into
"place.writtenByDocumentWrite.push("
-the new span would only be added after the link element when the
script returns, and only when
link.writtenByDocumentWrite.length != 0 or
the script returned a string to be wikified

> I will *very* carefully consider them...

Thanks for looking into it.

-Xv

[Xavier Vergés]

>
> I've adapted them for use as an instant bookmarklet (displayed via
> alert() dialog box instead of wikified output)
>
> http://www.TiddlyTools.com/#InstantBookmarklets
>

btw, I've learned that multiple persmissions can be requested with a
single call
netscape.security.PrivilegeManager.enablePrivilege("UniversalXPConnect
UniversalPreferencesRead U...
and you get only one popup

-Xv

[Weidner]

Hmm, no luck. I can't seem to locate either a "profile" directory or
user.js in the Prism directory tree.

I'm sure this is a n00b question, but how do I install/run your
scripts? I imported Eric's InstantBookmarklet to view the privileges,
but don't know what steps to take to use yours.

Sorry for the additional babysitting, and Thanks for your help,

Steve

On Feb 20, 1:50 pm, "Xavier Vergés" <xver...@gmail.com> wrote:
> Steve,
> I would bet on missing UniversalBrowserRead privileges
>

> If you have the inline javascript pluginhttp://www.tiddlytools.com/#InlineJavascriptPlugin

> this script, after asking for permission should list your privileges

> for different urlshttp://tiddlywiki.pastebin.com/f2c96f668

>
> To get those privileges, you could edit user.js in prism's profile
> dir.

> This script could help; again, it will ask for your persmissionhttp://tiddlywiki.pastebin.com/f3bba2e0c

[Xavier Vergés]

Hi Steve

user.js does not exists by default. It is a special file that you can
create in your mozilla app (firefox, prism...) profile dirs to set
preferences. Each app and each user has a different profile dir, with
a random name. More info at
http://kb.mozillazine.org/User.js_file
http://kb.mozillazine.org/Profile_folder

The scripts I linked to should help you avoid having to hand edit
user.js, and will ask for authorization to do it themselves. To run
them,
a) install Eric's
http://www.tiddlytools.com/#InlineJavascriptPlugin
b) for each of the scripts, create a tiddler, copying to it the code
in the script. When that tiddler is rendered, the script code will be
executed

(If I find the time during this weekend, I'd like to create a more
wizard-like plugin instead, so maybe it is worth waiting)

Also, keep in mind that I'm linking your real problem to lack of
privileges based only on pure speculation...

-Xv

[spacev...@gmail.com]

Steve - as I mentioned before, I had the same problems using Prism
and not being able to upload - I just uninstalled, downloaded and
installed again,
from here (http://labs.mozilla.com/featured-projects/ , the 'get
prism'
section), and it now works. I did not change anything in my settings
at all - just works.
Hope this helps you over the hump as well,
-Juergen

On Feb 21, 11:21 pm, "Xavier Vergés" <xver...@gmail.com> wrote:
> Hi Steve
>
> user.js does not exists by default. It is a special file that you can

> create in your mozilla app (firefox,prism...) profile dirs to set

> preferences. Each app and each user has a different profile dir, with

> a random name. More info athttp://kb.mozillazine.org/User.js_filehttp://kb.mozillazine.org/Profile_folder

>
> The scripts I linked to should help you avoid having to hand edit
> user.js, and will ask for authorization to do it themselves. To run
> them,

> a) install Eric'shttp://www.tiddlytools.com/#InlineJavascriptPlugin

> b) for each of the scripts, create a tiddler, copying to it the code
> in the script. When that tiddler is rendered, the script code will be
> executed
>
> (If I find the time during this weekend, I'd like to create a more
> wizard-like plugin instead, so maybe it is worth waiting)
>
> Also, keep in mind that I'm linking your real problem to lack of
> privileges based only on pure speculation...
>
> -Xv
>
> On Feb 22, 1:16 am, Weidner <SWeid...@gmail.com> wrote:
>
> > Hmm, no luck. I can't seem to locate either a "profile" directory or

> > user.js in thePrismdirectory tree.

>
> > I'm sure this is a n00b question, but how do I install/run your
> > scripts? I imported Eric's InstantBookmarklet to view the privileges,
> > but don't know what steps to take to use yours.
>
> > Sorry for the additional babysitting, and Thanks for your help,
>
> > Steve
>
> > On Feb 20, 1:50 pm, "Xavier Vergés" <xver...@gmail.com> wrote:
>
> > > Steve,
> > > I would bet on missing UniversalBrowserRead privileges
>
> > > If you have the inline javascript pluginhttp://www.tiddlytools.com/#InlineJavascriptPlugin
> > > this script, after asking for permission should list your privileges
> > > for different urlshttp://tiddlywiki.pastebin.com/f2c96f668
>
> > > To get those privileges, you could edit user.js inprism'sprofile
> > > dir.
> > > This script could help; again, it will ask for your persmissionhttp://tiddlywiki.pastebin.com/f3bba2e0c
>
> > > Warning: pure speculation... still on webrunner
>
> > > -Xv
>
> > > On Feb 5, 10:30 pm, Weidner <SWeid...@gmail.com> wrote:
>
> > > > This question has been posed before, but I wasn't able to find a
> > > > resolution.
>

> > > > I've been playing withPrismrecently and have found that I am not

> > > > able to use the "Save to web" feature of my TiddlySpot. I thought it
> > > > might be just my tiddlyspot, so I created a couple more to test with
> > > > and found that it doesn't seem to matter which version or plugins I'm
> > > > running, the save feature just doesn't work.
>
> > > > The same error is displayed on both XP and Vista (haven't tried it on
> > > > OS X or Linux) - "Error : Username or Password do not match". If I
> > > > download the TW, I am able to save it locally using "Save changes" in
> > > > the Sidebar.
>
> > > > I've checked and rechecked my upload username (txtUploadUserName in
> > > > AdvancedOptions) and tiddlyspot password in the Options dialog. Both
> > > > are correct - or at least the same as I type into Firefox - but the
> > > > error appears every time I try to save.
>
> > > > I'm fairly sure this will mean something to one of you gents, but I
> > > > don't know where to begin tracking this down... Looking at
> > > > AdvancedOptions; in Firefox, the pasUploadPassword field exactly

> > > > mimics what is seen in Options; inPrism, the pasUploadPassword field

[Xavier Vergés]

> I would bet on missing UniversalBrowserRead privileges

I would have lost the bet...

I have installed prism, set the appropiate privileges and the upload's
POST is failing. Daniel, Simon, would it be very difficult to look at
the logs for some light? Can I help with this?

-Xv

[Weidner]

I downloaded and sure-enough, version 0.9 works properly where 0.8
would not save.

Thanks!

On Mar 24, 8:02 pm, "spacevult...@gmail.com" <spacevult...@gmail.com>
wrote:

[Xavier Vergés]

That's odd! How did I manage to download prism 0.8 yesterday?!

Happy to be re-discover (because I was aware of this thread) that it
is a no issue!

Thanks!

-Xv