Closed GoogleCodeExporter closed 8 years ago
Hi Pascal, unfortunately I'm not that familiar with Play! so I don't completely
understand the motivation behind this change. It seems potentially problematic
to me because the plovr server intends to be RESTful where the first part after
the path is always the command:
/input
/compile
/modules
etc.
It seems like your change would break this pattern. In particular, it would be
harder to look at a plovr URL and be able to immediately tell what it does.
What is it about Play! that necessitates this change?
Thanks,
Michael
Original comment by bolinf...@gmail.com
on 1 Feb 2011 at 4:48
Basically, we want to "bridge" plovr through Play! in order to mix fast web
development tools brought by Play in Java and the power of google closure
tools.
I wrote a first simple module for Play+GoogleClosure just doing SOY "on the
fly" compiling. It allowed using just simple closure templating in a very
quick&iterative way.
Then, Dallan proposed to integrate plovr in this Play! module and provided the
first implementation. It allows to get plovr content through play and manages
several plovr configurations depending on whether you are in a dev or a prod
environment.
So in our Play integration, plovr is not a standalone server, it is used as a
library and we use it as a "closure content enabler for Play".
Thus, as plovr is not a "frontend", I just want people to be able to use any
trivial and generic url such as "/input/" or "/compile/" or "/modules/" in
their play application while using plovr in parallel.
It could be as simple as just adding "/plovr/" before "/input/"
http://localhost:9080/input/hello/... would become
http://localhost:9080/plovr/input/hello/...
But as I don't people from using traditional "localhost:9080/input", I propose
to add a new configuration to enable it or not.
In my case, it would be a simple way to be sure that plovr routes are not
overriden by anything else.
OK this is a detail and if you tell me that adding a context is far too
complicated, I will add a "WARNING: do not use /input, /compile etc..." in the
documentation :)
Thanks for your time!
regards
Pascal
Original comment by pascal.v...@gmail.com
on 1 Feb 2011 at 8:08
Would it be much work for you to change your Play! plugin to take requests to:
http://localhost:9080/plovr/*
and then rewrite the URL and pass it to the version of plovr that you have
bundled as a library and then return the result?
That would not require any changes to plovr.
Original comment by bolinf...@gmail.com
on 1 Feb 2011 at 4:22
Yes I can do that, this is my last solution, the dumb one :)
In fact, the only problem are the embedded "/input/" scripts loaded from client
JS in RAW mode. I should rewrite everything with /input/ on the fly but this is
not quite a problem.
I can do that if you prefer keeping plovr as it is. I can understand that.
That was just a suggestion of enhancement, not a critical issue.
Anyway, I think plovr+closure+play might be interesting at the end!
regards
Pascal
Original comment by pascal.v...@gmail.com
on 1 Feb 2011 at 4:35
I have actually started using Play! now myself, and it's quite fun! But to
close the loop on this, for now, I do not plan to support this feature right
now. The space of plovr options is already getting to be quite large, and I
want to focus on ones for which there is no workaround.
Cheers,
Michael
Original comment by bolinf...@gmail.com
on 24 Apr 2011 at 2:35
No problem... I haven't worked much on the play closure plugin recently because
I'm working on other opensource projects right now. If you need any advise or
discuss some points about Play!, don't hesitate, I contribute a lot to Play!
community so I begin to have some knowledge about it ;)
regards
Pascal
Original comment by pascal.v...@gmail.com
on 24 Apr 2011 at 2:44
Original issue reported on code.google.com by
pascal.v...@gmail.com
on 31 Jan 2011 at 8:14