Julius file isn't recompiled after adding a route #413

Closed
yogsototh opened this Issue Aug 24, 2012 · 5 comments

2 participants

@yogsototh

In the scaffolded site, if you add a @{SomeNewRouteR} in a julius file, the julius file isn't recompiled. The only way to work around this problem is to touch the handler calling this julius file. I am pretty sure this problem also hit cassius and lucius files.

I tried to look at the actual code which compute dependencies. It appears that the recompilation occurs only when modifying hamlet or source file. I believe the function to look at is determineDeps inside yesod/Build.hs:

go (Just (StaticFiles fp, _)) = getFolderContents fp                                                                    
go (Just (Hamlet, f)) = return [f, "templates/" ++ f ++ ".hamlet"]                                                      
go (Just (Verbatim, f)) = return [f]                                                                                    
go (Just (Messages f, _)) = getFolderContents f  

I would want to help, but I don't have a good idea for now on how to resolve this problem. As we should do something quite complex to close this problem. I mean, look for a hamlet widget call, then listing all files (hamlet, julius, cassius, etc...).
Then, inside the Devel detect whether one of those file had a new @{...} call.

On the other side a simple "hack" could resolve this. Simply looking at changes inside "templates/.{lucius,cassius,julius}.
And when the change contains a new @{...}, then simply grep the widget name inside Handler/
/.hs files, touch them. But I don't like this solution.

@snoyberg
Yesod Web Framework member

I'm planning on a fairly substantial rewrite of yesod devel to expose it as a library to make IDE access easier. One of my plans is to fix this annoyance and a few other related ones. The idea is:

  1. Expose helper functions from Cassius, Lucius, and Julius to get a set of all referenced identifiers in a template.
  2. yesod devel will track this information.
  3. Whenever a template is changed, check the referenced identifiers. If they remain the same, then do not recompile. Otherwise, touch the relevant Handler files and recompile.

If you're interested in helping with the coding on this, step 1 should be (relatively) easy.

@yogsototh

Hi Michael,

Yes, of course, I would be happy to help. Do you have any pointer to help me starting?
Or do you simply want me to write a function that take some text (hamlet/julius/cassius template) and return a set of symbol used. Typically, the @{..} but also the #{...}, the ^{...} and $if, ...

@snoyberg
Yesod Web Framework member

I don't think this is going to work for Hamlet. I've thought about it a bit, and the reason I haven't been able to implement hot-loaded Hamlet is that variables referenced from forall and maybe can have any arbitrary type that they wish.

So let's just focus on Lucius, Cassius, and Julius. There should already be the plumbing in place to get most of the information; what we need is a set of identifiers (not expressions) referenced from a template. So for:

alert("#{show 5}"); alert("#{foo bar "baz"}");

It should return the identifiers show, foo, bar.

I would recommend focusing on Julius first, it should be the easiest. I also have some ideas about unifying Cassius and Lucius.

@snoyberg
Yesod Web Framework member

OK, code is now on a separate branch that will support this feature. I'm waiting for the GHC API stuff to get merged into master before merging this code.

@snoyberg
Yesod Web Framework member

Addressed by pull request #446, closing.

@snoyberg snoyberg closed this Nov 2, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment