> I work on an application that undergoes weekly production releases, so > we've had to implement something very similar for both development and > production modes. There's just too high of risk if the user gets an out of > date version of the javascript.
I see. > The question is, what is the cost of having these two modes seperate? > keeping everything uniform makes debugging and troubleshooting easier as > well as having only one codebase to worry about. Why not *always* have this > behaviour? It's performance. I definitively would not want javascript etc to be reloaded all the time for Wicket applications. Something I could imagine - and maybe this is what you mean - is to ensure that all resources are refreshed whenever an application is restarted. I could think of something that would work with a UUID per application or something, in case headers wouldn't work. However, the problem with that is that it wouldn't work well with a cluster, unless we would know one master that communicates this id throughout the rest of the cluster, but I don't see how we can implement this as a framework feature. What are you thinking about, and how does RoR fixes this? Eelco ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
