Jump to content

Framework => Library


redbullmarky

Recommended Posts

Hi all

Not sure if this is possible, or whether I shoulda done a bit more googling, but still...

 

I have a pretty big framework i've been building over time which I now use to develop most of my new sites with. What I'm trying to find out is if it's possible somehow to turn this collection of files into a single special file that, via maybe just a change of a setting in the php.ini file (on a LAMP system) could allow my framework to be readily available in PHP? This for me would allow distribution to be much easier as well as giving some protection over the main framework itself (i guess)

 

Any help would be great

Cheers

Mark

Link to comment
Share on other sites

not really.

 

what i'm mainly looking to do is to condense/compile the framework down to a single file, for convenience purposes (amongst other things - like having some degree of protection over my code), that I could use it just like PHP's built in functions/classes. I guess the nearest thing I've seen to what I'm after is the PECL libraries, or GD or whatever, but it seems that these libraries need to be written in C.

Link to comment
Share on other sites

not really.

 

what i'm mainly looking to do is to condense/compile the framework down to a single file, for convenience purposes (amongst other things - like having some degree of protection over my code), that I could use it just like PHP's built in functions/classes. I guess the nearest thing I've seen to what I'm after is the PECL libraries, or GD or whatever, but it seems that these libraries need to be written in C.

 

I think php byte code compilers maybe part of what you seek.

 

Link to comment
Share on other sites

I think php byte code compilers maybe part of what you seek.

 

again, that's part of the solution, yes. I guess my main aim is to make it easier to distribute - ie, just drop it onto the server as a single file, and i'm done - rather than unzipping tonnes of files into the correct directory structures, etc. I get the feeling since I first opened up the topic that it's probably a lost cause with the tools available now. Personally, I can't see why it's NOT possible, I just reckon the tools haven't been developed to do it properly yet.

 

I've looked indepth at things like Zend Encoder/ionCube, etc for the solution of protection, etc, but it still leaves me with the other issue.

 

Oh well. I guess i'm too picky ;D

Link to comment
Share on other sites

I am not sure if this is of any help but my framework is self contained. It is self contained within one folder that has a directory structure that is forced on the user. There are a lot of advantages when it comes to havng a framework designed like this as opposed to an "included" framework, I find it just lets me predict things better allowing for more things to be automated. Pretty much the only configuration I do in my framework is in the /system/configs/ directory.

 

The down side to this is the fact If i have two sites on the same server using the same framework I have to have two copies of the framework but this is an advantage too because when someone modifies it for one app it wont affect the other.

 

I am not sure if you are looking for this kind of approach though, but it works for me on my framework all i do is paste the dir in webroot and it "works" one of the main advantages to forcing a directory structure on the users is I know where stuff is going to be, i know where the config files will be, i know where my logs will be saved to i know where everything will be so i can map it ahead of time allowing for considerably less configuration.

 

The only configuration in my framework is for

 

encryption //optional

session //optional

debugging //optional

cache //optional --i set defaults--

request //optional --i set defaults--

databases  //optional

 

there are a few other configurations unique to my framework but all of them are optional. Anyway I am ranting but the reason I ranted is I dont think the level of automation i have is possible via the method you are currently using and i believe automating all configurations and stuff is required to make a framework that can be just and pasted and then executed and i dont believe this is possible via the one copy of the framework for multiple sites approach and if I am wrong about the way you access your framework sorry I am going off memory about something I read on here a few weeks ago that I 'Think' you said.

 

 

 

 

Link to comment
Share on other sites

Ron, he wants to compress his entire framework into one file; that would work from a "does it work" point of view, but wouldn't solve the problem.

 

Mark: Most frameworks are usually a pretty good size, and I'm guessing yours is no exception - this file might end up being several megabytes. And we all know that byte-compiled and encoded PHP scripts aren't locked down very tightly. We do something rather unique with our framework at my place of employment, and it works very well. I don't know how well this will work for you, or if it's financially possible, but it could be something to think about.

 

Any time a client wants to take advantage of our framework, we require that their website be hosted on our servers. We keep all of our servers in-house and are connected to a very reliable pipe that we share with a few other companies. We handle all of the DNS services, database storage and backup, and every thing else that comes with running a reliable server. This allows us complete control over the framework and the environment, and we use a subversion repository to make upgrades and modifications simple. There's a bit of overhead for such an operation, of course, so if you decide to go with it, that's something you'll have to figure out.

Link to comment
Share on other sites

I might be overlooking something obvious but: doesn't putting your framework in a single file mean the entire thing is loaded into memory?

 

I'm sure you can avoid this if you rewrite the whole thing as a C extension, but otherwise I do not really see how you would avoid that.

 

Tbh, I don't really see the problem with having your framework in a regular dir structure. In fact, I see more advantages than disadvantages with that - like not having to update the whole framework when only a single component changes.

 

If you'd wan't easier management, you could write a simple script that connects over FTP and checks for/updates aged files. You'd have a working and a final copy on your local server, as well as a list of adresses/ftp credentials. It just iterates and synchronizes the latest final copy with the remote copies. Simple and convenient.

Link to comment
Share on other sites

448191, i think i'm trying to kill two birds with one stone, I guess - protection of the framework as well as ease of install. A good chunk of the framework are specific to the industry I mainly deal with (ie, recruitment) and are on sale at some tidy little prices. Sure, I could use Zend Encoder, ionCube or suchlike to "compile" the scripts in question, but I guess if I could go the whole hog and also make the whole thing as a complete extension, that'd be better.

 

Neal, that's the way I've got it right now but most of the sites I've done are applications for me and my company and the others I'm jointly involved with. There is one however that will at some point need to be hosted elsewhere and others will follow.

 

As we stand right now, I think that encoding the scripts in question might be the way to go until something comes out that can do the whole job.

 

Cheers for your help chaps

Mark

Link to comment
Share on other sites

@nameless

The down side to this is the fact If i have two sites on the same server using the same framework I have to have two copies of the framework but this is an advantage too because when someone modifies it for one app it wont affect the other.

 

Why not build your framework so that you only install it in one directory structure but then allow client apps that want special functionality to override just pieces of it with their own versions of files.

 

Take this dir structure as an example:

~/public_html/your_framework
~/public_html/site_one
~/public_html/site_two

 

Now you have site_one and  site_two both include the same framework for their code.  What you do is build your framework so that it optionally takes two arguments when it's included:

<?php
  /**
   * site_one.php
   * starting script for site one
   * This file would be at ~/public_html/site_one/site_one.php
   */
  // Set the path of site one's source code
  $src_dir = dirname(__FILE__) . "/";
  // Set site one's override directory for your framework
  $override_dir = dirname(__FILE__) . "/override_fw/";
  // Include your framework
  require_once("path/to/your/framework/file.php");
?>

 

When your framework kicks off, it will look for $src_dir and $override_dir being set, if they're not set then the invoking site has no custom version of your framework.  Now let's say site one wishes to override your framework's:

<framework_root>/components/layout.php

 

You simply place site one's version of layout.php within:

<site_one>/override_fw/components/layout.php

 

You build your framework's loader so that when it includes / requires a file, it checks for existence of the site's overriding copy and loads that if it exists, else it loads the regular framework file.

 

This way updating your framework is easy and multiple sites can work off the same framework installation with customisations.

Link to comment
Share on other sites

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.