Installable PEAR package

[GoogleCodeExporter]

What would you like dompdf to do:

It'd be handy to create a pear installabe package for dompdf. This would
involve creating a package.xml and using pear to read this package and tar
up the files into one nice neat tgz.

Original issue reported on code.google.com by ryan.mas...@gmail.com on 29 Apr 2009 at 6:06

[GoogleCodeExporter]

Should definitely be a good idea !

Be aware that it might also induce some coding standards...

Original comment by tomd...@gmail.com on 4 Sep 2009 at 10:25

[GoogleCodeExporter]

I think we should wait until the config changes, which was discussed in the 
list[0] not too long ago.

[0]http://groups.google.com/group/dompdf/browse_thread/thread/eabfd48069bceba7

Original comment by davidjme...@gmail.com on 8 Sep 2009 at 7:14

[GoogleCodeExporter]

Is there a status update on this issue? I'm specifically interested in the need 
to decouple the configuration files from the application.

Is this a matter of no one is working on the issue? If so, how open is the 
project to taking new code submissions/RFCs?

Original comment by raymond....@maine.edu on 7 Aug 2012 at 10:43

[GoogleCodeExporter]

We never looked further at this issue. I think that the process to submit a 
package to the pear.net repository is very long.
I don't know what is need to create a new package, but we could host our own 
Pear repository like Zend did on Google Code : http://code.google.com/p/zend/
This would let us make the release when we want.

We are totally open to new code subsmissions! You are welcome to submit patches 
and ideas here.

Original comment by fabien.menager on 8 Aug 2012 at 12:54

[GoogleCodeExporter]

It looks exactly like what we need: http://pirum.sensiolabs.org/

Original comment by fabien.menager on 8 Aug 2012 at 1:22

[GoogleCodeExporter]

Can I suggest the first place we start is by refactoring the configuration 
system? This would at least allow us to move forward with Packagist (read: I 
currently have a dompdf Package I started (dindo/dompdf)) and provide dompdf as 
an easily installable dependency for projects. This step would be needed for 
PEAR as well.

@fabien.menager Pirum is great. I've used it in the past and it is very simple 
to use.

I'll spend some time soon and submit my changes to see what you think. I'll try 
to find some time in the next week or so.

Original comment by raymond....@maine.edu on 9 Aug 2012 at 12:12

[GoogleCodeExporter]

@raymond: I've been thinking it would be nice to change the way dompdf does 
configuration. I rather like the way configuration is done in JS ... though I 
don't know how easy that is to duplicate in PHP. Passing an options array seems 
to be more common. But having a way to specify the defaults would also be nice. 
The runtime settings could obviously be stored in the main dompdf object.

The main issue (though not a huge one) would be ensuring that all references to 
the current configuration constants be rewritten to support accessing the 
settings from the dompdf object.

Original comment by eclecticgeek on 9 Aug 2012 at 3:52

[GoogleCodeExporter]

@electricgeek Off the cuff I would say we create a Configuration class that is 
just a bag of get/set for config options. Classes like DOMPDF will need to 
accept a Configuration object, which means the constructor signature will 
change.

Here is what I'm thinking for a config object: http://pastebin.com/EXrDQDR3

You can see I use "directory" as the example. As I was looking though some of 
the code last night, I noticed that directory is only there for some other 
directory related settings (e.g. lib, include, etc. locations). We could 
probably do away with these via the autoloader.

If we don't want to change the method signatures, an alternative would be to 
make the Configuration object a singelton, and then just replace the defines 
with calls like $config = \DOMPDF\Configuration\Configuration::getInstance(); 
$config->getDirectory();

If we want to specify defaults, I would suggest the defaults be stored on the 
objects as property defaults and are overwritten during instantiation by 
passing in the config to the constructor, or a call to setOptions() (on DOMPDF) 
after instantiation.

Original comment by raymond....@maine.edu on 9 Aug 2012 at 12:24

