If the sitemap could be specified as a function JRebel could reload it. One approach is along the lines that setSiteMap could be passed a function e.g. ()=>List[Menu]. In production mode the return value may or may not be cached. Another approach is to have an optional method in Boot called say buildSiteMap. If it's not defined you can build it imperatively in def boot. Or you can define buildSiteMap. In development mode it would be called on every page load. In production mode it could either be called once, or it could be called every time. Personally I see value in a dynamic, functional sitemap even in production, but it may impact performance (or not).
------------------------------------- Jeppe Nejsum Madsen<[email protected]> wrote: On Tue, Mar 9, 2010 at 12:08 PM, Timothy Perrett <[email protected]> wrote: > BTW, with SBT, don't forget you can do: > > jetty-run > (make changes to your code) > prepare-webapp > > That will redeploy chnaged files / classses to the running jetty instance so > development with SBT can still be slick without javarebel :-) But still this doesn't address the problem (I think?) of changing things in Boot. Maybe I code differently from everybody else, but when iterating new features, I always end up making lots of changes to Sitemap. And afaik everyone of those changes requires a restart.... For the rest I agree JRebel fits quite nicely (it does have it's problems as David points out) /Jeppe -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en. -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
