-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Adding default context path #2
Comments
Hey Colin, I don't know anyone who has tried non-root applications with lift-ng. Regarding the ideas you have tried, were you trying to modify the lift-ng source, or were you trying to make it work as-is? Joe
|
I was trying to make it work as is - I haven’t had chance to modify source code yet but was wondering what effect would be if /ajax_request was made relative as opposed to absolute. I am having some success using httpProvider interceptors but don’t like the idea of hard coding my context path. $httpProvider.interceptors.push(function ($q) { ~C On May 12, 2014, at 10:44 AM, Joe Barnes notifications@github.com wrote:
Internet Disclaimer This message (including any attachments) contains confidential information intended for a specific individual and purpose, and may be protected by law. |
Yeah, I likewise believe that should be avoided. I think this may be literally a 1-character fix. Try the context-fix branch. It doesn't break my test app. Let me know if it fixes your application. |
I am using Liftweb 2.6x with scala 2.10x with maven and couldn't (easily) get context-fix branch to work so I just copied liftproxy.js (from ng_2.6_2.10, version 0.3.1) and modified call to ajax_request to be relative and not absolute - see below. This worked for me. I am not sure if this breaks anything else though, for example if using
to read
|
I do believe that the relative/absolute fix is potentially the better solution but for folks wanting to use Interceptor method without hardcoding of context path in the meantime...
|
Great to hear making it a relative URL works. As I mentioned, the relative path worked great with the embedded test project, which deploys at the root context. I'll merge the change and release it as 0.4.1 later this evening. FYI, assuming you migrate from 0.3.1 to 0.4.1, you'll only need to include the Angular snippet now, omitting the liftproxy and the future actor in your view template(s). There are also some optional init() params you can pass in your boot related to futures support. Joe
|
Super, look forward to checking it out. Thanks for addressing so soon. Colin Sent from my iPhone
|
No problem! Glad to have more people looking at it and contributing. Version 0.4.1 is out. Let me know when you've had time to try it and verify that your issue is resolved, and we can close this issue. |
I have tried version 0.4.1 and am not sure if I am doing something wrong or whether renderIfNotAlreadyDefined has changed as it appears that I am not inserting nodeseq from my snippet creating the factory service. What led me down this path was angular error Here is my simplified snippet code
For completeness section of html file requesting lift processing of snippet:
and output in eclipse console
As can be seen in console output, angular module (am) is instantiated and display in console am = ......, but ren has no data. In converting from 0.3.1 I did remove liftproxy.js from my html file and confirmed that new code is inserting liftproxy.js automatically. |
Change |
I’ll try but I only did this to debug after I saw that service javascript was not inserted. ~C On May 13, 2014, at 10:22 AM, Joe Barnes notifications@github.com wrote:
Internet Disclaimer This message (including any attachments) contains confidential information intended for a specific individual and purpose, and may be protected by law. |
Oh, something else I thought of... where is the service relative to the |
I originally had I am going a little in circles so maybe need to take a break, but with 0.3.1 I was able to use csssel binding to a
This no longer works in 0.4.1 and I need to use tag
|
Only way I can get 0.4.1 to working is by using a dedicated snippet to serve the Services transformation. Version 0.3.1 worked using CssSel transformation. I have posted sample project to https://github.com/colinbes/lift-ng. This project has three tags in master branch; Working_0.3.1, Non_Working_0.4.1 and Working_0.4.1 Non_Working_0.4.1 is straight upgrade from 0.3.1 to 0.4.1 Cheers On May 13, 2014, at 10:45 AM, Joe Barnes notifications@github.com wrote:
|
I'm 99% sure I've found your problem. Try |
Ahh, that loos more promising. Whatever the changes, it works on my simplified project. As I have hit my current project with a hammer I need to put pieces together again and I will try - but I am pretty sure this will work. I will be interested to see what the changes were. ~Colin On May 13, 2014, at 2:46 PM, Joe Barnes notifications@github.com wrote:
|
Just tried with my main project and 0.4.2-SNAPSHOT seems to be working fine! On May 13, 2014, at 2:46 PM, Joe Barnes notifications@github.com wrote:
|
Fantastic! It's funny because it's code that I removed just 2 days ago... I thought it wasn't used: 8727a5d I'll release 0.4.2 this evening. Thanks for all of the time you've put into helping make lift-ng better! |
Yup, that will get you every time! Thanks for your assistance On May 13, 2014, at 4:00 PM, Joe Barnes notifications@github.com wrote:
|
0.4.2 released. This time we should have it all correct! |
As my app is running non root the generated ajax call is to /ajax_request where I need /context/ajax_request
I have tried couple of ideas with no success and am looking for ideas/suggestions
Much appreciated
~Colin
The text was updated successfully, but these errors were encountered: