Please excuse my distinct lack of knowledge in this field. Software development is not my forte.
I am currently about to commence work on a project of which there is a large system built using PowerBuilder with an Oracle Enterprise database to serve the data up.
I want to build a nicer interface for the system and believe it is possible to use web technologies (my background) to do so. Can anyone confirm if it is possible to use PHP with PowerBuilder or is there a way in which I can interface my build with PowerBuilder?
I don't think there is a "good" way to incorporate PB & PHP but if there is a will there is always a way.
One unusual but possible way of mixing the technologies might be to write an IIS handler with PowerBuilder.NET, or you could build the handler using Visual Studio and call a PowerBuilder .NET Assembly from the handler. I find it is easier to build the handler using Visual Studio myself because I had problems getting PB.NET to inherit from HTTPHandler or using the .NET interface. Doing this would be like re-inventing ASP.NET as it basically just processes .ASP files and kicks out HTML/Javascript/CSS,etc and you'd be writing a handler for a different file extension (say .pb or .powerbuilder) and spitting out your favorite web code based on what filename and/or arguments you used in the URL.
I made something like this not long ago just to see if I could do it and it wasn't too difficult. Eventually I'll post the code on my PB blog. I've seen another implementation of something like this using CGI which is older technology, not as good as using a handler for busy sites.
Again this probably wasn't the answer you were looking for but it is an answer. Good luck.
I just read the Twelve-Factor App, which looks like a pretty comprehensive set of rules to apply in a web-based application. It uses python or rails in its examples, but never php... I was wondering which factors of the manifesto can be applied to PHP projects and how?
Thanks
Short answer:
All points apply to PHP as the twelve factor app manifesto refers specifically for web apps.
PHP has a very hard time complying to twelve factor, in particular in the items 2, 7, 8 9 (as a side effect of 7 and 8) and 12 (partially). Actually that's the first really grounded argument I have heard in the whole "PHP sucks" rant that is common on the Ruby and Python communities (don't get me wrong, I think Ruby and Python are better languages, but I don't hate PHP, and definitively hate the "my language is better" rants.)
Being that said, it may be that your PHP project is not a web app or SaaS, but just a simple website, so you may just deem that twelve factor is not a need.
Long answer: A point-by-point analysis would be:
Codebase: not an issue
Dependencies: the way PEAR works goes quite against this point, as pear dependencies are installed system wide and usually you don't have a consolidated manifesto to declare them. Is also usual for a PHP setup to require you to add packages to your OS installation to get some libraries available. Finally AFAIK there isn't a tool in PHP to provide isolation like "virtualenv", "rbenv" or "rvm" (or if it exists is not popular among the PHP community) Edit: Composer (http://getcomposer.org/) seems to do the right regarding dependencies, it still doesn't isolate the PHP version, but for all the rest it should be fine.
Config: some PHP frameworks are not very well suited to do this, but there are certainly others that do well, so it's not a flaw of the platform itself
Backing Services: shouldn't be much of an issue, despite maybe having to hack some frameworks a little in order to manage the services as resources
Build, release, run: this is totally appliable to PHP as this definitively doesn't concern only "compiling". One may argue that several projects and hosting platforms on the PHP community abuse of direct FTP, etc. but that's not a flaw of PHP itself, and there is no real impediment on doing things right regarding this item.
Processes: This definitively concerns to PHP. PHP is quite capable of running purely stateless processes (the emphasis is on the word stateless), and actually several frameworks make your life easy for it. For example, symfony provides out-of-the-box session management with memcached or database storage instead of regular sessions
Port binding: Over simplyfing it, this point basically demands you to reverse proxy and have the actual webserver embedded on the app instead of being a separated component. This puts PHP in a very hard position to comply. Despite there are ways to do this (see the reply about using PHP as FastCGI) that's definitively not the most common nor the best supported way to serve a PHP app as it is on other communities (e.g. Ruby, Node.js).
Processes: This is not impossible in PHP. However several elements put PHP in a hard position to comply. Namely the lack of good support for items 6 and 7; the fact that the PHP API to spawn new processes isn't really very nice to work with; and specially the way Apache's mod_php handles their workers (which is by far the most common deployment schema for PHP)
Disposability: If you use the right tools there is nothing inherent on PHP to prevent you from creating fast, disposable, tidy web and worker processes. However I believe that since the underlying process model is hard to implement as per points 7 and 8, then 9 becomes a bit cumbersome as a side effect
Dev/prod parity: This is very platform agnostic, and I would say one of the hardest to get done right. PHP is no exception to this rule, but it doesn't have a particular impediment either. Actually most of the tools named on the manifesto can be applied to a PHP project
Logs: Having your app agnostic of the log system on the execution environment is totally doable on PHP
Admin processes: The most important flaw of PHP regarding this point is its lack of a REPL shell. Regarding the rest, several frameworks like Symfony allow you to program admin tasks (e.g Doctine-based database migrations) and run them on the same environment as your "regular" web envionrment.
Since the PHP community is evolving, it may be that it has already righted some of the wrongs mentioned.
Build, release, Run: Applicable to compiled code which is not the case in PHP. So this
point is not something you need to look at.
I don't claim any authority on this 12 factor stuff, but my read of that section is that the author would disagree. It's not just about compiling, it's about managing dependencies both in the small (the snapshot of the code) and in the large (any libraries the code uses).
Imagine you're a new dev and they say, "Okay, this is a custom php app, so...
a) The custom code is really two subprojects, which are in repo A and repo B.
b) You'll need to create a directory layout like so, and then
c) check the code for each subproject out into this subdirectory and this subdirectory.
d) You'll also need these three open source PHP libraries:
version 3.1 of library Foo,
version 2.3 of library Bar, and
version 5.6 of library Bat.
e) download them from their home project sites and unpack them, then copy them into this directory, that directory, and the other directory.
f) then you'll need to set these configurations in the external library,
g) and these configs in our two custom code projects.
h) once that's all done, tar/gzip it all up, upload it up to the QA server and untar it into htdocs.
There's no compiling going in that set of steps, but you can bet there's a lot of building.
Getting all of that set up and working is the build step.
Using tar/gzip to take a snapshot of the working build is the release step.
SCP'ing/unpacking it into the QA server's htdocs directory is the runtime step.
You might say that some of those steps above are unnecessary - the libraries should be deployed at the system level and merely imported. From the 12factors.net site I'd say the author prefers you to import them uniquely and individually for the app. It sidesteps dependency versioning problems at the cost of more disk space (not that anybody cares). There are more hassles in managing all those dependencies as local-to-the-app, but then that's the point of the build/release/runtime scheme.
It might have changed since you read it - there are a few PHP examples now, although a few of them seem like negations of the twelve-factor concept.
One of the ways that normal mod_php sites violate twelve-factor comes with VII. Port binding. From the manifesto:
The twelve-factor app is completely self-contained and does not rely on runtime injection of a webserver into the execution environment to create a web-facing service. The web app exports HTTP as a service by binding to a port, and listening to requests coming in on that port.
However, apache/php can be coaxed into this worldview with something like this:
https://gist.github.com/1398498
Not perfect, but it works for the most part. To test it out, install foreman:
gem install foreman
then run it in the directory you cloned the gist into:
foreman start
then visit
http://localhost:5000/foo
DO NOT TAKE THIS POST AS A REFERENCE, THIS WAS WRITTEN IN 2011, MANY THINGS HAVE CHANGED SINCE THEN... THE WORLD OF PROGRAMMING IS IN CONSTANT EVOLUTION. A POINT OF VIEW OF 2011 IS NOT NECESSARILY STILL VALID IN 2018.
I just read a few lines of each points and here goes my analysis of the document:
Codebase: Everyone, php or not should have a codebase even for the little projects
Dependecies: PHP uses includes and code libraries that you should always be able to port easily by simply copying the code to a server. Sometimes you use PEAR and then if the server doesn't support it, you have to copy and install pear manually. I use Zend Framework most of the time, so it's just copying the code of the framework with the ftp upload.
Config: It is common for php apps to have a writable config file that you store configurations into. Where you store it is your choice as a developer, but it is usually either at the root of your app or in a settings/config folder.
Backing Services: PHP does use backing service most of the time such as MySQL. Other common services depending on your app are twitter and facebook. You use their API to communicate with them and store/retrieve data to work with.
Build, release, Run: Applicable to compiled code which is not the case in PHP. So this point is not something you need to look at.
Processes: HTTP is stateless and is SERVED,thus, you usually have no process apart from the web server. This is not entirely true as a webservice may be bundled with applications you package with or create for it. But, for the sake of standards, you usually don't have to use processes in the web world.
Port binding: PHP doesn't apply to port binding at all because it is not a process that hooks to an address, Apache, NGinx or Lighttpd does that for you. Reading #6/7 makes me understand that a website could never be a Twelve-Factor app.
Concurrency: Again this point treats about processes which do not apply to PHP web pages. This point applies to the server serving the content.
Disposability: This point discusses about how fast a process should be. Obviously, PHP web sites not being a process shouldnt apply but always note that your website should execute pages as fast as possible... Always think about this block or that block of code and see if it is optimized.
Dev/Prod Parity: This point is crucial in any app development. You never want to have a large gap between two app versions or upgrading can become a hassle. Furthermore, never create client specific versions of an app. Always find ways to allow your app to be configured/customized at the template level so you can keep your app as close as possible to all installed versions everywhere.
Logs: Logs are always a good thing to have, they allow you to follow the process of your code without having to output it to screen. My favorite tactic is to "tail -f logfile" inside of a linux console and look at what is happening as i execute my code.
Admin processes: Not applicable, in php, you don't have processes, but you do have pages that you can secure with usernames and passwords.
I am having one enterprise application developed using j2ee technology. I also have some php application. I want to merge the php application in my enterprise application to enhance the functionality without rewriting the code in j2ee. Could anyone please suggest me how to do this. I did some research on this and found following options
PHP & Java bridge - In this I will run tomcat behind apache server. The php module will be in apache and j2ee app in tomcat. This seems to be the opposite of how I would want my app to run. As the user registers in j2ee app and will also use the module build in php. So I would want my tomcat server to be oin front.
Install php on tomcat and run the php module in tomcat server. I tried many times to configure this with PHP5+ and tomcat6+ but not able to do that. I also could not find proper php & tomcat version combination which works together.
Please help me to find the best option (open for any new options as well) keeping application performance in mind.
running the PHP part on Apache httpd and the java part on Tomcat "behind" it is not that wrong. The fact that Tomcat is behind apache server is only a matter of connection flow, but from a user POV /forum/page.php will be handled by PHP, while /supercomputation/dothat will be handled by java.
The only problem is how you put the two together on the same page, if you need to, cause in this case only server side includes, iframes or javascript pop on my mind.
Another approach is to install PHP on a separate server, even another httpd on a different port, eventually listening only on 127.0.0.1, and then use a java server side component to "fetch" PHP output and merge it in the page generated by tomcat.
It might sound a hack, but it's not that hard at all, is already supported by many frameworks, and I've seen enormous web sites in production with a java based "frontend" that aggregated contents coming from other PHP and Python subsystems.
Whatever solution you decide to adopt, you'll need to setup some coordination between the two systems ... for example, single authentication for users. How to do that heavily depends on how those applications are designed, and will probably need some tuning here and there.
I have developed an app and its written in PHP (with a bunch of SQL scripts), this app will be used by a few small companies. For them to use it, I will have to install Apache and SQL Server for them.
Every method I have thought has fallen short of what I need. I was actually just hoping to use ZendGuard or IonCube but they don't support PHP 5.3.x.
Is there a simpler method where I can maybe store a key in the database and make the app run only when it knows its on that server?
Maybe create a key based on some random numbers/letters and the machine name, sql server host name and encode/decode this when ever the system is in use?
Thanks all for any help or ideas
Even if Zend and Ioncube don't support PHP 5.3 code (which I find hard to believe!! Are you sure?), I'm sure they will in the foreseeable future.
I think it's worth asking them when they are going to introduce support for it.
Update: It indeed seems true: Zend but then, the question is, does your software really need 5.3 (i.e. use 5.3 specific features like namespaces and such?)
I work in a dev environment that is currently IIS6/Server 2003 with Framework 3.5. I primarily am working in ASP.NET MVC.
I've run into a scenario where, for the solution I'm working on, I'd either have to spend weeks reinventing the wheel or integrating a PHP-based opensource project into one of the components I'm building.
I'd love to add this project to the fold, but the fact that it is based on PHP greatly concerns because of potential compatibility, security, and administration issues with running both PHP and .NET on a single IIS installation.
What are your experiences of doing this? Good? Bad? Not a big deal? Major headache?
Check the dependencies very carefully.
Many OSS php apps were not available to me because they required libs which were *nix only.
Very often its not until you download it and have a good look that it becomes obvious what those dependencies are.
Not sure if your Q hints at running .asp and .php extensions, but yes you can run them alongside - I even once managed to get .htm files that got parsed by as .asp first THEN as .php after ( btw this was old-style .asp not .net - but on IIS all the same ) .
The major issues I hit in the past may not be a problem for you:
Some PHP libraries assume you can use mod_rewrite. I used ISAPI Rewrite instead, but it was not 100% compatible.
Some libraries (or developers) assume they will run in a Unix based environment, and the file system will be case sensitive.
Apart from these, I haven't had any issue when running PHP from IIS that would prevent me from using it in a production environment.