>  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?


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
Wicket-user mailing list

Reply via email to