Skip to content
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

Closed
colinbes opened this issue May 12, 2014 · 20 comments
Closed

Adding default context path #2

colinbes opened this issue May 12, 2014 · 20 comments
Labels

Comments

@colinbes
Copy link

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
Copy link
Owner

joescii commented May 12, 2014

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 notifications@github.com 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
Copy link
Author

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 notifications@github.com 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 notifications@github.com 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
Copy link
Owner

joescii commented May 12, 2014

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
Copy link
Author

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
Copy link
Author

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
Copy link
Owner

joescii commented May 13, 2014

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 notifications@github.com 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
Copy link
Author

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 notifications@github.com 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 notifications@github.com 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
Copy link
Owner

joescii commented May 13, 2014

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
Copy link
Author

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
Copy link
Owner

joescii commented May 13, 2014

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

@colinbes
Copy link
Author

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:

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
Copy link
Owner

joescii commented May 13, 2014

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
Copy link
Author

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
Copy link
Author

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 notifications@github.com 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
Copy link
Owner

joescii commented May 13, 2014

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
Copy link
Author

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:

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
Copy link
Author

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:

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
Copy link
Owner

joescii commented May 13, 2014

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
Copy link
Author

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:

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 added a commit that referenced this issue May 14, 2014
@joescii
Copy link
Owner

joescii commented May 14, 2014

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants