Adding default context path

[colinbes]

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

[joescii]

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

On May 12, 2014, at 10:15, Colin Bester [email protected] wrote:

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

—
Reply to this email directly or view it on GitHub.

[colinbes]

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) {
return {
'request': function (config) {
config.url = ‘/bc/' + config.url;
return config || $q.when(config);
}
};
});

~C

On May 12, 2014, at 10:44 AM, Joe Barnes [email protected] wrote:

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

On May 12, 2014, at 10:15, Colin Bester [email protected] wrote:

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

—
Reply to this email directly or view it on GitHub.
—
Reply to this email directly or view it on GitHub.

Internet Disclaimer

---

This message (including any attachments) contains confidential information intended for a specific individual and purpose, and may be protected by law.
If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited.

---

[joescii]

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.

[colinbes]

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 <base href="..."> etc. Note that using Interceptor mentioned above also worked for me.

return $http.post('/ajax_request/' + lift_page + '/', req, {
        headers : {
          'Content-Type': 'application/x-www-form-urlencoded; charset=UTF-8'
        }
      }).then(returnQ);

to read

return $http.post('ajax_request/' + lift_page + '/', req, {
        headers : {
          'Content-Type': 'application/x-www-form-urlencoded; charset=UTF-8'
        }
      }).then(returnQ);

[colinbes]

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...

myApp.config(function($locationProvider, $httpProvider) {

    $locationProvider.html5Mode(true);
    $httpProvider.interceptors.push(function($q) {
        return {
            'request' : function(config) {
                config.url = $('pageContext').context.referrer + config.url;
                return config || $q.when(config);
            }
        };
    });
});

[joescii]

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

On May 12, 2014, at 14:46, Colin Bester [email protected] wrote:

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...

myApp.config(function($locationProvider, $httpProvider) {

$locationProvider.html5Mode(true);
$httpProvider.interceptors.push(function($q) {
    return {
        'request' : function(config) {
            config.url = $('pageContext').context.referrer + config.url;
            return config || $q.when(config);
        }
    };
});

});
—
Reply to this email directly or view it on GitHub.

[colinbes]

Super, look forward to checking it out.

Thanks for addressing so soon.

Colin

Sent from my iPhone

On May 12, 2014, at 7:05 PM, Joe Barnes [email protected] wrote:

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

On May 12, 2014, at 14:46, Colin Bester [email protected] wrote:

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...

myApp.config(function($locationProvider, $httpProvider) {

$locationProvider.html5Mode(true);
$httpProvider.interceptors.push(function($q) {
return {
'request' : function(config) {
config.url = $('pageContext').context.referrer + config.url;
return config || $q.when(config);
}
};
});
});
—
Reply to this email directly or view it on GitHub.
—
Reply to this email directly or view it on GitHub.

[joescii]

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.

[colinbes]

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 $injector:modulerr Failed to instantiate module recipe.services with no error given. On examining output in browser I don't see my expected factory code.

Here is my simplified snippet code

object MyRecipeService {

  val am = angular.module("recipe.services")
    .factory("recipeService", jsObjFactory()
      .jsonCall("getModels", RecipeService.getModels))

  val ren = renderIfNotAlreadyDefined(am)

  def render = {
    System.out.println("am = "+am);
    System.out.println("ren = "+ren);
    ren
  } 
}

For completeness section of html file requesting lift processing of snippet:

<script data-lift="MyRecipeService"></script>

and output in eclipse console

[INFO] Started Jetty Server
[INFO] Starting scanner at interval of 10 seconds.
am = net.liftmodules.ng.Angular$Module@470cbe
ren = 
08:38:20.167 [qtp1153748161-27] WARN  n.liftweb.http.CoreRequestVarHandler - RequestVar net.liftmodules.ng.Angular$HeadRendered$_ was set but not read

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.

[joescii]

Change val am and val ren to def am and def ren.

[colinbes]

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 [email protected] wrote:

Change val am and val ren to def am and def ren.

—
Reply to this email directly or view it on GitHub.

Internet Disclaimer

---

This message (including any attachments) contains confidential information intended for a specific individual and purpose, and may be protected by law.
If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited.

---

[joescii]

Oh, something else I thought of... where is the service relative to the Angular snippet in the HTML? I always render Angular before the services.

[colinbes]

I originally had <script data-lift="Angular"></script> in my default.html file in the section but have now moved it into my HTML file just before services - it worked fine in 0.3.1.

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 <span id="angularscript"></span> tag in HTML with StatefulSnippet:

render method...
"#angularscript" #>  angularScript() &
      "#yy [onclick]" #> SHtml.jsonCall(clientQuery, (s:JValue) => handleClick(s))._2.cmd andThen SHtml.makeFormsAjax

This no longer works in 0.4.1 and I need to use tag <script data-lift="MyRecipeService"></script> and create seperate snippet file

object MyRecipeService {

  def render = {renderIfNotAlreadyDefined(angular.module("recipe.services")
    .factory("recipeService", jsObjFactory()
      .jsonCall("getModels", RecipeService.getModels)))} 
}

[colinbes]

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
Working_0.4.1 is modified Non_Working_0.4.1, made to work by introduction seperate snippet file and dripping csssel based transformation

Cheers
Colin

On May 13, 2014, at 10:45 AM, Joe Barnes [email protected] wrote:

Oh, something else I thought of... where is the service relative to the Angular snippet in the HTML? I always render Angular before the services.

[joescii]

I'm 99% sure I've found your problem. Try 0.4.2-SNAPSHOT. It is available in the Sonatype snapshot repo (http://oss.sonatype.org/content/repositories/snapshots)

[colinbes]

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 [email protected] wrote:

I'm 99% sure I've found your problem. Try 0.4.2-SNAPSHOT. It is available in the Sonatype snapshot repo (http://oss.sonatype.org/content/repositories/snapshots)

—
Reply to this email directly or view it on GitHub.

[colinbes]

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 [email protected] wrote:

I'm 99% sure I've found your problem. Try 0.4.2-SNAPSHOT. It is available in the Sonatype snapshot repo (http://oss.sonatype.org/content/repositories/snapshots)

[joescii]

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!

[colinbes]

Yup, that will get you every time!

Thanks for your assistance

On May 13, 2014, at 4:00 PM, Joe Barnes [email protected] 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!

[joescii]

0.4.2 released. This time we should have it all correct!