Hey,
I'm doing some effort to use the Resource Loader in the Maps extension. A problem I've run into is that I apparently cannot use things defined in another module that already loaded. What I'm doing is loading the OpenLayers library, and then another JS file that uses the OpenLayers library to create the actual maps on the page. After looking at this with Firebug, I guess it's a scope issue, as each module's contents is getting put in a function. Are there currently ways to correctly load such libraries? And if not, what would be a good way of creating this? Making a new class that derives from ResourceLoaderModule?
Cheers
-- Jeroen De Dauw * http://blog.bn2vs.com * http://wiki.bn2vs.com Don't panic. Don't be evil. 50 72 6F 67 72 61 6D 6D 69 6E 67 20 34 20 6C 69 66 65! --
You are probably assuming your code is running in the global scope. It's actually being wrapped in a closure. If you want to create a global variable or function you need to do so by adding it to the window object.
The old way:
var myVar = 1234; function myMethod() { alert( 1234 ); };
The new way:
window.myVar = 1234; window.myMethod = function() { alert( 1234 ); };
- Trevor
On 11/8/10 3:28 PM, Jeroen De Dauw wrote:
Hey,
I'm doing some effort to use the Resource Loader in the Maps extension. A problem I've run into is that I apparently cannot use things defined in another module that already loaded. What I'm doing is loading the OpenLayers library, and then another JS file that uses the OpenLayers library to create the actual maps on the page. After looking at this with Firebug, I guess it's a scope issue, as each module's contents is getting put in a function. Are there currently ways to correctly load such libraries? And if not, what would be a good way of creating this? Making a new class that derives from ResourceLoaderModule?
Cheers
-- Jeroen De Dauw
Don't panic. Don't be evil. 50 72 6F 67 72 61 6D 6D 69 6E 67 20 34 20 6C 69 66 65! -- _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Hey,
You are probably assuming your code is running in the global scope.
After looking at this with Firebug, I guess it's a scope issue, as each
module's contents is getting put in a function.
If you want to create a global variable or function you need to do so by
adding it to the window object. So in my use case this would mean editing the OpenLayers library?
Cheers
-- Jeroen De Dauw * http://blog.bn2vs.com * http://wiki.bn2vs.com Don't panic. Don't be evil. 50 72 6F 67 72 61 6D 6D 69 6E 67 20 34 20 6C 69 66 65! --
Well, you don't have to do that, there's a work around...
ResourceLoaderFileModule objects can have more than one script per module, just pass in an array for the scripts element. In this array you will first have the OpenLayers script, and then the another script you have written. Your script will just export some symbols like this...
window.myObject = myObject; window.myMethod = myMethod;
Can that work?
- Trevor
On 11/8/10 3:36 PM, Jeroen De Dauw wrote:
Hey,
You are probably assuming your code is running in the global scope.
After looking at this with Firebug, I guess it's a scope issue, as each
module's contents is getting put in a function.
If you want to create a global variable or function you need to do so by
adding it to the window object. So in my use case this would mean editing the OpenLayers library?
Cheers
-- Jeroen De Dauw
Don't panic. Don't be evil. 50 72 6F 67 72 61 6D 6D 69 6E 67 20 34 20 6C 69 66 65! -- _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Hey,
Using only a single resource module seems to fix the scope problem. However, the script is still breaking. For some reason I'm getting an error in the OpenLayers lib when I try to create a new Map object in my script, and code execution stops there. See line 56 in this file [0]. As far as I can tell, the code I have there is pretty equivalent to what I have in the old non-RL-using version, which is working. Any idea's there?
[0] http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/Maps/includes/ser...
Cheers
-- Jeroen De Dauw * http://blog.bn2vs.com * http://wiki.bn2vs.com Don't panic. Don't be evil. 50 72 6F 67 72 61 6D 6D 69 6E 67 20 34 20 6C 69 66 65! --
Well, if OpenLayers isn't attached to window then it won't work...
You need to use the technique I told you about and add this line to the script.
window.OpenLayers = OpenLayers;
- Trevor
On 11/8/10 3:54 PM, Jeroen De Dauw wrote:
Hey,
Using only a single resource module seems to fix the scope problem. However, the script is still breaking. For some reason I'm getting an error in the OpenLayers lib when I try to create a new Map object in my script, and code execution stops there. See line 56 in this file [0]. As far as I can tell, the code I have there is pretty equivalent to what I have in the old non-RL-using version, which is working. Any idea's there?
[0] http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/Maps/includes/ser...
Cheers
-- Jeroen De Dauw
Don't panic. Don't be evil. 50 72 6F 67 72 61 6D 6D 69 6E 67 20 34 20 6C 69 66 65! -- _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Hey,
Thanks, that works. I'd hoped there would be no need to have a modified version of the OpenLayers library though :(
Cheers
-- Jeroen De Dauw * http://blog.bn2vs.com * http://wiki.bn2vs.com Don't panic. Don't be evil. 50 72 6F 67 72 61 6D 6D 69 6E 67 20 34 20 6C 69 66 65! --
As I said, you don't need to modify it, just supplement it with an extra file which contains the code that adds the references to the window object. Then when creating your ResourceLoaderFileModule you do this
'scripts' => array( 'ext.maps.openLayers.js', 'ext.maps.openLayers.binding.js' ),
This will weld the two scripts together before throwing them in a closure.
- Trevor
On 11/8/10 4:12 PM, Jeroen De Dauw wrote:
Hey,
Thanks, that works. I'd hoped there would be no need to have a modified version of the OpenLayers library though :(
Cheers
-- Jeroen De Dauw
Don't panic. Don't be evil. 50 72 6F 67 72 61 6D 6D 69 6E 67 20 34 20 6C 69 66 65! -- _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Hey,
Next problem: One of the modules I'm loading contains a CSS file (part of the OpenLayers lib). The CSS points to a bunch of images, but they are not getting loaded. I guess this is a path issue, but am not sure how to confirm this / solve it. This is my module definition: http://dpaste.org/Pe1N/
Cheers
-- Jeroen De Dauw http://blog.bn2vs.com Don't panic. Don't be evil. --
The paths will be remapped so that relative paths in the CSS file will still work. Look at the paths in the output CSS and you should be able to see the issue quickly.
go to load.php?modules=ext.maps.openlayers&only=styles&debug=true on your wiki and you should see the CSS.
- Trevor
On 11/8/10 7:35 PM, Jeroen De Dauw wrote:
Hey,
Next problem: One of the modules I'm loading contains a CSS file (part of the OpenLayers lib). The CSS points to a bunch of images, but they are not getting loaded. I guess this is a path issue, but am not sure how to confirm this / solve it. This is my module definition: http://dpaste.org/Pe1N/
Cheers
-- Jeroen De Dauw http://blog.bn2vs.com Don't panic. Don't be evil. -- _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Hey,
Thanks again for the quick reply.
The image paths appear to be correct when I view the file via that url. What I'm seeing when I load an OpenLayers map is that some of the controls that consist out of images get displayed as "firefox image not found" images, and then disappear from the map. I asked about this on the OpenLayers IRC and people there agreed it was most likely a CSS issue. So anyone an idea what might be going wrong here?
Cheers
-- Jeroen De Dauw http://blog.bn2vs.com Don't panic. Don't be evil. --
Screen-shot of what I described in my last email: http://mapping.referata.com/wiki/File:Failmap.png
On 9 November 2010 05:51, Jeroen De Dauw jeroendedauw@gmail.com wrote:
The image paths appear to be correct when I view the file via that url. What I'm seeing when I load an OpenLayers map is that some of the controls that consist out of images get displayed as "firefox image not found" images, and then disappear from the map. I asked about this on the OpenLayers IRC and people there agreed it was most likely a CSS issue. So anyone an idea what might be going wrong here?
-- Jeroen De Dauw http://blog.bn2vs.com Don't panic. Don't be evil. --
2010/11/9 Jeroen De Dauw jeroendedauw@gmail.com:
Screen-shot of what I described in my last email: http://mapping.referata.com/wiki/File:Failmap.png
Can you link to the actual fail map instead of a screenshot so I/we can look at this in Firebug ourselves? I'm pretty sure /something/ is going wrong with image URL remapping here, but it's hard to figure out what unless I can see it fail in my browser.
Roan Kattouw (Catrope)
Hi! Is it possible to add client-side support for {{PLURAL}} in mediaWiki.msg() ? Or, that would be too complex, since different languages can interpret plurals in different ways. Dmitriy
It's in the roadmap and in process? Want to help?
- Trevor
On 11/9/10 11:00 AM, Dmitriy Sintsov wrote:
Hi! Is it possible to add client-side support for {{PLURAL}} in mediaWiki.msg() ? Or, that would be too complex, since different languages can interpret plurals in different ways. Dmitriy
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
* Trevor Parscal tparscal@wikimedia.org [Tue, 09 Nov 2010 11:01:47 -0800]:
It's in the roadmap and in process? Want to help?
I found the following notes in the linked from Roadmap article: http://www.mediawiki.org/wiki/ResourceLoader/Status
Port Michael's wikitext-in-JS code (for PLURAL and stuff)
It seems that Michael (Dale?) already wrote the code for that.
After looking at server-side Language classes, it seems that client-side plural either requires AJAX (which is really inefficient for messages), or, a much better approach is to make a set of JS language classes, similar to PHP classes, which is a larger work.
After looking at ResourceLoader code, it seems that message classes are here, for example I've found resources/mediawiki.language/languages/ru.js, which implements mediaWiki.language.convertPlural. However mediaWiki.msg currently ignores them.
I can match a plural with JS regexp and try to replace callback value by that mediaWiki.language.convertPlural() call, however I have the feeling that it's better to wait for trunk merge, instead of re-inventing something that will not be used.
It seems that ru.js mediaWiki.language.converPlural matches the logic of LanguageRu::convertPlural. I don't know any more languages. What can I do to help? Dmitriy
Well, we basically just need a template parser. Michael has one that seems to be working for him, but it would need to be cleaned up and integrated, as it's currently spread across multiple files and methods.
Do you like writing parsers?
- Trevor
On 11/9/10 10:25 PM, Dmitriy Sintsov wrote:
- Trevor Parscaltparscal@wikimedia.org [Tue, 09 Nov 2010 11:01:47
-0800]:
It's in the roadmap and in process? Want to help?
I found the following notes in the linked from Roadmap article: http://www.mediawiki.org/wiki/ResourceLoader/Status
Port Michael's wikitext-in-JS code (for PLURAL and stuff)
It seems that Michael (Dale?) already wrote the code for that.
After looking at server-side Language classes, it seems that client-side plural either requires AJAX (which is really inefficient for messages), or, a much better approach is to make a set of JS language classes, similar to PHP classes, which is a larger work.
After looking at ResourceLoader code, it seems that message classes are here, for example I've found resources/mediawiki.language/languages/ru.js, which implements mediaWiki.language.convertPlural. However mediaWiki.msg currently ignores them.
I can match a plural with JS regexp and try to replace callback value by that mediaWiki.language.convertPlural() call, however I have the feeling that it's better to wait for trunk merge, instead of re-inventing something that will not be used.
It seems that ru.js mediaWiki.language.converPlural matches the logic of LanguageRu::convertPlural. I don't know any more languages. What can I do to help? Dmitriy
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
* Trevor Parscal tparscal@wikimedia.org [Wed, 10 Nov 2010 00:16:27 -0800]:
Well, we basically just need a template parser. Michael has one that seems to be working for him, but it would need to be cleaned up and integrated, as it's currently spread across multiple files and
methods.
Do you like writing parsers?
Maybe my knowledge of MediaWiki is not good enough, but aren't the local messages only provide the basic syntax features like {{PLURAL:||}}, not a full Parser with template calls and substitutions? I never tried to put real template calls into messages. Rewriting the whole Parser in Javascript would be a lot of work. Many people have already failed to make alternative parsers fully compatible. And how would one call the server-side templates, via AJAX calls? That would be inefficient.
I am currently trying to improve my Extension:WikiSync, also I have plans to make my another extensions ResourceLoader compatible.
You know, my country is a kind of third world country (also I am living in not the most developed local area), so I am not rich, so I mostly code for customers, who use MediaWiki at their sites. They are kind enough to allow me to publish my extensions for free (GPL) at MediaWiki site and repository so these might be useful to someone else (I hope so).
I cannot afford to make _a_lot_ of free work (I'll run out of money). I realize that there are free volunteers at Wikimedia, some are really skillful. However, most of these come from more successful places, I think.
However, if the most of work has already been done, I can take a look, but I don't have the links to look at (branches, patches). I just don't know how much time would it take. Sorry. Dmitriy
2010/11/10 Dmitriy Sintsov questpc@rambler.ru:
- Trevor Parscal tparscal@wikimedia.org [Wed, 10 Nov 2010 00:16:27
-0800]:
Well, we basically just need a template parser. Michael has one that seems to be working for him, but it would need to be cleaned up and integrated, as it's currently spread across multiple files and
methods.
Do you like writing parsers?
Maybe my knowledge of MediaWiki is not good enough, but aren't the local messages only provide the basic syntax features like {{PLURAL:||}}, not a full Parser with template calls and substitutions? I never tried to put real template calls into messages. Rewriting the whole Parser in Javascript would be a lot of work. Many people have already failed to make alternative parsers fully compatible. And how would one call the server-side templates, via AJAX calls? That would be inefficient.
We're not looking for a full-blown parser, just one that has a few basic features that we care about. The current JS "parser" only supports expansion of message parameters ($1, $2, ...), and we want {{PLURAL}} support too. AFAIK that's pretty much all we're gonna need. Michael Dale's implementation has $1 expansion and {{PLURAL}}, AFAIK, and maybe a few other features.
I am currently trying to improve my Extension:WikiSync, also I have plans to make my another extensions ResourceLoader compatible.
I think {{PLURAL}} is an important feature for ResourceLoader, and if no volunteer wants to implement it, I think a staff developer should.
However, if the most of work has already been done, I can take a look, but I don't have the links to look at (branches, patches). I just don't know how much time would it take. Sorry.
I believe most of the work has already been done, yes, but I've never seen Michael's code and I don't know where it is (maybe someone who does can post a link?).
Roan Kattouw (Catrope)
On Wed, Nov 10, 2010 at 10:56 AM, Roan Kattouw roan.kattouw@gmail.com wrote:
We're not looking for a full-blown parser, just one that has a few basic features that we care about. The current JS "parser" only supports expansion of message parameters ($1, $2, ...), and we want {{PLURAL}} support too. AFAIK that's pretty much all we're gonna need. Michael Dale's implementation has $1 expansion and {{PLURAL}}, AFAIK, and maybe a few other features.
Actually PHP and JS are a bit similar. Different function names and slight syntax differences, but I think it is possible to take the existing PHP parser, strip out the references to MW internals and replace the database queries with appropriate API calls. That would also enable a "true" WYSIWYG editor or live preview at least, as having a JS parser will also allow that the resulting DOM nodes have some kind of "reference" attribute which can be looked at to find the wikitext responsible for the creation of the node (and so, enable inline editing). Actually, this seems just perfect for a GSoC project for next year: Port the MW parser to JavaScript, and a followup project to make a WYSIWYG/inline editor based on it.
Marco
On 10-11-10 02:55 AM, Marco Schuster wrote:
On Wed, Nov 10, 2010 at 10:56 AM, Roan Kattouwroan.kattouw@gmail.com wrote:
We're not looking for a full-blown parser, just one that has a few basic features that we care about. The current JS "parser" only supports expansion of message parameters ($1, $2, ...), and we want {{PLURAL}} support too. AFAIK that's pretty much all we're gonna need. Michael Dale's implementation has $1 expansion and {{PLURAL}}, AFAIK, and maybe a few other features.
Actually PHP and JS are a bit similar. Different function names and slight syntax differences, but I think it is possible to take the existing PHP parser, strip out the references to MW internals and replace the database queries with appropriate API calls. That would also enable a "true" WYSIWYG editor or live preview at least, as having a JS parser will also allow that the resulting DOM nodes have some kind of "reference" attribute which can be looked at to find the wikitext responsible for the creation of the node (and so, enable inline editing). Actually, this seems just perfect for a GSoC project for next year: Port the MW parser to JavaScript, and a followup project to make a WYSIWYG/inline editor based on it.
Marco
Sorry, but the differences between PHP and JS are more than you think. Besides /x you're going to run into a bit of pain where /s is used. And you'll be rearanging code a bit to cache RegExp's created through string concatenation. And there's the potential to be tripped up by associative arrays if the parser uses them.
And as for WYSIWYG, parsing is quite different, at least if you're sane enough to not want to re-run an extremely expensive parser like the MW one for every few character changes. And then there are extensions...
The parser is heavy... even if you take into account how efficient JS engines have become and the potential for them to be even faster at executing the parser than php is you don't want a heavy directly ported parser doing the work handling message parsing client side.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
* Daniel Friesen lists@nadir-seen-fire.com [Wed, 10 Nov 2010 05:54:51 -0800]:
Sorry, but the differences between PHP and JS are more than you think. Besides /x you're going to run into a bit of pain where /s is used. And you'll be rearanging code a bit to cache RegExp's created through string concatenation. And there's the potential to be tripped up by associative arrays if
the
parser uses them.
And as for WYSIWYG, parsing is quite different, at least if you're
sane
enough to not want to re-run an extremely expensive parser like the MW one for every few character changes. And then there are extensions...
The parser is heavy... even if you take into account how efficient JS engines have become and the potential for them to be even faster at executing the parser than php is you don't want a heavy directly
ported
parser doing the work handling message parsing client side.
PHP will never come to browsers. However, there is the way to bring Javascript to mod_php: http://pecl.php.net/package/spidermonkey It even has beta status, not alpha. Maybe even has a chance to be included to Parser? However, one should not expect to find it at "crippled" hosting. A good dedicated hosting / co-location is probably required to compile / setup it yourself (though a most of MediaWiki installations run from such hosting, not a crippled down ones).
The same language for server and client side would bring many advantages. Like you don't have to re-implement something complex twice in both languages, only the pars that are different for server / client. Dmitriy
The code is not spread across many files.. its a single mw.Parser.js file. Its being used in my gadget and Neil's upload wizard. I agree the parser is not the "ideal parser", its not feature complete, is not very optimised, and it was hacked together quickly. But it passes all the tests and matches the output of php for all the messages across all the languages. I should have time in the next few days to re merge / clean it up a bit if "no one else" is doing it.
It should be clear who is doing what.
The parser as is ... is more of a starting point than a finished project. But it starts by passing all the tests... If that useful we can plop it in there.
an old version of the test file is here. I have a ported / slightly cleaner version in a patch http://prototype.wikimedia.org/s-9/extensions/JS2Support/tests/testLang.html
it also includes a test file that confirms the transforms work across a sample set of messages. Its not clear to me how the current test files / system scales ... Mostly for Krinkle: The mediawiki.util.test.js seem to always include itself when in debug mode. And why does mediawiki.util.test.js not define an object by name "mediawiki.util.test" it instead defines "mediawiki.test"
also:
if (wgCanonicalSpecialPageName == 'Blankpage' && mw.util.getParamValue('action') === 'mwutiltest') {
Seems gadget like.. this logic can be done on php side no? Why not deliver specific test payloads for specific test entry points? if you imagine we have dozes of complicated tests systems with sub components the debug mode will become overloaded with js code that is never running.
--michael
On 11/10/2010 10:56 AM, Roan Kattouw wrote:
2010/11/10 Dmitriy Sintsov questpc@rambler.ru:
- Trevor Parscal tparscal@wikimedia.org [Wed, 10 Nov 2010 00:16:27
-0800]:
Well, we basically just need a template parser. Michael has one that seems to be working for him, but it would need to be cleaned up and integrated, as it's currently spread across multiple files and
methods.
Do you like writing parsers?
Maybe my knowledge of MediaWiki is not good enough, but aren't the local messages only provide the basic syntax features like {{PLURAL:||}}, not a full Parser with template calls and substitutions? I never tried to put real template calls into messages. Rewriting the whole Parser in Javascript would be a lot of work. Many people have already failed to make alternative parsers fully compatible. And how would one call the server-side templates, via AJAX calls? That would be inefficient.
We're not looking for a full-blown parser, just one that has a few basic features that we care about. The current JS "parser" only supports expansion of message parameters ($1, $2, ...), and we want {{PLURAL}} support too. AFAIK that's pretty much all we're gonna need. Michael Dale's implementation has $1 expansion and {{PLURAL}}, AFAIK, and maybe a few other features.
I am currently trying to improve my Extension:WikiSync, also I have plans to make my another extensions ResourceLoader compatible.
I think {{PLURAL}} is an important feature for ResourceLoader, and if no volunteer wants to implement it, I think a staff developer should.
However, if the most of work has already been done, I can take a look, but I don't have the links to look at (branches, patches). I just don't know how much time would it take. Sorry.
I believe most of the work has already been done, yes, but I've never seen Michael's code and I don't know where it is (maybe someone who does can post a link?).
Roan Kattouw (Catrope)
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 11/10/10 8:20 AM, Michael Dale wrote:
The code is not spread across many files..
I spent hours going over the code, and there were several points in the code that called out to other libraries. This was based on the patch you provided me.
I agree the parser is not the "ideal parser", its not feature complete, is not very optimised, and it was hacked together quickly.
Which is why I suggested it as a starting point
Essentially, Michael has solved some of this problem already, we just need to integrate it.
- Trevor
On 11/10/10 1:56 AM, Roan Kattouw wrote:
I think {{PLURAL}} is an important feature for ResourceLoader, and if no volunteer wants to implement it, I think a staff developer should.
Certainly staff members (me for instance) are already assigned this work. I was responding to a query about "what can I do". In short, you can help :)
- Trevor
Hey,
Can you link to the actual fail map instead of a screenshot so I/we can look at this in Firebug ourselves? I'm pretty sure /something/ is going wrong with image URL remapping here, but it's hard to figure out what unless I can see it fail in my browser.
Sure, the issue can be seen here: http://wiki.bn2vs.com/OpenLayers_map_with_RL
Cheers
-- Jeroen De Dauw http://blog.bn2vs.com Don't panic. Don't be evil. --
Your problem has nothing to do with CSS. The images that are not loading are actual <img> tags, and they are trying to find images in the /img/ folder, which means http://wiki.bn2vs.com/img/ in your case.
- Trevor
On 11/10/10 1:40 PM, Jeroen De Dauw wrote:
Hey,
Can you link to the actual fail map instead of a screenshot so I/we can look at this in Firebug ourselves? I'm pretty sure /something/ is going wrong with image URL remapping here, but it's hard to figure out what unless I can see it fail in my browser.
Sure, the issue can be seen here: http://wiki.bn2vs.com/OpenLayers_map_with_RL
Cheers
-- Jeroen De Dauw http://blog.bn2vs.com Don't panic. Don't be evil. -- _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Hey,
...are trying to find images in the /img/ folder...
So why is this, and how can it be fixed? It works when not using the RL...
Cheers
-- Jeroen De Dauw http://blog.bn2vs.com Don't panic. Don't be evil. --
2010/11/10 Jeroen De Dauw jeroendedauw@gmail.com:
Hey,
...are trying to find images in the /img/ folder...
So why is this, and how can it be fixed? It works when not using the RL...
Could you point me to the code that generates those <img> tags?
Roan Kattouw (Catrope)
Hey,
Could you point me to the code that generates those <img> tags?
No. That's all part of the OpenLayers library. I'll ask around on the OL IRC though :)
Cheers
-- Jeroen De Dauw http://blog.bn2vs.com Don't panic. Don't be evil. --
Hey,
I've send an email about this to the OpenLayers list, as this appears be to something that can not really be fixed by the RL.
Cheers
-- Jeroen De Dauw http://blog.bn2vs.com Don't panic. Don't be evil. --
@2010-11-09 05:51, Jeroen De Dauw:
Hey,
Thanks again for the quick reply.
The image paths appear to be correct when I view the file via that url. What I'm seeing when I load an OpenLayers map is that some of the controls that consist out of images get displayed as "firefox image not found" images, and then disappear from the map. I asked about this on the OpenLayers IRC and people there agreed it was most likely a CSS issue. So anyone an idea what might be going wrong here?
Background images in CSS files have paths relative to the CSS files. As Trevor said, those paths should be changed by RL, but probably something went wrong. To check to what path CSS points you can use Firebug (and point element with the image) or you can right click on the image and choose to copy image path (background image path in this case I guess). You might use non-relative paths (full URLs) to circumvent the problem.
Taking a wild guess here the problem might be because RL does not expect quotes around URL path. More URL variants here: http://www.w3.org/TR/CSS2/syndata.html#value-def-uri
Best, Nux.
ResourceLoader uses CSSMin::remap, which *should* work with double, single or non quoted URLs. There may be some strange syntax that it's tripping over though...
- Trevor
On 11/9/10 12:53 AM, Maciej Jaros wrote:
@2010-11-09 05:51, Jeroen De Dauw:
Hey,
Thanks again for the quick reply.
The image paths appear to be correct when I view the file via that url. What I'm seeing when I load an OpenLayers map is that some of the controls that consist out of images get displayed as "firefox image not found" images, and then disappear from the map. I asked about this on the OpenLayers IRC and people there agreed it was most likely a CSS issue. So anyone an idea what might be going wrong here?
Background images in CSS files have paths relative to the CSS files. As Trevor said, those paths should be changed by RL, but probably something went wrong. To check to what path CSS points you can use Firebug (and point element with the image) or you can right click on the image and choose to copy image path (background image path in this case I guess). You might use non-relative paths (full URLs) to circumvent the problem.
Taking a wild guess here the problem might be because RL does not expect quotes around URL path. More URL variants here: http://www.w3.org/TR/CSS2/syndata.html#value-def-uri
Best, Nux.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
wikitech-l@lists.wikimedia.org