« DevEdge Saved | Main | XForms On The Rise »
March 7, 2005
XPath in XUL Overlays
A short proposal of mine for using XPath in XUL Overlays on the Mozilla Wiki.
The idea is to make overlays more flexible as well as more readable. The proposal is a clean separation of the matching part of overlays and the actual content being added, making it easier to read overlaus imho.
Also, are blogs the best way to push wiki entries to the public? Should we make planet.mozilla.org post a summary of wiki additions each week perhaps?
Posted by doron at March 7, 2005 8:46 AM
Comments
Perhaps it should be done manually, though. Because although MediaWiki does provide RSS and Atom feeds listing newly-created pages ( http://wiki.mozilla.org/wiki?title=Special:Newpages&feed=rss ), as soon as the wiki gets somewhat busy, Planet starts getting polluted with lots of entries that many wouldn’t even care about.
So maybe it’s better to manually feature new pages *of note*, like Wikipedia’s Did you know? feature.
Posted by: Minh Nguyá»…n ![[TypeKey Profile Page]](http://weblogs.mozillazine.org/doron/nav-commenters.gif)
at March 7, 2005 12:58 PM
I agree with Minh: I'd love to know what's going on in the wikis without having to read them, but I don't want to know *everything* that goes on in them, just the important things.
Posted by: dolphinling at March 7, 2005 5:09 PM
How much overhead does adding XPath parsing add here over simple id-based matching, and how does that compare to the overhead from just matching an id anyway? XPath matching would be far more powerful, but you have to be at least considering how much overhead this adds to overlaying.
Posted by: Jeff Walden at March 7, 2005 5:11 PM
"How much overhead does adding XPath parsing add here over simple id-based matching, and how does that compare to the overhead from just matching an id anyway? XPath matching would be far more powerful, but you have to be at least considering how much overhead this adds to overlaying."
id-based matching should cost the same as simple XPath parsing. Our xpath code is pretty fast, and we wouldn't be removing the existing behavior, just adding more flexability.
Posted by: doron at March 7, 2005 6:37 PM