Knowing your own metadata
ScroogeMcPump
[such as] @author, @version, ... are ignored by the Greasemonkey
extension, but they can be read by human beings or other code."
My question is, how? How can a script be made aware of its own
metadata? Does anyone have sample code for this? And if so: Why
doesn't someone with access put it up on the wiki?
Stefan Petrea
177 function getMetaKeywords() {
178 var i;
179 var mt = window._content.document.getElementsByTagName("META");
180 for(i=0;i<mt.length;i++) {
181 var meta_tag=mt.item(i);
182 if( meta_tag.name.toLowerCase() == 'keywords' ) {
183 return meta_tag.content;
184 };
185 }
186 }
--
Stefan Petrea
homepage : http://perlhobby.googlecode.com/
mobile phone : +40732070179
Anthony Lieuallen
>> At <http://wiki.greasespot.net/Metadata_block>, it says, "Other Keys
> My question is, how? How can a script be made aware of its own
> metadata?
It doesn't necessarily say that _user scripts_ can read them. More
that, say, us.o could use them. Or a script that auto-updates could XHR
it, parse it, and see if the (version) number has changed since last update.
ScroogeMcPump
metadata in the // ==UserScript== block.
ScroogeMcPump
> It doesn't necessarily say that _user scripts_ can read them.
> Or a script that auto-updates could XHR it, parse it, and
locked away in what the JS interpreter thinks is a comment; that's why
the famous (but now broken) auto-update script forces everyone to
duplicate all this data in a JS object.
I was looking to incorporate a simpler auto-update routine into my own
script, but it seems ridiculous that there's a perfectly good spot for
this info that's totally inaccessible TO the script itself. (My
script's users already consider the process of installing Firefox,
installing Greasemonkey, and then installing my script to be
cumbersome; I think asking them to install yet another script would be
too much for some of their widdle minds to take.)
And on a related subject, how CAN I incorporate an auto-update routine
into my script without it artificially inflating my download stats on
us.o?
Stefan Petrea
there is a function called readFile here
http://perlhobby.googlecode.com/svn/trunk/firefox_toolbar_version_0.5/tuttoolbar_unziped/chrome/content/tuttoolbar.js
you can use that if you want but you will have to build the path to gm_scripts.
I believe it's possible for it to read it's own userscript block.
--
ScroogeMcPump
> there is a function called readFile
[1] Is an ordinary Greasemonkey script going to have sufficient
privileges to run code like this?
[2] Is an ordinary Greasemonkey script going to be able to figure out
its own location on the hard drive?
(If the answer to [1] is "yes", then I think [2] is information that
Gm should automatically make available to the script. OTOH, if the
contents of the // ==UserScript== block were automatically made
available to the script, none of this rigamarole would be necessary.)
Anthony Lieuallen
> [1] Is an ordinary Greasemonkey script going to have sufficient
> privileges to run code like this?
No.
> [2] Is an ordinary Greasemonkey script going to be able to figure out
> its own location on the hard drive?
Because of 1, no.
P.S.
========================================================
var metadata=<>
// ==UserScript==
// @name MetaData Grabber
// @namespace http://arantius.com/misc/greasemonkey/
// @description Get the @UserScript metadata for this script...
// @include *
// ==/UserScript==
</>.toString();
alert(metadata);
========================================================
ScroogeMcPump
> var metadata=<>
Dang, that's clever! I had no idea JS had a "here document" syntax!
I even downloaded the ECMA spec, and still found no mention of it - so
it's not surprising that no one thought of doing it that way before!
It'll take some tweaking with split() and stuff, but that'll
definitely work! Thanks!
Anthony Lieuallen
> On Jun 23, 1:56 pm, Anthony Lieuallen <arant...@gmail.com> wrote:
>> var metadata=<>
> Dang, that's clever! I had no idea JS had a "here document" syntax!
This is a sort of bastardization of E4X [1]. It's really a bare XML
node, which has text as its only child, so .toString() gets that text out.
[1] http://developer.mozilla.org/en/docs/E4X
> It'll take some tweaking with split() and stuff, but that'll
> definitely work! Thanks!
The GM code that parses the metadata is JS, so you can start from there.
Dan Phiffer
On Jun 23, 2008, at 9:14 PM, ScroogeMcPump wrote:
> On Jun 23, 1:56 pm, Anthony Lieuallen <arant...@gmail.com> wrote:
>
>> var metadata=<>
>
> Dang, that's clever! I had no idea JS had a "here document" syntax!
> I even downloaded the ECMA spec, and still found no mention of it - so
> it's not surprising that no one thought of doing it that way before!
Yeah, nice hack Anthony!
> It'll take some tweaking with split() and stuff, but that'll
> definitely work! Thanks!
Here's an attempt at parsing it further:
var metadata = {};
<>
// ==UserScript==
// @name Introspect
// @namespace http://phiffer.org/
// @description Simple introspection demo
// @include *
// ==/UserScript==
</>.toString().split('@').forEach(function(item) {
var key = item.match(/^(\w+)/);
if (key) metadata[key[1]] = item.match(/\s+(.+)/)[1];
});
John Plsek
script, you wrote the meta data, what's the point of complex coding to
get hard coded information much of which can be made useless information
by changing the includes/excludes in "Manage Scripts" page?
Vikas Pandey
I think he has a point. If we want to display something from our
metadata, then we can use such a variable name in our main script if it
has been possible for a variable to pick metadata.
often, we might like to show the name of the script or its description
or its location (where to download it from), or its rev num at the
places where the script is run. Sort of advertising.
Currently, one has to change manually everywhere, and if one misses
changing at some places, then the display will go wrong.
--
V
Matt Sargent
may not necessarily reflect what is seen in the script manager. I can
add and remove include/excludes, and these changes will not be revealed
by this technique. And I can go in and edit the script description, and
it would be detected by this technique, but not in the script manager.
Basically, you're dealing with a mix of both dynamic and static data,
and if a coder doesn't realize this, they're going to get some
unexpected results.
ScroogeMcPump
> Basically, you're dealing with a mix of both dynamic and static data
at this point are keys like @date or @version, which are not only not
manipulated by Gm, but totally ignored by it.
(I still think Gm should create a standard object where ALL of this
info - static, dynamic, or nonstandard - would be readable by the
script itself; but this hack will do nicely for what I want.)
Stefan Petrea
>
> On Jun 23, 12:52 pm, Stefan Petrea <stefan.pet...@gmail.com> wrote:
>
> > there is a function called readFile
> > [...]
> > you will have to build the path to gm_scripts.
>
> Okay, then that brings up two more questions:
> [1] Is an ordinary Greasemonkey script going to have sufficient
> privileges to run code like this?
I guess that's a TIAS.
If not,use the greasemonkey extension compiler,or modify the
greasemonkey.js to have this readFile function which it will
use in the script as the extension is capable of running this
kind of code.
> [2] Is an ordinary Greasemonkey script going to be able to figure out
> its own location on the hard drive?
Again see the first answer and also check out the greasemonkey compiler
script.
> (If the answer to [1] is "yes", then I think [2] is information that
> Gm should automatically make available to the script. OTOH, if the
> contents of the // ==UserScript== block were automatically made
> available to the script, none of this rigamarole would be necessary.)
> >
--
Stefan Petrea
Can't GM be modified for this or are you looking to use this with
an existing version of GM ?
John Plsek
that having the info only once as meta data is far neater - and besides,
it's a cool solution too ;)
ScroogeMcPump
> Can't GM be modified for this or are you looking to use this with
> an existing version of GM ?
ScroogeMcPump
> > > there is a function called readFile
> [...]
longer necessary.
Johan Sundström
> (I still think Gm should create a standard object where ALL of this
> info - static, dynamic, or nonstandard - would be readable by the
> script itself; but this hack will do nicely for what I want.)
Both a convenience GM API to get script headers and the whole script
source code as a string are things I want to add to Greasemonkey, but
I haven't quite come up with how I want them to behave with respect to
@require yet (at the moment those are not treated as headers, but they
should, to allow a library to require other libraries and resources
itself). There is some old discussion on the topic on greasemonkey-dev
if you search for GM_headers.
Prior to that happening, I would suggest using this hack instead of
those proposed, as they bug out if your @include or @exclude urls
contain a bare &, which isn't all unlikely:
var headers = parseHeaders(<><![CDATA[
// ==UserScript==
// @name Header parser
// @namespace http://ecmanaut.googlecode.com/
// @description A quick E4X hack
]]></>.toXMLString().split(/[\r\n]+/).filter(/\/\/ @/));
function parseHeaders(all) {
var headers = {}, name, value;
for each (var line in all) {
[line, name, value] = line.match(/\/\/ @(\S+)\s*(.*)/);
headers[name] = value;
}
return headers;
}
--
/ Johan Sundström, http://ecmanaut.blogspot.com/
ScroogeMcPump
> I would suggest using this hack instead of those proposed
we need toXMLString() instead of plain toString()? The XML code
really isn't relevant to the parsing and will get stripped out anyway,
so why bother to pass it in?
Also, in what I'm working on, I fold .split() and .filter() into the
parsing function - so that it can be reused elsewhere on data from
other sources with minimal duplication of code.
> There is some old discussion on the topic on greasemonkey-dev
> if you search for GM_headers.
zero dev experience here; I know @xpath would've simplified the coding
of my (one and only public) script... :-)
Johan Sundström
> On Jul 1, 3:14 am, "Johan Sundström" <oyas...@gmail.com> wrote:
>> I would suggest using this hack instead of those proposed
>
> Okay, I get how CDATA makes it better, but with that in place, why do
> we need toXMLString() instead of plain toString()? The XML code
> really isn't relevant to the parsing and will get stripped out anyway,
> so why bother to pass it in?
Feel free to shave off those three characters; the two amount to the
exact same thing. (Personally, I like to keep them around when I work
with E4X, as .toString() doesn't give the whole truth for cases like
<a href="...">oops</a>.toString(), but it matters less here.)
>> There is some old discussion on the topic on greasemonkey-dev
>> if you search for GM_headers.
>
> BTW, +1 on GM_headers, AND +1 on @xpath, too, FWIW from a person with
> zero dev experience here; I know @xpath would've simplified the coding
> of my (one and only public) script... :-)
Glad to hear it; the whole point with @xpath was usability for
everybody that *hasn't* spent the last ten years getting expert at
spanking the DOM to go their errands in short work. I have failed to
convince Anthony and Aaron it's a good enough idea, though.
Assuming I'm the only one working on GM_headers, I'm probably the
largest obstacle in front of that at the moment, as I haven't come up
with code good enough for it yet to be content myself -- there isn't
any oppossition to it, from what I recall. :-)
Maybe we should set up something akin to
http://userscripts.uservoice.com/ to probe the popularity of proposed
features and changes, and get some more influx of ideas in an
overviewable browsey manner for things like that. Won't likely
overrule any vetoes, but at least I would really love a more
approachable open air place than greasemonkey-dev and Trac.
(Would probably also be helpful to give myself a swift kick in the bum
to actually sweat out the API for it, implement and be done with it --
knowing that tons of people want the same thing you do is powerful
encouragement to work on it.)