--
You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to lif...@googlegroups.com.
To unsubscribe from this group, send email to liftweb+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Thanks for the feedback:
@Stephen:
The solution works like a charm. I agree It's not very pretty but till PaulP implements a post-phase hook it will have to do :)
@both of you:
The only advantage I see of writing a compiler plugin over, say, an SBT task is that the compiler plugin is easily used with any build system and not just SBT. I use ant where I work and on our hudson instance so it's nicest for me if it could run it there as well :)
Also if we go further and extend the plugin (which would be very cool) with some more checks as described in point 3 in Stephen's mail it might be nice to have all the lift-specific checks gathered one place instead of spread across compiler plugins and build tool tasks :) Do you see any disadvantage to writing it as a compiler plugin besides the slight increase in complexity?
Another advantage of writing it as a compiler plugin is you get to write a compiler plugin ;) (Tautology ftw)
@Stephen:
The solution works like a charm. I agree It's not very pretty but till PaulP implements a post-phase hook it will have to do :)
@both of you:
The only advantage I see of writing a compiler plugin over, say, an SBT task is that the compiler plugin is easily used with any build system and not just SBT. I use ant where I work and on our hudson instance so it's nicest for me if it could run it there as well :)
Also if we go further and extend the plugin (which would be very cool) with some more checks as described in point 3 in Stephen's mail it might be nice to have all the lift-specific checks gathered one place instead of spread across compiler plugins and build tool tasks :) Do you see any disadvantage to writing it as a compiler plugin besides the slight increase in complexity?
Another advantage of writing it as a compiler plugin is you get to write a compiler plugin ;) (Tautology ftw)
On Mon, Dec 20, 2010 at 9:08 PM, Mads Hartmann Jensen <mad...@gmail.com> wrote:
@Stephen:
The solution works like a charm. I agree It's not very pretty but till PaulP implements a post-phase hook it will have to do :)
you should also try paul's sugesstion w/ subclassing Run. i am not sure what exactly this entails but it might yield a better solution
@both of you:
The only advantage I see of writing a compiler plugin over, say, an SBT task is that the compiler plugin is easily used with any build system and not just SBT. I use ant where I work and on our hudson instance so it's nicest for me if it could run it there as well :)
Also if we go further and extend the plugin (which would be very cool) with some more checks as described in point 3 in Stephen's mail it might be nice to have all the lift-specific checks gathered one place instead of spread across compiler plugins and build tool tasks :) Do you see any disadvantage to writing it as a compiler plugin besides the slight increase in complexity?
what about a case where people invoke snippets from 3rd party libraries / dependencies (do people do this / can you even do this?), ie classes which live in the classpath from some jar. with a compiler plugin. this wouldn't work, because you're requiring all snippets be defined in source code
another disadvantage is what about incremental compilation? i'm not really sure how this works in scalac, but i could imagine it only passing relevant classes through the compiler phases, in which case your plugin would throw a lot of false errors during these runs. that would be very misleading.
Another advantage of writing it as a compiler plugin is you get to write a compiler plugin ;) (Tautology ftw)
ya compelling point lol
Those arguments don't really rule out having the checks run as a plugin, they just rule out using the plugin system to find out available snippets, leaving the possibility of using some other technique like reflection, inside a compiler plugin.
--
You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to lif...@googlegroups.com.
To unsubscribe from this group, send email to liftweb+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
David, Unless you think it's an impossible task I'm going to take a swing at this - Not going for perfection the first time around :)
Just talked to Ross on IM and there's really no compelling reason to do it as a compiler plugin and it raises a lot of annoying issues.What I need is the following (if I remember correctly)- Access to LiftRules after instantiation- Access to all the jars that the project depends on & compiled classes- All the templates of the app
On Dec 22, 2010, at 12:18 PM, TylerWeir wrote:
> Mads, you're a beast!
>
On Dec 22, 2010, at 10:17 PM, TylerWeir wrote:
> You should:
> http://www.youtube.com/watch?v=9vvuLAl99ec
So I've been playing around with it a bit to create a proof of concept snippet linter. Here's some example output>
[warn] No snippet named 'FunctionalDictionary'. Invocation found in src/test/webapp/subfolder/test2.html
[warn] No snippet named 'Test'. Invocation found in src/test/webapp/subfolder/test2.html
I've just coded enough for the code to work together. Nothing works optimally yet and it can only validate a template if the snippet is declared in the project. The reason for this is because I have no idea how to figure out the fully qualified class name of a snippet invoked like this <lift:Snippet.render> so the best I can do is to try to prepend the package of the project and see if that class exists.
Just wanted to keep you updated.
Thanks,
Mads Hartmann
The reason for this is because I have no idea how to figure out the fully qualified class name of a snippet invoked like this <lift:Snippet.render> so the best I can do is to try to prepend the package of the project and see if that class exists.