Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Developping microsummary generator

3 views
Skip to first unread message

michaeljgru...@fastmail.fm

unread,
Nov 28, 2006, 11:37:22 AM11/28/06
to
Hi there,

I'm just getting to know a somewhat hidden gem in FF 2.0, the
microsummaries. I'm trying to replace some "notifier" extensions by
microsummaries (saving status bar real estate). It took me quite a while
until I realised that FF somehow caches the xml describing the generator
- but sometimes not (?). I thought my XPaths were wrong until I noticed
that FF (after a restart and forcing the mu-summaries to refresh) would
recreate the original xml after I edited the one in the
"microsummary-generators" subfolder of the profile. It even seemed that
part of my changes where taken over.

So: Where are generators stored, and what's the proper way to delete or
edit them? Does FF ever reload the generator from the url or uri
specified as an attribute to the generator element? How do I use
xsltproc or the like for testing a generator?

Michael

P.S.: I managed to style bookmarks according to a microsummary,
implementing the tinerstatus extension as a microsummary. If anyone is
interested I'll put some details online.

Myk Melez

unread,
Nov 28, 2006, 6:31:31 PM11/28/06
to michaeljgru...@fastmail.fm
michaeljgru...@fastmail.fm wrote:

> I'm just getting to know a somewhat hidden gem in FF 2.0, the
> microsummaries. I'm trying to replace some "notifier" extensions by
> microsummaries (saving status bar real estate). It took me quite a while
> until I realised that FF somehow caches the xml describing the generator
> - but sometimes not (?).

Firefox caches the generators on startup and keeps them cached until
shutdown. You can refresh the cache either by restarting Firefox or by
reinstalling the generator, which you can do programmatically using
nsIMicrosummaryService::installGenerator
<http://lxr.mozilla.org/mozilla/source/browser/components/microsummaries/public/nsIMicrosummaryService.idl#200>.


> I thought my XPaths were wrong until I noticed
> that FF (after a restart and forcing the mu-summaries to refresh) would
> recreate the original xml after I edited the one in the
> "microsummary-generators" subfolder of the profile. It even seemed that
> part of my changes where taken over.

It shouldn't happen that your changes to generator files get overwritten
(although it's possible for a generator file to get reinstalled if you
delete it--see below), so there may be a bug here. Can you provide more
detail about the sequence of steps you took and what happened?


> Where are generators stored, and what's the proper way to delete or
> edit them?

Generators are stored inside the profile directory within the
microsummary-generators subdirectory. The proper way to delete them is
to delete the file in that subdirectory corresponding to the generator
you want to delete. The simplest way to edit them is to edit that file
and then restart Firefox for your changes to take effect.


> Does FF ever reload the generator from the url or uri
> specified as an attribute to the generator element?

If you delete a generator file, but one or more bookmarks still use that
generator to generate their live titles, then Firefox will try once to
reinstall the generator by downloading it from its source URI.

If the reinstall succeeds, the generator file will reappear in
microsummary-generators directory, and the bookmarks will continue to
use it to generate their live titles. Otherwise, Firefox will make the
bookmarks start using their static titles.


> How do I use
> xsltproc or the like for testing a generator?

Currently, the best method I know of for testing a generator is to add a
bookmark using it and then reload the bookmark's live title via the
"Reload Live Title" command on the bookmark item's context menu.

When I develop generators, I generally edit the generator file in a text
editor, restart Firefox after making some changes, and then reload the
live title for my testing bookmark to see the effect of my changes.

But when I'm building an XPath expression for a generator, I use the
XPath Checker extension <https://addons.mozilla.org/firefox/1095/> to
develop the expression, as it immediately shows me the effects of my
changes. Then, once I have the expression selecting the appropriate
content, I add it to the generator.

I recognize that this is not as easy as it could be. I'd love to see a
good developer extension for creating and modifying microsummary generators.

For example, the tool might add an "editing" pane to the browser
interface which sits between the content pane and the tab bar. The pane
would be hidden by default, but it would appear when a developer
activates it.

The pane could contain a control for selecting the generator to edit (or
for creating a new generator), a textarea for editing the generator's
XML, a display area showing what the generator produces, and perhaps
some controls for generating XPaths from selected nodes on the page.

Perhaps the Microsummary Generator Builder extension
<https://addons.mozilla.org/firefox/3741/> could be extended to do this.


> P.S.: I managed to style bookmarks according to a microsummary,
> implementing the tinerstatus extension as a microsummary. If anyone is
> interested I'll put some details online.

Sounds intriguing. Please do describe this in more detail!

-myk

michaeljgru...@fastmail.fm

unread,
Nov 29, 2006, 11:05:51 AM11/29/06
to Myk Melez
Myk Melez venit, vidit, dixit 2006-11-29 00:31:
> michaeljgru...@fastmail.fm wrote:
...

>> I thought my XPaths were wrong until I noticed that FF (after a
>> restart and forcing the mu-summaries to refresh) would recreate the
>> original xml after I edited the one in the
>> "microsummary-generators" subfolder of the profile. It even seemed
>> that part of my changes where taken over.
>
> It shouldn't happen that your changes to generator files get
> overwritten (although it's possible for a generator file to get
> reinstalled if you delete it--see below), so there may be a bug here.
> Can you provide more detail about the sequence of steps you took and
> what happened?

I'm not sure I can reproduce this. I edited the xml inside the
generators folder with FF running; at some point FF even seemed to point
at the swap file my editor generated, according to the error console.

...


>> Does FF ever reload the generator from the url or uri specified as
>> an attribute to the generator element?
>
> If you delete a generator file, but one or more bookmarks still use
> that generator to generate their live titles, then Firefox will try
> once to reinstall the generator by downloading it from its source
> URI.
>
> If the reinstall succeeds, the generator file will reappear in
> microsummary-generators directory, and the bookmarks will continue to
> use it to generate their live titles. Otherwise, Firefox will make
> the bookmarks start using their static titles.