[GoogleCodeExporter]

That makes sense to me, and looks fairly easy to implement. Does this allow for 
user-defaults to be specified, or would the user have to set the configuration 
each time?

We would also have to look into rewriting the way you load dompdf as well.

Original comment by eclecticgeek on 9 Aug 2012 at 2:59

[GoogleCodeExporter]

@eclecticgeek You have a couple of options:

1) You could specify the options each time or
2) You could extend the Configuration class and set the protected properties to 
what you need and then pass that to DOMPDF.

Note that option 2 will not work if we decide to use a singelton and I would 
suggest we don't do a singelton for that reason. 

As for the way DOMPDF is loaded, I envision a user would create a bootstrap of 
their own. They would create a Configuration object, and then inject it into 
the constructor of a DOMPDF object. They can then perform the operations they 
want.

Original comment by raymond....@maine.edu on 9 Aug 2012 at 3:06

[GoogleCodeExporter]

I would have seen something more like this : http://pastebin.com/gjhdFKp3 
But I'm totally OK with the idea. It must not be a singleton, because there may 
be as many configurations as dompdf objects (even if most of the time there is 
only one).
Please note that it must be PHP 5.0+, so no namespaces :(

And what about the "bootstrap" script that must be included to have the 
autoloader and all, what do you think about a "bootstrap.php"? Is there a more 
usual script name?

Original comment by fabien.menager on 9 Aug 2012 at 9:59

• Changed state: Accepted

[GoogleCodeExporter]

I don't think a bootstrap should be included. I think how to setup autoloading, 
the config object, and dompdf class should be in the install instructions.

Also, as for the config object, I shy away from magic get/set now because it's 
not expressive enough. It hides the intentions of the object.

I thought about the namespace thing after I posted ;-) No worries on that.

Original comment by raymond....@maine.edu on 9 Aug 2012 at 10:45

[GoogleCodeExporter]

In fact, there is already a bootstrap: dompdf_config.inc.php, but its name is 
not really obvious. I was thinking about that because our goal is to give the 
users the simplest way to use dompdf. Including a single file (with an obvious 
name) is something important to me. I know this is not really related to the 
PEAR package, because it should be usable exactly the same way as any other 
PEAR package, but it goes with the way configs are handled.

As for the config object, I like the way I wrote it because we only need to add 
a single line to this class to add a new option. Adding explicitly getters and 
setters is not something I like to do, especially if they all have the same 
code inside...
And magic methods are already used in dompdf, and they work pretty well ;-)

Brian, what do you think about this?

Original comment by fabien.menager on 11 Aug 2012 at 12:53

[GoogleCodeExporter]

On configuration: The downside to having an array of config values on the 
config object is now you can't extend DOMPDF_Configuration into something like 
my own "TestConfiguration" or "ProductionConfiguration" objects unless you 
provide a whole configuration--in some cases I might want to keep the defaults 
from DOMPDF_Configuration.

On bootstrap: If the goal of dompdf_config.inc.php is to be a bootstrap file, 
it should be removed from being included from the CLI scripts. Instead, a 
config file (ini, YAML, XML, etc.) path should be passed in as an argument, 
which will allow the decoupling of the current dompdf_config.inc.php and thus 
allow the config file to live in a different place than in the project's root. 
In the case of PEAR and Packagist, this is a must.

Original comment by raymond....@maine.edu on 11 Aug 2012 at 2:34

[GoogleCodeExporter]

Here is a compromise: http://pastebin.com/qgwYvEAH

It allows get/set if you want (they are dynamic by default) and allows for 
users to extend and create their own pre-defined config files using objects.

Original comment by raymond....@maine.edu on 12 Aug 2012 at 1:50

[GoogleCodeExporter]

Original comment by eclecticgeek on 24 May 2013 at 3:00

• Added labels: Restrict-AddIssueComment-Commit