php-general Digest 18 May 2013 01:05:44 -0000 Issue 8234
Topics (messages 321102 through 321114):
Re: A Good OOP Tutorial/Read?
321102 by: Stuart Dallas
321103 by: Sebastian Krebs
321104 by: Tedd Sperling
321105 by: Matijn Woudt
321106 by: Stuart Dallas
321107 by: Pøemysl Fiala
321108 by: David Harkness
Re: Saving session to database
321109 by: Matijn Woudt
321110 by: Lester Caine
321111 by: Matijn Woudt
321112 by: Andrew Ballard
321113 by: Lester Caine
looking for a PDF generator class/library for PHP 5?
321114 by: dealTek
Administrivia:
To subscribe to the digest, e-mail:
php-general-digest-subscr...@lists.php.net
To unsubscribe from the digest, e-mail:
php-general-digest-unsubscr...@lists.php.net
To post to the list, e-mail:
php-gene...@lists.php.net
----------------------------------------------------------------------
--- Begin Message ---
On 17 May 2013, at 14:04, Tedd Sperling <tedd.sperl...@gmail.com> wrote:
> I thank you for your addition, but what you provided did nothing to explain
> the difference between abstract and interface.
>
> In your example:
>
> An abstract Shape with Circle and Square inheriting.
>
> OR
>
> An interface Shape with Circle and Square implementing.
>
> Does exactly the same thing -- so where's the difference?
An interface does what it says on the tin: it describes an interface that a
class can then tell the world it implements.
An abstract class provides functionality as well as an interface description.
An abstract class cannot be instantiated, it can only be extended.
The logging example given by someone earlier in this thread is the most common
example given for interfaces. This is where the interface is defined as an API
for others to implement and/or use which then enables users to pick and choose
the combination of implementations they want to use based on their requirements
without needing to change any of the code of either class.
Abstract classes are more likely to be used where there is a set of shared
functionality that is required by several other classes, but which is not
functionally useful by itself. An example of this from a current project of
mine is in aggregating news sources (RSS, scraping, custom formats, etc).
I have an abstract base class which supplies common code to parse and process
data, and some abstract methods that must be implemented by any class that
extends it because the abstract class methods may call them. The abstract class
also contains a static factory method for getting instances of the
type-specific classes.
With this architecture the users of the abstract class never see the derived
classes so there's no need to publish an interface for them to use.
Does that help at all?
-Stuart
--
Stuart Dallas
3ft9 Ltd
http://3ft9.com/
--- End Message ---
--- Begin Message ---
2013/5/17 Tedd Sperling <tedd.sperl...@gmail.com>
> Nick:
>
> I thank you for your addition, but what you provided did nothing to
> explain the difference between abstract and interface.
>
> In your example:
>
> An abstract Shape with Circle and Square inheriting.
>
> OR
>
> An interface Shape with Circle and Square implementing.
> Does exactly the same thing -- so where's the difference?
>
>
- The first one allows to contain implemented methods. Interfaces enforce
"contract only", which makes them more stable on the long run. Sooner or
later (or right from the beginning) someone _will_ implement a method in
that class, which will loosen the separation between the contract and the
implementation. And then it begins, that it is hard to distinguish, what
from this class is contract (and should _never_ change without a good
reason) and what is implementation, that can change.
- It is semantically different as first one states "Circle _is a_ Shape",
whereas interfaces defines their relationship more like "Circle _behaves
like_ a Shape".
- In many languages you can only extend from one class.
Of course: Technically they do the same, but thats not the point ;) Also
technically you don't _require_ interfaces at all. As mentioned: Most of
this happens in ones mind. For example if you change an interface, you
should _always_ expect to break something ;)
Most of OOP isn't about syntax or technical features anyway, but it is
about concepts (design and so on).
And as a sidenote: I don't say (and don't believe ;)) that my explanation
is completely academically correct ;)
>
> Also, your:
>
> Please make an effort to understand polymorphic concepts of OOP as
> they are rudimentary. Without that one will never grasp OO Patterns
> (Gang of Four).
>
> Was more insulting than helpful. Polymorphism was not the question asked.
>
> Clearly the getArea() method is polymorphic and overridden in both Circle
> and Shape classes and also in BOTH abstract and interface examples.
>
> Additionally, I'm not sure what:
>
> > (int double side)
>
> means.
>
> Cheers,
>
> tedd
>
>
> _____________________
> tedd.sperl...@gmail.com
> http://sperling.com
>
>
> -----
>
> On May 16, 2013, at 8:47 PM, Nick Khamis <sym...@gmail.com> wrote:
>
> > interface Shape {
> > public double getArea();
> > }
> >
> > class Circle implements Shape {
> > double radius;
> > public Circle(int double radius) {
> > this.radius = radius;
> > }
> >
> > public double getArea() {
> > return (radius * radius * 3.1415);
> > }
> >
> > }
> >
> > class Square implements Shape {
> > double side;
> >
> > public Square(int double side) {
> > this.side = side;
> > }
> >
> > double getArea() {
> > return (side * side);
> > }
> > }
> >
> >
> > Please make an effort to understand polymorphic concepts of OOP as
> > they are rudimentary. Without that one will never grasp OO Patterns
> > (Gang of Four).
> >
> > Ninus.
> >
> > On 5/16/13, Tedd Sperling <tedd.sperl...@gmail.com> wrote:
> >> Thanks to both Bastien and Sebastian:
> >>
> >> While I understand that an interface is like an abstract Class, in that
> you
> >> don't have to flesh-out your methods, but rather where you define
> exactly
> >> how Classes who implement that interface will be required to flesh-out
> those
> >> methods. But so what? What's the point?
> >>
> >> Without giving me complicated examples, just give me one simple example
> that
> >> illustrates the advantage of using an interface over writing a new Class
> >> where you flesh-out whatever methods you want. After all, an interface
> >> requires the same thing, does it not?
> >>
> >> As such, I just don't see the advantage interfaces bring.
> >>
> >> Cheers,
> >>
> >> tedd
> >>
> >>
> >> _____________________
> >> tedd.sperl...@gmail.com
> >> http://sperling.com
> >>
> >>
> >>
> >> --
> >> PHP General Mailing List (http://www.php.net/)
> >> To unsubscribe, visit: http://www.php.net/unsub.php
> >>
> >>
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
github.com/KingCrunch
--- End Message ---
--- Begin Message ---
Stuart:
You said:
> An interface does what it says on the tin: it describes an interface that a
> class can then tell the world it implements.
>
> An abstract class provides functionality as well as an interface description.
> An abstract class cannot be instantiated, it can only be extended.
>
> The logging example given by someone earlier in this thread is the most
> common example given for interfaces. This is where the interface is defined
> as an API for others to implement and/or use which then enables users to pick
> and choose the combination of implementations they want to use based on their
> requirements without needing to change any of the code of either class.
I understand the "stated" differences between abstract and interface. I can
cite what the differences are, but I don't see the practical application
differences. To me there is no difference between an abstract class (without
method declarations) and an interface.
However, I view an interface as a statement (a contract) where IF you want
someone to use your code you outline the methods you require them to flesh-out
in their code -- but I would like to see a simple example of that.
I vaguely get the logging example given by Larry, but I'm not good at abstract
thinking -- I need a concrete simple example.
I tried to create a demo where I had a Toaster Class that contained
breadNumber() and toastSetting() methods and then created an interface so my
students could use the Toaster, but it didn't really hold up as well as I
wanted.
So, can anyone give me a simple example where an interface is used so I can
easily explain why they are important?
Thanks,
tedd
_____________________
tedd.sperl...@gmail.com
http://sperling.com
--- End Message ---
--- Begin Message ---
On Fri, May 17, 2013 at 4:04 PM, Tedd Sperling <tedd.sperl...@gmail.com>wrote:
> Stuart:
>
> You said:
>
> > An interface does what it says on the tin: it describes an interface
> that a class can then tell the world it implements.
> >
> > An abstract class provides functionality as well as an interface
> description. An abstract class cannot be instantiated, it can only be
> extended.
> >
> > The logging example given by someone earlier in this thread is the most
> common example given for interfaces. This is where the interface is defined
> as an API for others to implement and/or use which then enables users to
> pick and choose the combination of implementations they want to use based
> on their requirements without needing to change any of the code of either
> class.
>
> I understand the "stated" differences between abstract and interface. I
> can cite what the differences are, but I don't see the practical
> application differences. To me there is no difference between an abstract
> class (without method declarations) and an interface.
>
> However, I view an interface as a statement (a contract) where IF you want
> someone to use your code you outline the methods you require them to
> flesh-out in their code -- but I would like to see a simple example of
> that.
>
> I vaguely get the logging example given by Larry, but I'm not good at
> abstract thinking -- I need a concrete simple example.
>
> I tried to create a demo where I had a Toaster Class that contained
> breadNumber() and toastSetting() methods and then created an interface so
> my students could use the Toaster, but it didn't really hold up as well as
> I wanted.
>
> So, can anyone give me a simple example where an interface is used so I
> can easily explain why they are important?
>
> Thanks,
>
> tedd
>
There are plenty, but they are never required. I see interfaces more as
some kind of documentation in PHP code, they have much more advantages in
other languages (eg. Java).
A good example would be if you build a product that allows plugins to be
used. You would create an interface (which requires the functions init,
execute and finish for example), and state that any plugin should implement
that interface and hese functions.
It's the cleaner way of doing things, but it surely would work the same as
if you didn't use an interface, and just told in your documentation that a
class should have these 3 functions.
- Matijn
--- End Message ---
--- Begin Message ---
On 17 May 2013, at 15:04, Tedd Sperling <tedd.sperl...@gmail.com> wrote:
> Stuart:
>
> You said:
>
>> An interface does what it says on the tin: it describes an interface that a
>> class can then tell the world it implements.
>>
>> An abstract class provides functionality as well as an interface
>> description. An abstract class cannot be instantiated, it can only be
>> extended.
>>
>> The logging example given by someone earlier in this thread is the most
>> common example given for interfaces. This is where the interface is defined
>> as an API for others to implement and/or use which then enables users to
>> pick and choose the combination of implementations they want to use based on
>> their requirements without needing to change any of the code of either class.
>
> I understand the "stated" differences between abstract and interface. I can
> cite what the differences are, but I don't see the practical application
> differences. To me there is no difference between an abstract class (without
> method declarations) and an interface.
That's true, there is no difference if the abstract class has no method
declarations. But by the same token, that's the difference. It's a syntactical
difference rather than a conceptual difference.
> However, I view an interface as a statement (a contract) where IF you want
> someone to use your code you outline the methods you require them to
> flesh-out in their code -- but I would like to see a simple example of that.
That's not what an "interface" is for. I can see how the word is confusing as
you can call the API of both an interface and a class (abstract and not) an
interface, but in this context the word interface means the thing itself, not
an aspect of the thing. An interface is an interface and does nothing more than
define the API. An abstract class may also have methods and member variables.
> I vaguely get the logging example given by Larry, but I'm not good at
> abstract thinking -- I need a concrete simple example.
>
> I tried to create a demo where I had a Toaster Class that contained
> breadNumber() and toastSetting() methods and then created an interface so my
> students could use the Toaster, but it didn't really hold up as well as I
> wanted.
>
> So, can anyone give me a simple example where an interface is used so I can
> easily explain why they are important?
I've knocked up a quick example of the logger use case:
https://gist.github.com/3ft9/5599326
Note that if I publish that iLogger interface to others and let them provide
implementations against it people can use their logging classes with my user
class without any changes. Yes, this could be accomplished by using "abstract
class" instead of "interface" but then it's more than just an interface that
I'm publishing.
If you're looking for a reason why interfaces exist when abstract classes can
accomplish the same task you need to talk to someone more academically minded
than me. For me, interfaces have their place because they specifically limit
what you're getting from a third party to an API definition, rather than it
also containing additional code that should be audited before being used in
your software.
Your toaster example would work, but I think you need to switch from the large
object to a smaller aspect for it to make sense. Rather than being able to
replace the whole toaster from their code, imagine if they wanted to replace a
module within the toaster that determines the pattern to be burnt on to the
bread. The Toaster class could optionally take an object that implements
iToasterPattern which the students could supply to change the pattern burnt. To
enable them to use that you would provide them with the API to the Toaster
object so they can talk to it, and the iToasterPattern interface so they can
provide their own implementation of iToasterPattern.
-Stuart
--
Stuart Dallas
3ft9 Ltd
http://3ft9.com/
--- End Message ---
--- Begin Message ---
Interfaces...I will add my 2 cents to what was already said.
You don't need them, but they improve quality of your code. Your application is easily maintained, improved, understandable, accessible, more cleaner, modules can be added easily...
They implements some behavior (example):
interface toastAble
{
function toast($bread);
}
interface talkAble
{
function sayHello();
}
abstract class AToaster implements toastAble
{
function toast($bread)
{
$bread->state = STATE_DELICIOUS;
}
}
class TalkingToaster extends AToaster implements talkAble
{
function sayHello()
{
echo "Hello, would you like to toast your bread?";
}
}
$toaster = new TalkingToaster();
$toaster->sayHello();
Premek.
On Fri, 17 May 2013 16:04:40 +0200, Tedd Sperling <tedd.sperl...@gmail.com> wrote:
> Stuart:
>
> You said:
>
>> An interface does what it says on the tin: it describes an interface
>> that a class can then tell the world it implements.
>>
>> An abstract class provides functionality as well as an interface
>> description. An abstract class cannot be instantiated, it can only be
>> extended.
>>
>> The logging example given by someone earlier in this thread is the most
>> common example given for interfaces. This is where the interface is
>> defined as an API for others to implement and/or use which then enables
>> users to pick and choose the combination of implementations they want
>> to use based on their requirements without needing to change any of the
>> code of either class.
>
> I understand the "stated" differences between abstract and interface. I
> can cite what the differences are, but I don't see the practical
> application differences. To me there is no difference between an
> abstract class (without method declarations) and an interface.
>
> However, I view an interface as a statement (a contract) where IF you
> want someone to use your code you outline the methods you require them
> to flesh-out in their code -- but I would like to see a simple example
> of that.
>
> I vaguely get the logging example given by Larry, but I'm not good at
> abstract thinking -- I need a concrete simple example.
>
> I tried to create a demo where I had a Toaster Class that contained
> breadNumber() and toastSetting() methods and then created an interface
> so my students could use the Toaster, but it didn't really hold up as
> well as I wanted.
>
> So, can anyone give me a simple example where an interface is used so I
> can easily explain why they are important?
>
> Thanks,
>
> tedd
>
>
> _____________________
> tedd.sperl...@gmail.com
>
http://sperling.com>
> --
> PHP General Mailing List (
http://www.php.net/)
> To unsubscribe, visit:
http://www.php.net/unsub.php>
--- End Message ---
--- Begin Message ---
On Fri, May 17, 2013 at 7:04 AM, Tedd Sperling <tedd.sperl...@gmail.com>wrote:
> To me there is no difference between an abstract class (without method
> declarations) and an interface.
>
The key difference in OO languages that do not allow multiple inheritance
is that you can always add an interface to an existing class but you can
only mix in an abstract class if your class doesn't extend another.
Let's say you want to define the contract for a UserDataAccessObject with
query and CRUD methods. If you make it an abstract class, I cannot
implement that contract using my AbstractMysqlDao base class. With an
interface, I can do
class MysqlUserDao
extends AbstractMysqlDao
implements UserDataAccessObject
Being a dynamic language, PHP allows you to fulfill a contract without
using interfaces at all. You can call findUserByLogin() on any object--even
those that don't declare that interface via __call(). However, you won't be
able to pass your objects to methods that use parameter type hinting. This
is where interfaces really shine, and they become more important as your
project grows in complexity. They are certainly *not* required to make good
use of OOP, especially in PHP/Python/Ruby.
However, I view an interface as a statement (a contract) where IF you want
> someone to use your code you outline the methods you require them to
> flesh-out in their code -- but I would like to see a simple example of
> that.
>
Interfaces come in handy when implementing the visitor and observer
patterns. Simple example are always contrived, but here's mine:
interface Engine {
function orderFuel(Store $store);
function setSpeed($mph);
}
class SteamEngine implements Engine {
function orderFuel(Store $store) {
$store->order('coal', 1000, WeightUnit::POUND);
}
function setSpeed($mph) {
if ($mph >= 80) {
throw new InvalidArgumentException('Cannot exceed 80mph');
}
$this->loadFuel(...);
}
}
class MrFusion implements Engine {
function orderFuel(Store $store) {
$store->order('aluminum can');
$store->order('banana peel');
}
function setSpeed($mph) {
if ($mph >= 88 && empty($this->destinationTime)) {
throw new IllegalStateException('Must set desired time
travel destination');
}
$this->adjustThrottle($mph - $this->speed);
}
}
You could make Engine an abstract class, but that would reduce your users'
choice.
David
--- End Message ---
--- Begin Message ---
On Thu, May 16, 2013 at 2:49 PM, Lester Caine <les...@lsces.co.uk> wrote:
> Matijn Woudt wrote:
>
>>
>>
>>
>> On Thu, May 16, 2013 at 10:43 AM, Lester Caine <les...@lsces.co.uk
>> <mailto:les...@lsces.co.uk>> wrote:
>>
>> I'm having a problem with webtrees ... http://webtrees.net/
>> My copy is running on http://webtrees.lsces.org.uk and you will see
>> that it
>> is throwing an error relating to the session handling.
>>
>> Running Apache 2.2.22, PHP5.4.14, MySQL 5.5.31 (
>> http://lsces.org.uk/phpinfo.__**php<http://lsces.org.uk/phpinfo.__php><
>> http://lsces.org.uk/phpinfo.**php <http://lsces.org.uk/phpinfo.php>> )
>>
>>
>> If I comment out the session_set_save_handler() section of
>> session.php then
>> I can log in and use the site. Have tried reworking that as a
>> SessionHandlerInterface without any success. As far as I can see, the
>> 'write' function of the handler is not being called and while there
>> are
>> various notes about problems with PHP5.4 blocking access to the write
>> and
>> close functions, none of the fixes I have tried have resulted in a
>> working
>> setup.
>>
>> Anybody seen this problem with PHP5.4?
>>
>> http://lsces.org.uk/hg/__**webtrees/file/dcf6ff358108/__**
>> includes/session.php#l334<http://lsces.org.uk/hg/__webtrees/file/dcf6ff358108/__includes/session.php#l334>
>>
>> <http://lsces.org.uk/hg/**webtrees/file/dcf6ff358108/**
>> includes/session.php#l334<http://lsces.org.uk/hg/webtrees/file/dcf6ff358108/includes/session.php#l334>>
>> is
>> the code that seems to be failing.
>>
>>
>> What error do you get? I tried loading the site but it shows up fine.
>> In general, you should post the error message in your email anyway, for
>> two reasons:
>> 1) Most people on this list don't bother to open a (terrible slow)
>> website.
>> 2) Archives, so if anyone after you comes up with the same problem, he
>> will be
>> able to refer to the archives to find his solution.
>>
>
> Been working on this most of the morning without success :(
> Faulty version is back up, and showing all the error messages, but
> basically ...
>
> ERROR 2: session_regenerate_id(): Session object destruction failed
> 0 Error occurred on in function session_regenerate_id
> But I think it's the initial session write that is failing
>
> ERROR 2: session_write_close(): Failed to write session data (user).
> Please verify that the current setting of session.save_path is correct
> (/var/lib/php5)
> 0 Error occurred on in function session_write_close
>
> But it should be writing to the database not the file directory.
>
>
>
It seems to me the session functions are failing, probably due to problems
with the database. Have you checked that there actually is a ##session
table in your database?
You might want to add some debugging code to these functions, to check if
errors occur with inserting or retrieving the sessions from the database.
- Matijn
--- End Message ---
--- Begin Message ---
Matijn Woudt wrote:
It seems to me the session functions are failing, probably due to problems with
the database. Have you checked that there actually is a ##session table in your
database?
You might want to add some debugging code to these functions, to check if errors
occur with inserting or retrieving the sessions from the database.
Well past that stage without making any progress.
Using the write function outside of the session_set_save_handler() it works
perfectly, and then the read can see the saved sessions and can load them.
I am convinced that something is wrong with the general setup which is
preventing the write and close from firing when it should. I can not trace any
attempt to call the write function in the session handling.
I'm currently checking out the adodb-session handler which WAS working in PHP5.3
but seems to be showing similar problems in PHP5.4
--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
--- End Message ---
--- Begin Message ---
On Fri, May 17, 2013 at 8:07 PM, Lester Caine <les...@lsces.co.uk> wrote:
> Matijn Woudt wrote:
>
>>
>> It seems to me the session functions are failing, probably due to
>> problems with
>> the database. Have you checked that there actually is a ##session table
>> in your
>> database?
>> You might want to add some debugging code to these functions, to check if
>> errors
>> occur with inserting or retrieving the sessions from the database.
>>
>
> Well past that stage without making any progress.
> Using the write function outside of the session_set_save_handler() it
> works perfectly, and then the read can see the saved sessions and can load
> them.
>
> I am convinced that something is wrong with the general setup which is
> preventing the write and close from firing when it should. I can not trace
> any attempt to call the write function in the session handling.
>
> I'm currently checking out the adodb-session handler which WAS working in
> PHP5.3 but seems to be showing similar problems in PHP5.4
>
>
Well, I'm not sure what would be the problem here, but some general
comments:
There have been various changes in session handling between 5.3 and 5.4, so
most likely it is in there. Check if there are any references to
register_shutdown_function, and replace them with session_register_shutdown.
Second, check the return value of session_set_save_handler, it is a bad
habit not checking return value of a function, just because it works.
If that doesn't help, take the session piece out of the big framework, and
test it in a separate file. If that also fails, you've got a small piece of
code you can post here which will encourage others to have a look at it at
their box.
- Matijn
--- End Message ---
--- Begin Message ---
I've found database session storage requires extra diligence in error
handling. When I see that error at 0 it is usually because something blew
up either before the session handler was ready or after it was torn down.
Andrew
On May 17, 2013 2:42 PM, "Matijn Woudt" <tijn...@gmail.com> wrote:
> On Fri, May 17, 2013 at 8:07 PM, Lester Caine <les...@lsces.co.uk> wrote:
>
> > Matijn Woudt wrote:
> >
> >>
> >> It seems to me the session functions are failing, probably due to
> >> problems with
> >> the database. Have you checked that there actually is a ##session table
> >> in your
> >> database?
> >> You might want to add some debugging code to these functions, to check
> if
> >> errors
> >> occur with inserting or retrieving the sessions from the database.
> >>
> >
> > Well past that stage without making any progress.
> > Using the write function outside of the session_set_save_handler() it
> > works perfectly, and then the read can see the saved sessions and can
> load
> > them.
> >
> > I am convinced that something is wrong with the general setup which is
> > preventing the write and close from firing when it should. I can not
> trace
> > any attempt to call the write function in the session handling.
> >
> > I'm currently checking out the adodb-session handler which WAS working in
> > PHP5.3 but seems to be showing similar problems in PHP5.4
> >
> >
> Well, I'm not sure what would be the problem here, but some general
> comments:
> There have been various changes in session handling between 5.3 and 5.4, so
> most likely it is in there. Check if there are any references to
> register_shutdown_function, and replace them with
> session_register_shutdown.
> Second, check the return value of session_set_save_handler, it is a bad
> habit not checking return value of a function, just because it works.
> If that doesn't help, take the session piece out of the big framework, and
> test it in a separate file. If that also fails, you've got a small piece of
> code you can post here which will encourage others to have a look at it at
> their box.
>
> - Matijn
>
--- End Message ---
--- Begin Message ---
Andrew Ballard wrote:
I've found database session storage requires extra diligence in error handling.
When I see that error at 0 it is usually because something blew up either before
the session handler was ready or after it was torn down.
Found the culprit ...
Suhosin
http://www.simplemachines.org/community/index.php?topic=486606.0 gives the
pointer but I've not followed through on an updated version. This is a stock
SUSE install and I don't want to manually 'fix' it so I've just disabled Suhosin.
--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
--- End Message ---
--- Begin Message ---
Hi all,
I'm looking into a good versatile PDF generator class/library to use with PHP
5? --- Preferably one which is maintained somewhat recently...
Mostly needed for basic pages, but I also have some longer reports (more than
one 8.5" x 11" page) and it would be nice if the pdf was able to split it up
without losing part of the font when crossing page boundaries etc...
--
Thanks,
Dave - DealTek
deal...@gmail.com
[db-3]
--- End Message ---
