咕噜服务+ PHP? [英] Grunt serve + PHP?

查看:136
本文介绍了咕噜服务+ PHP?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我开始我的哟+咕噜+ angular.js第一个项目。结果
我有需要读取从我的服务器的一些数据的服务;我建立它采用了棱角分明$ http服务。
我也建立了一个RESTful Web服务(PHP实现,但它可能是Java和C,Perl中,...,没关系),这暴露了一个API来获取数据。结果
从咕噜供应我NG应用服务器目前(也可能永远都)从哪里PHP Web服务(阿帕奇)运行相同的。

I'm starting my first project with yo + grunt + angular.js.
I have a service which needs to read some data from my server; I built it using angular $http service. I've also built a RESTful web service (implemented in PHP, but it could be Java, C, Perl, ..., it doesn't matter) which exposes an API to get the data.
The server from which grunt serves my ng-app is currently (and probably will ever be) the same from where the PHP web service is run (by apache).

我不知道这是一个可以接受的建筑......我结束了在同一台服务器上有两个不同的服务器(咕噜和apache)...更多,我总是要增加一个访问控制允许来源: 127.0.0.1我的PHP服务的输出...: - (

I wonder if this is an acceptable architecture... I end up having two distinct servers (grunt and apache) on the same server... More, I always have to add an "Access-Control-Allow-Origin:127.0.0.1" to the output of my PHP service... :-(

是否有可能从繁重的PHP服务,例如?

Is it possible to serve PHP from grunt, for example?

更新:我谈谈发展阶段......当然在制作我不会用咕噜......结果
为了更好地解释一下,我想同时在开发和生产阶段使用相对URL在$ HTTP()...在相同的code ...结果
如果在生产,我可以期望它的工作,因为我将只对已部署的角度应用程序的的PHP服务,谁应该际preT PHP的发展,当角应用一台服务器由步兵服务?咕噜本身呢?如果是的话,怎么样?

UPDATE: I speak about development stage... Of course at production I wouldn't use grunt...
To better explain myself, I would like to use relative urls in $http()... With the same code at both the development and the production stages...
If at production I can expect it to work, because I will only have one server for the deployed Angular app and the PHP service, who's supposed to interpret PHP at development, when the Angular app is served by Grunt? Grunt itself? If yes, how?

UDPATE 2,和可能的解决方案:想了不少关于这个问题(也是阅读的这个一文),而不是在这里接受令人满意的答案,我决定,我会用这个办法:

UDPATE 2, AND A POSSIBLE SOLUTION: After thinking quite a bit on this issue (and also reading this article), and not receiving satisfactory answers here, I decided I will use this approach:


  • 开发

    • 使用了生产样服务器(Apache,lighttpd的,...),以满足真正的PHP页面。结果
      使用绝对网址与$ HTTP或$请求访问该服务器(从咕噜,供应angular.js页不同)。该网址将被轻松配置,仅要求最低工作(和可能出现的错误)切换到生产。

    • 在PHP脚本,制作(JSON)输出,输出总是正确的访问控制允许来源头前;该指令的值也将是很容易配置。


    • 生产

      • 部署angular.js应用到PHP部署在同一台服务器。

      • 更改网址,使他们相对的,因为现在他们与客户端脚本共享相同的起源。

      • 将访问控制允许来源头,只允许本地请求(或者可能删除头在所有...)。

      我会很高兴,如果有人要评论此解决方案,争议,或提出更好的...

      I would be very pleased if anybody would like to comment this solution, to dispute it, or to propose better ones...

      推荐答案

      如果没有收到满意的答案,想着很多有关的问题我自己后,我提供以下我的结论:

      Not receiving a satisfactory answer, after thinking quite a bit about the issue myself, I provide hereafter my conclusions:


      • 开发的结果

        • 使用了生产样服务器(Apache,lighttpd的,...),以满足真正的PHP页面。结果
          使用绝对网址与$ HTTP或$请求访问该服务器(从咕噜,供应angular.js页不同)。该网址将被轻松配置,仅要求最低工作(和可能出现的错误)切换到生产。

        • 在PHP脚本,制作(JSON)输出,输出总是正确的访问控制允许来源头前;该指令的值也将是很容易配置。


        • 生产的结果

          • 部署angular.js应用到PHP部署在同一台服务器。

          • 更改网址,使他们相对的,因为现在他们与客户端脚本共享相同的起源。

          • 将访问控制允许来源头,只允许本地请求(或者可能删除头在所有...)。

          这篇关于咕噜服务+ PHP?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