per-project libraries
Richard Bateman
library for just one project?
I guess what I'd like is to be able to put a module dir in my project
and have loadlib load that one instead of the library from the primary
framework dir. That way, if for some reason I needed to break something
(or was testing something in one project) I wouldn't have to create a
whole new tree.
Also, if we could find a way to do it that wouldn't have too high an
overhead, maybe being able to define a search path for included
libraries would be cool -- maybe we could even add something to the PHP
includes path and use that for includes, so that the PHP engine would
handle it instead of us having to check if the file exists.
Just brainstorming, tell me what you think.
Richard
Rick Gigger
>
> Is there anything in place right now that will allow one to override a
> library for just one project?
Ok, I think there are several different ways we could attack this
problem depending on what you want to do.
> I guess what I'd like is to be able to put a module dir in my project
> and have loadlib load that one instead of the library from the primary
> framework dir.
Is there just one class that you want to change? I assume this can't
be done with just extending a class, but rather you are messing with
some of the core functionality of the module? What specifically are
you looking to do in this case.
> That way, if for some reason I needed to break something
> (or was testing something in one project) I wouldn't have to create a
> whole new tree.
If what you really want to do is change a module and we are just
looking for a way to avoid version control management overhead then I
think we should think about the following:
1. Make the change right in zoop, just don't check them in. Even have
a second, experimental checked out directory (maybe even check it out
read only) that you can mess around in.
2. Use git. Using git you can check out from subversion, then manage
locally with git. With git you can easily manage a whole bunch of
local branches and make, destroy and merge between them VERY quickly
whenever you want. Then when you want to you can still commit to svn.
If on the other hand you might want to be able to deploy these changes
and at the same time keep your zoop install current you could always
just call zoop::registerClass and I think your new class will simply
replace the old one. Are you looking to add entirely new zoop modules
without having to put them into the repository right away or are you
looking to mess with ones that are already there?
> Also, if we could find a way to do it that wouldn't have too high an
> overhead, maybe being able to define a search path for included
> libraries would be cool -- maybe we could even add something to the
> PHP
> includes path and use that for includes, so that the PHP engine would
> handle it instead of us having to check if the file exists.
We could easily just add in a second parameter to zoop::loadLib that
would default to zoop_dir but you could pass in anything you want.
Then it would look for the module there. We could also have
zoop::loadAppLib that will be the same as zoop::loadLib but it will
use app_dir/modules instead of zoop_dir. In the end I don't know that
there will be any real technical difference in loading an app module
or loading a zoop module. So if your module is specific to the
application or more or a framework type module it won't really matter.
> Just brainstorming, tell me what you think.
That got me thinking, we could also have a way of adding entire
frameworks that can use the zoop module structure. Then third parties
could create frameworks that build on zoop. We could even bundle some
of them. Also I might want to break the basic framework down into
several different ones. For instance I might want to put all the
stable stuff into the "core" framework. Then the more experimental
stuff into an "experimental" framework. Then there could be "contrib"
for third party stuff. Also we might want to have a legacy framework
where we put all the code for old zoop to allow people to transition
smoothly.
What do you think?
Rick
Richard Bateman
> We could easily just add in a second parameter to zoop::loadLib that
> would default to zoop_dir but you could pass in anything you want.
> Then it would look for the module there. We could also have
> zoop::loadAppLib that will be the same as zoop::loadLib but it will
> use app_dir/modules instead of zoop_dir. In the end I don't know that
> there will be any real technical difference in loading an app module
> or loading a zoop module. So if your module is specific to the
> application or more or a framework type module it won't really matter.
> frameworks that can use the zoop module structure. Then third parties
> could create frameworks that build on zoop. We could even bundle some
> of them. Also I might want to break the basic framework down into
> several different ones. For instance I might want to put all the
> stable stuff into the "core" framework. Then the more experimental
> stuff into an "experimental" framework. Then there could be "contrib"
> for third party stuff. Also we might want to have a legacy framework
> where we put all the code for old zoop to allow people to transition
> smoothly.
>
> What do you think?
>
> Rick
to reload a class, it doesn't replace the existing one, it throws an
error. That might be due to configuration options, I suppose, I
couldn't say for sure. The primary thing that got me thinking about
this is when I was migrating an existing project over to the new zoop
framework from pehppy. In the original pehppy.php that worked very
similar to your zoop.php (so similar, in fact, that I'm astounded at how
closely we built our systems to each other) there is a loadExtensions
method that works pretty much just like your loadLib method, except it
first checks an "extensions" directory in the script root, and then it
checks the fw root dir as it loads. For the particular problem that I'm
dealing with now, that would work quite well, since I have an extension
from the old framework that I want to use with the new, but I don't know
that I want to add it to the official repository (particularly since I'm
not certain what reasons excluded it, and because it's old). I don't
want to rewrite all my code that used it, so for now I have just
manually included the "fpdf" stuff.
That got me thinking, though, that there might be times when we'd want
to use different versions of the same extension, it would be nice to
have a way to "override" the "official" version. really, that's not
that important to me right now, since I don't need to do it at the
moment... it was just a thought that popped up in response to the other.
I like where you're going with the external frameworks idea... there are
a lot of code libraries that we use sometimes that don't go into the
main branch, and it would be great to have a "standard" way to include
them. Another thing that would be good is to have a way to detect if
the module is loaded... for example, the PEHPPY class kept track of all
loaded libraries in a global (non-session, of course) variable, and then
you could call requireExtension("fpdf"), and if the extension was
already loaded it wouldn't do anything, otherwise it would try to load
it. This is great for libraries that depend on other libraries, because
then you don't have to know all the dependencies, it will load them
automatically, but with a minimum of file I/O.
Now, what I was thinking relative to the include path is that the
problem we could run into setting up this sort of paradyme is that it
either requires additional configuration in the middle of the code (like
in index.php or includes) or it would use a lot of file I/O to check the
existence of different files to make sure it loads the libraries in the
correct order.
If we modified the include path, we could define a few "magic"
directories, and then add the ability to add more directories, and the
include path and PHP's include function would take care of the problem
of getting the correct file loaded in 90% of all cases, if not better,
Suggested "magic" directories, in order:
script directory
script/libraries directory
zoop directory
<other added "framework" source directories here>
<existing include path>
Then all you'd need to do to load the "fpdf" library would be to run
zoop:loadLib("fpdf"); (or however it works) and that method would load
"fpdf/FpdfModule.php" and it would find it in the correct directory, no
need to specify an implicit path. I assume that the zend2 engine has
optimizations on it's includes to keep the overhead down, and one way or
another it'll be faster than us writing a handler for it, so we could
use the existing PHP functionality to easily solve the problem while
presumably keeping down overhead.
Anyway, that was a lot of brainstorming and it's rough, but that's kinda
what I was thinking about.
Richard
Richard Bateman
Rick Gigger
That's probably a better behavior in most cases. It should probably
be something like zoop::overrideClass instead of zoop::registerClass.
The only difference begin that one throws an error. It's better to
force them to indicate when they intend to override a class.
> The primary thing that got me thinking about
> this is when I was migrating an existing project over to the new zoop
> framework from pehppy. In the original pehppy.php that worked very
> similar to your zoop.php (so similar, in fact, that I'm astounded at
> how
> closely we built our systems to each other) there is a loadExtensions
> method that works pretty much just like your loadLib method, except it
> first checks an "extensions" directory in the script root, and then it
> checks the fw root dir as it loads. For the particular problem that
> I'm
> dealing with now, that would work quite well, since I have an
> extension
> from the old framework that I want to use with the new, but I don't
> know
> that I want to add it to the official repository (particularly since
> I'm
> not certain what reasons excluded it, and because it's old). I don't
> want to rewrite all my code that used it, so for now I have just
> manually included the "fpdf" stuff.
Yeah, I'm sure we can come up with a good way for loading modules
outside the main directory.
> That got me thinking, though, that there might be times when we'd want
> to use different versions of the same extension, it would be nice to
> have a way to "override" the "official" version. really, that's not
> that important to me right now, since I don't need to do it at the
> moment... it was just a thought that popped up in response to the
> other.
Yeah, we should cross that bridge when we come to it.
> I like where you're going with the external frameworks idea... there
> are
> a lot of code libraries that we use sometimes that don't go into the
> main branch, and it would be great to have a "standard" way to include
> them. Another thing that would be good is to have a way to detect if
> the module is loaded... for example, the PEHPPY class kept track of
> all
> loaded libraries in a global (non-session, of course) variable, and
> then
> you could call requireExtension("fpdf"), and if the extension was
> already loaded it wouldn't do anything, otherwise it would try to load
> it. This is great for libraries that depend on other libraries,
> because
> then you don't have to know all the dependencies, it will load them
> automatically, but with a minimum of file I/O.
I definitely planned that but I'm not sure if I implemented it yet.
That's a really interesting idea. My idea was more along the lines of:
zoop::loadModule('module_name') loads something from the default
repository.
$framework = zoop::addFramework('mymods', '/home/apps/code/lib/
mycustomlibrary') adds in a new framework and returns a framework
object.
$framework->loadModule('mycustommodule') then loads from the new place
There are two things to take into consideration. For one there is a
balance between the extra overhead of making the include path bigger
and requiring php to search more locations before it finds the right
file and the extra overhead for the programmer of having to do more
manual work managing the repositories. The second issue is that doing
manually allows you to have complete control, so if you wanted to
switch between modules with the same name but in two different
locations you could do it by loading it from the specific framework
that you wanted. That might end up being a big deal, and I don't
think the overhead would be a very big deal.
Rick