I see, this must have happened in my case. I installed a generator from
somewhere else and started editing it without changing the included url...

>> How do I use xsltproc or the like for testing a generator?

...


> But when I'm building an XPath expression for a generator, I use the
> XPath Checker extension <https://addons.mozilla.org/firefox/1095/> to
> develop the expression, as it immediately shows me the effects of my
> changes. Then, once I have the expression selecting the appropriate
> content, I add it to the generator.

I used that, too, but thanks for the hint. I was confused because the
expression which worked in that extension seemingly didn't work in the
generator.

> I recognize that this is not as easy as it could be. I'd love to see
> a good developer extension for creating and modifying microsummary
> generators.
>
> For example, the tool might add an "editing" pane to the browser
> interface which sits between the content pane and the tab bar. The
> pane would be hidden by default, but it would appear when a developer
> activates it.
>
> The pane could contain a control for selecting the generator to edit
> (or for creating a new generator), a textarea for editing the
> generator's XML, a display area showing what the generator produces,
> and perhaps some controls for generating XPaths from selected nodes
> on the page.

What I was thinking of: Since a generator is XSLT it should be possible
to run it (together with the web page it applies to) through an XSLT
processor. This would be the fastest developement cycle, at least for
me. I didn't succeed with "xsltproc" which we have here but I'm an XSLT
newbie, so my failure doesn't mean much.

>> P.S.: I managed to style bookmarks according to a microsummary,
>> implementing the tinerstatus extension as a microsummary. If anyone
>> is interested I'll put some details online.
>
> Sounds intriguing. Please do describe this in more detail!

OK, I put everything up at

http://aboutconfig.mozdev.org/stuff.html

including the generator and a screenshot. It describes one special use
but the concept should be quite general.

Having tool tips for overly long bookmarks would be nice, btw ;)

Cheers,
Michael

Dietrich Ayala

unread,
Nov 29, 2006, 12:26:58 PM11/29/06
to michaeljgru...@fastmail.fm, dev-apps...@lists.mozilla.org

michaeljgru...@fastmail.fm wrote:
>
> What I was thinking of: Since a generator is XSLT it should be possible
> to run it (together with the web page it applies to) through an XSLT
> processor. This would be the fastest developement cycle, at least for
> me. I didn't succeed with "xsltproc" which we have here but I'm an XSLT
> newbie, so my failure doesn't mean much.
>

I usually develop the standalone XSLT first, and debug it with xsltproc. Then I create the generator
after the XSLT development is done. This is much faster than having to continually re-install the
generator and restart Firefox. Try this:

xsltproc --html yourstylesheet.xsl http://www.foo.com/bar.html

Myk Melez

unread,
Nov 29, 2006, 5:01:19 PM11/29/06
to
michaeljgru...@fastmail.fm wrote:

> OK, I put everything up at
>
> http://aboutconfig.mozdev.org/stuff.html
>
> including the generator and a screenshot. It describes one special use
> but the concept should be quite general.

Wow, that's awesome!


> Having tool tips for overly long bookmarks would be nice, btw ;)

There are tooltips in the bookmarks toolbar and sidebar. In the
toolbar, the tooltip shows you the full title and URL of the bookmark.
In the sidebar, it just shows you the full title.

I'm not sure why these differ or why we don't have tooltips in the
bookmarks menu.

-myk

michaeljgru...@fastmail.fm

unread,
Nov 30, 2006, 5:08:12 AM11/30/06
to
Myk Melez venit, vidit, dixit 2006-11-29 23:01:
> michaeljgru...@fastmail.fm wrote:
...

>> Having tool tips for overly long bookmarks would be nice, btw ;)
>
> There are tooltips in the bookmarks toolbar and sidebar. In the
> toolbar, the tooltip shows you the full title and URL of the
> bookmark. In the sidebar, it just shows you the full title.
>
> I'm not sure why these differ or why we don't have tooltips in the
> bookmarks menu.

What I meant was: tooltips for items in a bookmark toolbar folder. The
tooltips are shown for items right on the toolbar, but not for the ones
in a folder.

Michael

P.S.: Hooray, trees are closed, 1st chance to check that my code works
for closed trees ;)

michaeljgru...@fastmail.fm

unread,
Nov 30, 2006, 5:25:16 AM11/30/06
to Dietrich Ayala
Dietrich Ayala venit, vidit, dixit 2006-11-29 18:26:

This is mostly what I tried, although I didn't know xsltproc accepts
urls - cool. It turned out I need to feed the content of the transform
element to xsltproc, not the element itself ;)

Still, the result of xsltproc differs in one respect from the result of
the generator (it can't parse the tree name); it complains about the
HTML structure, too. Maybe it's an old version (libxml 20617, libxslt
10112 and libexslt 810).

Michael

michaeljgru...@fastmail.fm

unread,
Nov 30, 2006, 8:33:03 AM11/30/06
to
michaeljgru...@fastmail.fm venit, vidit, dixit 2006-11-30 11:25:
...

> Still, the result of xsltproc differs in one respect from the result
> of the generator (it can't parse the tree name); it complains about
> the HTML structure, too. Maybe it's an old version (libxml 20617,
> libxslt 10112 and libexslt 810).

Well, I noticed that the tinderbox status pages begin with two <html>
elements which confuses xsltproc... Also, it gets confused by HTML tags
within javascript strings (taking them as if they were within the html)
and by unquoted URLs (in anchor hrefs) with ampersands. The w3c
validator report 3043 errors against HTML 4.01 Transitional for the
Firefox tinderbox status page. Oh well...

Michael

0 new messages