Our current app has a lot of contexts tied to security features - for example content generated by going to a URL for '/area1/' is only visible to certain logged in users. Users who have access to pages in '/area2/' do not have access to pages from '/area1/'.
These servlets are configured in this way:<servlet-mapping> <servlet-name>dwr-invoker</servlet-name> <url-pattern>/area1/dwr/*</url-pattern> </servlet-mapping> <servlet-mapping> <servlet-name>area1</servlet-name> <url-pattern>/area1/*</url-pattern> </servlet-mapping> <servlet-mapping> <servlet-name>dwr-invoker</servlet-name> <url-pattern>/area2/dwr/*</url-pattern> </servlet-mapping> <servlet-mapping> <servlet-name>area2</servlet-name> <url-pattern>/area2/*</url-pattern> </servlet-mapping>This led to a problem involving DWR (version 3rc1). As different servlets require different authentication privileges, we use specific filters on each servlet to authenticate the user to make sure they have access; thus the DWR must be relative to these servlets so the filter is invoked. The dwr-invoker was configured in this way:
<servlet> <servlet-name>dwr-invoker</servlet-name> <servlet-class>org.directwebremoting.spring.DwrSpringServlet</servlet-class> <init-param> <param-name>debug</param-name> <param-value>true</param-value> </init-param> <init-param> <param-name>allowScriptTagRemoting</param-name> <param-value>true</param-value> </init-param> </servlet>Unfortunately, when it came to trying to access dwr objects, the _pathToDwrServlet property was stopping requests. Because the engine.js file is generated dynamically, on the first call to generate engine.js, it uses the current context to populate this value:
/** The default path to the DWR servlet */ dwr.engine._pathToDwrServlet = "/area1/dwr";A caching issue means that when the context is /area2/, this value is still present in engine.js, causing associated security exceptions and puzzled expressions from testers and devs alike. "So how do we get around this?" I hear you cry. Well I'll tell you.There is an init param when defining dwr-invoker called overridePath. This allows the _pathToDwrServlet to be a different value than the one obtained in the initial context. "But surely you need to know what context you'll need each time?" Not necessarily - add this code:
<init-param> <param-name>overridePath</param-name> <param-value>dwr</param-value> </init-param>which means that the path in engine.js is always:
/** The default path to the DWR servlet */ dwr.engine._pathToDwrServlet = "dwr";By giving this value a path that matches the start of the path used to import the engine.js and util.js scripts, it always picks up the correct context when making the call to DWR objects, avoiding any tricky security exceptions but using the correct current context! And it works for situations where you're in the top level context as well, just as the import statements do! It's as easy as pie. Mmmmmm, pie.
I discovered some superb mixes on soundcloud... let's see if posterous handles them differently to ordinary URLs.
Cyantific - Return of the Ghetto Blaster by Reprise AgencyOn the product I currently work on, we had a requirement for the site to be customisable in terms of branding and colour. Part of that was a series of icons in a navigation bar. They were to be of a fixed colour and be selected as part of a colour scheme, where the CSS was selected based on the domain key.
The original icons we had look okay and do the job.... to a point. Until we got asked for a new colour scheme to match the customers chosen colours. We got a contractor to make the icons, which he did. He even supplied a template file so we could make other sets. Fine, until we realised it was a Fireworks file, which can only be edited with Fireworks. "Can I have a Fireworks licence please?"
Export this as a png file to the location of your choice. You're done! You can now overlay these with white images to create icons - set the icon base you have created as a background to a div, position it, then position an image tag over this. Here it is at normal magnification (you can rob it if you just want red icons)
This carpenter ant (Camponotus leonardi) is caught in the throes of a fungus-induced death grip. It has clamped itself to a leaf 25 centimetres above a forest floor in Thailand, and died.
The reason is growing out of the back of its head. The reddish-brown stalk is made by a fungus called Ophiocordyceps unilateralis, which has invaded the ant's body and manipulated its behaviour. The exposed position is ideal for releasing spores.
It turns out this parasitic mind-control is at least 48 million years old. David Hughes of Harvard University and colleagues discovered fossilised leaves of this age in Messel, Germany that bore characteristic "death grip" scars, suggesting that ants once clamped themselves onto them.
It is the first time this sort of behavioural control has been discovered in the fossil record, and supports the idea that the ants and fungi have been locked in an evolutionary arms race for many millions of years.
Journal reference: Biology Letters, DOI: 10.1098/rsbl.2010.0521 (in press)
(Image: David Hughes)
Absolutely terrifying but undeniably amazing.
Another idea down the pan! A webOS client for delicious, the social bookmarking site. They even had the same name I came up with!
I _might_ have a look at the code anyway as it's open sourced, but I am wary of pitching in on someone else's project and ending up with loads of support requests or just doing all the work! This is meant to be a learning exercise after all.The search continues for another unique idea.Oh and I am blogging this on the bus from my Pre. Extremely liberating!