php-general Digest 31 Aug 2008 12:53:56 -0000 Issue 5655
Topics (messages 279116 through 279136):
how to write good code
279116 by: Shiplu
279117 by: Eric Gorr
279122 by: Ross McKay
Re: Individual bulk e-mails - performance question
279118 by: Manuel Lemos
279119 by: Diogo Neves
279120 by: Manuel Lemos
279127 by: Robert Cummings
279130 by: Per Jessen
279131 by: Robert Cummings
279133 by: Per Jessen
279134 by: Robert Cummings
Re: Php installation
279121 by: David Robley
Re: ASCII Captcha
279123 by: Sancar Saran
279124 by: Robert Cummings
279125 by: Robert Cummings
279126 by: Robert Cummings
279128 by: Diogo Neves
279129 by: Ross McKay
279132 by: Robert Cummings
279135 by: Diogo Neves
casting static property
279136 by: Diogo Neves
Administrivia:
To subscribe to the digest, e-mail:
[EMAIL PROTECTED]
To unsubscribe from the digest, e-mail:
[EMAIL PROTECTED]
To post to the list, e-mail:
[EMAIL PROTECTED]
----------------------------------------------------------------------
--- Begin Message ---
I wanna know how to write good code in php.
Not oop stuff. I wanna know how to write a good php code file.
documentation, comments. indentation etc.
what are the good practices??
--
Blog: http://talk.cmyweb.net/
Follow me: http://twitter.com/shiplu
--- End Message ---
--- Begin Message ---
On Aug 30, 2008, at 8:17 PM, Shiplu wrote:
I wanna know how to write good code in php.
Not oop stuff. I wanna know how to write a good php code file.
documentation, comments. indentation etc.
what are the good practices??
Studying design patterns are a great start to learning how to write
good code. Such things apply not only to PHP, but to other languages
as well.
A couple of good books are:
Design Patterns: Elements of Reusable Object-Oriented Software
# ISBN-10: 0201633612
# ISBN-13: 978-0201633610
Head First Design Patterns (Head First)
# ISBN-10: 0596007124
# ISBN-13: 978-0596007126
As for comments, the best comments are those that include 'why' the
code was written the way it was. What the code does can be discerned
by studying the code and is generally less useful.
As for code style (which includes indentation), there is no single
good style...pick something that looks good to you and use it. The
most important thing is to be consistent. For example, if you choose
to write an if statement like:
if ( ... )
{
...
...
}
don't use that in some parts of your code and
if ( ... ) {
...
...
}
in other parts.
As for other tips to writing good PHP code, I'd recommend taking a
look at:
Essential PHP Security
# ISBN-10: 059600656X
# ISBN-13: 978-0596006563
But, basically, it just comes down to practice, practice and more
practice.
--- End Message ---
--- Begin Message ---
On Sat, 30 Aug 2008 20:17:18 -0400, Shiplu wrote:
>I wanna know how to write good code in php.
>Not oop stuff. I wanna know how to write a good php code file.
>documentation, comments. indentation etc.
>what are the good practices??
Find out what "bad" is by reading this:
http://thedailywtf.com/Series/CodeSOD.aspx
Then, don't do it like that!
But seriously, you might want to check out this page on Wikipedia, and
follow some of its references:
http://en.wikipedia.org/wiki/Programming_style
--
Ross McKay, Toronto, NSW Australia
"Let the laddie play wi the knife - he'll learn"
- The Wee Book of Calvin
--- End Message ---
--- Begin Message ---
Hello,
on 08/30/2008 02:40 PM Merlin said the following:
I am running a travel community where users want to get informed on
changes inside different groups they have subscribed to.
At the moment I am doing this with a for loop that generates an
individual e-mail sent to them via phpmailer. That works, however the
submit of the content upload form (that triggers the e-mail
notification) now takes several seconds, as more and more users subscribe.
I am thinking about placing the info on the individual e-mail inside a
ascii txt file that will be read by a cron job which will send the
e-mail instead. Something like every 5 minutes reading it line by line
and then after sending it removing the line.
e.g:
for:[EMAIL PROTECTED]; body:individual
for:[EMAIL PROTECTED]; body:other email
Does this sound like a plan? Or do you believe that there are better
ways doing it? I could imagine that I would run into problems a few
months from now if for example the cron job will be triggered a second
time, while the first one has not finished.
Any ideas or suggestions? Thank you for any help.
While it is a good idea to off-load e-mail delivery to a script run from
cron, it seems odd that each mail takes several seconds to deliver.
I suspect that you sending messages in a less efficient way. Maybe you
are queueing messages using SMTP (which is the slowest way to queue
messages) or you are using sendmail on your system and it is configured
by default to attempt to deliver the messages immediately, making your
PHP script hang while the message is not accepted by the remote server.
There are much better ways to do it by just telling the mail system to
queue the messages without holding on the PHP script.
On the other hand, if the time it takes build your messages but the
messages have the same contents for all the receipients, you can also
use some good e-mail components with caching support.
In that case, I recommend that you use for instance this MIME message
class that provides message body caching support, so you can send
messages to different receipients and cache the building of message body
parts and avoid overhead when sending to a new receipient.
It also provides different means to send messages and solve the overhead
of message delivery by forcing the messages to queue by your local and
be delivered later whenever possible, so your PHP script is freed to
send messages to other recipients.
http://www.phpclasses.org/mimemessage
--
Regards,
Manuel Lemos
Find and post PHP jobs
http://www.phpclasses.org/jobs/
PHP Classes - Free ready to use OOP components written in PHP
http://www.phpclasses.org/
--- End Message ---
--- Begin Message ---
Well, I agree that sending it by an external process more specialized
in sending emails can be faster and more eficient, but it's harder to
control... sometimes you need to know in your php if email was really
sent and do something, and while I'm not saying it's impossible, I'm
sure it's a little more complicated...
Yet, if sending email don't need to be tracked, then external tool
world possible be better...
Anyway, don't ask me how to do that, I'm more confortable doing things in PHP :)
On Sun, Aug 31, 2008 at 2:31 AM, Manuel Lemos <[EMAIL PROTECTED]> wrote:
> Hello,
>
> on 08/30/2008 02:40 PM Merlin said the following:
>>
>> I am running a travel community where users want to get informed on
>> changes inside different groups they have subscribed to.
>>
>> At the moment I am doing this with a for loop that generates an individual
>> e-mail sent to them via phpmailer. That works, however the submit of the
>> content upload form (that triggers the e-mail notification) now takes
>> several seconds, as more and more users subscribe.
>>
>> I am thinking about placing the info on the individual e-mail inside a
>> ascii txt file that will be read by a cron job which will send the e-mail
>> instead. Something like every 5 minutes reading it line by line and then
>> after sending it removing the line.
>> e.g:
>> for:[EMAIL PROTECTED]; body:individual
>> for:[EMAIL PROTECTED]; body:other email
>>
>> Does this sound like a plan? Or do you believe that there are better ways
>> doing it? I could imagine that I would run into problems a few months from
>> now if for example the cron job will be triggered a second time, while the
>> first one has not finished.
>>
>> Any ideas or suggestions? Thank you for any help.
>
> While it is a good idea to off-load e-mail delivery to a script run from
> cron, it seems odd that each mail takes several seconds to deliver.
>
> I suspect that you sending messages in a less efficient way. Maybe you are
> queueing messages using SMTP (which is the slowest way to queue messages) or
> you are using sendmail on your system and it is configured by default to
> attempt to deliver the messages immediately, making your PHP script hang
> while the message is not accepted by the remote server.
>
> There are much better ways to do it by just telling the mail system to queue
> the messages without holding on the PHP script.
>
> On the other hand, if the time it takes build your messages but the messages
> have the same contents for all the receipients, you can also use some good
> e-mail components with caching support.
>
> In that case, I recommend that you use for instance this MIME message class
> that provides message body caching support, so you can send messages to
> different receipients and cache the building of message body parts and avoid
> overhead when sending to a new receipient.
>
> It also provides different means to send messages and solve the overhead of
> message delivery by forcing the messages to queue by your local and be
> delivered later whenever possible, so your PHP script is freed to send
> messages to other recipients.
>
>
> http://www.phpclasses.org/mimemessage
>
>
> --
>
> Regards,
> Manuel Lemos
>
> Find and post PHP jobs
> http://www.phpclasses.org/jobs/
>
> PHP Classes - Free ready to use OOP components written in PHP
> http://www.phpclasses.org/
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
Thanks for your attention,
Diogo Neves
Web Developer @ SAPO.pt by PrimeIT.pt
--- End Message ---
--- Begin Message ---
Hello,
on 08/30/2008 10:40 PM Diogo Neves said the following:
Well, I agree that sending it by an external process more specialized
in sending emails can be faster and more eficient, but it's harder to
control... sometimes you need to know in your php if email was really
sent and do something, and while I'm not saying it's impossible, I'm
sure it's a little more complicated...
Knowing whether the message was successfully delivered or not, is
something that you often will not know.
Nowadays many SMTP servers use grey listing. This means that first the
server says it cannot accept the message temporarily, but it will accept
after several minutes.
Even if the server accepts the message immediately, he may bounce or
discard it later.
So it is utopic to expect any reliable answer about the deliverability
of a message. It is better not rely your software on the accuracy of any
response from the remote server.
In any case, for really urgent messages, the MIME message class can use
the SMTP driver to deliver messages directly to the remote SMTP server
bypasing the local mail server. If it fails the delivery, you should
relay it to the local mail server to retry deliverying it later. Take a
look at the test_urgent_mail.php script for an example:
http://www.phpclasses.org/mimemessage
Yet, if sending email don't need to be tracked, then external tool
world possible be better...
Anyway, don't ask me how to do that, I'm more confortable doing things in PHP :)
PHP is very efficient if you use it in a smart way. For instance, you
can cache message bodies using the MIME message above to avoid message
composition overhead.
As for the actual SMTP delivery, the network connection and TCP data
exchanging is usually so slow that any overhead of PHP script execution
is meaningless.
--
Regards,
Manuel Lemos
Find and post PHP jobs
http://www.phpclasses.org/jobs/
PHP Classes - Free ready to use OOP components written in PHP
http://www.phpclasses.org/
--- End Message ---
--- Begin Message ---
On Sat, 2008-08-30 at 22:14 +0200, Per Jessen wrote:
> Merlin wrote:
>
> > I am thinking about placing the info on the individual e-mail inside a
> > ascii txt file that will be read by a cron job which will send the
> > e-mail instead. Something like every 5 minutes reading it line by line
> > and then after sending it removing the line.
> > e.g:
> > for:[EMAIL PROTECTED]; body:individual
> > for:[EMAIL PROTECTED]; body:other email
> >
> > Does this sound like a plan? Or do you believe that there are better
> > ways doing it?
>
> Sounds pretty good to me.
>
> > I could imagine that I would run into problems a few
> > months from now if for example the cron job will be triggered a second
> > time, while the first one has not finished.
>
> That's easily taken care of. Instead of a cron-job, you could have a
> script running as a daemon, checking for emails to be sent every 5mins.
That's the same as running a cron every 5 minutes except now you also
need to detect if your daemon dies :) On the plus side though, you
eliminate the overhead of starting up the script every 5 minutes :)
Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP
--- End Message ---
--- Begin Message ---
Robert Cummings wrote:
>> That's easily taken care of. Instead of a cron-job, you could have a
>> script running as a daemon, checking for emails to be sent every
>> 5mins.
>
> That's the same as running a cron every 5 minutes except now you also
> need to detect if your daemon dies :) On the plus side though, you
> eliminate the overhead of starting up the script every 5 minutes :)
It is not the same as it will prevent multiple scripts running
concurrently in case a batch of emails takes longer that 5 minutes.
Checking if the daemon dies - I guess it's a matter of taste or
paranoia, but I don't think it's necessary when the script is
sufficiently simple:
#!/bin/sh
while true
do
<yourscript>
sleep 300
done
/Per Jessen, Zürich
--- End Message ---
--- Begin Message ---
On Sun, 2008-08-31 at 12:12 +0200, Per Jessen wrote:
> Robert Cummings wrote:
>
> >> That's easily taken care of. Instead of a cron-job, you could have a
> >> script running as a daemon, checking for emails to be sent every
> >> 5mins.
> >
> > That's the same as running a cron every 5 minutes except now you also
> > need to detect if your daemon dies :) On the plus side though, you
> > eliminate the overhead of starting up the script every 5 minutes :)
>
> It is not the same as it will prevent multiple scripts running
> concurrently in case a batch of emails takes longer that 5 minutes.
> Checking if the daemon dies - I guess it's a matter of taste or
> paranoia, but I don't think it's necessary when the script is
> sufficiently simple:
>
> #!/bin/sh
> while true
> do
> <yourscript>
> sleep 300
> done
I accomplish the same with cron scripts by using locks with expiry.
Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP
--- End Message ---
--- Begin Message ---
Robert Cummings wrote:
> On Sun, 2008-08-31 at 12:12 +0200, Per Jessen wrote:
>> Robert Cummings wrote:
>>
>> >> That's easily taken care of. Instead of a cron-job, you could
>> >> have a script running as a daemon, checking for emails to be sent
>> >> every 5mins.
>> >
>> > That's the same as running a cron every 5 minutes except now you
>> > also need to detect if your daemon dies :) On the plus side though,
>> > you eliminate the overhead of starting up the script every 5
>> > minutes :)
>>
>> It is not the same as it will prevent multiple scripts running
>> concurrently in case a batch of emails takes longer that 5 minutes.
>> Checking if the daemon dies - I guess it's a matter of taste or
>> paranoia, but I don't think it's necessary when the script is
>> sufficiently simple:
>>
>> #!/bin/sh
>> while true
>> do
>> <yourscript>
>> sleep 300
>> done
>
> I accomplish the same with cron scripts by using locks with expiry.
There are many ways to skin a cat. I also tend to use cron+locks to
avoid multiple concurrent scripts, but for shorter intervals, I tend to
use the daemon.
/Per Jessen, Zürich
--- End Message ---
--- Begin Message ---
On Sun, 2008-08-31 at 12:49 +0200, Per Jessen wrote:
> Robert Cummings wrote:
>
> > On Sun, 2008-08-31 at 12:12 +0200, Per Jessen wrote:
> >> Robert Cummings wrote:
> >>
> >> >> That's easily taken care of. Instead of a cron-job, you could
> >> >> have a script running as a daemon, checking for emails to be sent
> >> >> every 5mins.
> >> >
> >> > That's the same as running a cron every 5 minutes except now you
> >> > also need to detect if your daemon dies :) On the plus side though,
> >> > you eliminate the overhead of starting up the script every 5
> >> > minutes :)
> >>
> >> It is not the same as it will prevent multiple scripts running
> >> concurrently in case a batch of emails takes longer that 5 minutes.
> >> Checking if the daemon dies - I guess it's a matter of taste or
> >> paranoia, but I don't think it's necessary when the script is
> >> sufficiently simple:
> >>
> >> #!/bin/sh
> >> while true
> >> do
> >> <yourscript>
> >> sleep 300
> >> done
> >
> > I accomplish the same with cron scripts by using locks with expiry.
>
> There are many ways to skin a cat.
As tedd would say... none of which the cat will like :)
Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP
--- End Message ---
--- Begin Message ---
On Sat, 30 Aug 2008, It flance wrote:
> Hi,
>
> Apache was already installed in my computer. Anyway now i can run php
> scripts without any problem. The problem is just that if a script
> contains database statements like connection to the database server,
> those statements are ignored while run in the browser but they are
> procesed if run from terminal. So i guess this is a configuration
> problem but i have no idea how to fix it.
>
> Thanks
>
> --- On Sat, 8/30/08, David Robley <[EMAIL PROTECTED]> wrote:
> > From: David Robley <[EMAIL PROTECTED]>
> > Subject: [PHP] Re: Php installation
> > To: [EMAIL PROTECTED]
> > Date: Saturday, August 30, 2008, 7:03 AM
> >
> > It flance wrote:
> > > Hi all,
> > >
> > > I'm using Fedora 8. I installed php, mysql and
> >
> > apache. Now i can run a
> >
> > > script connecting to a database from terminal but not
> >
> > from browser.
> >
> > > Any suggestion?
> >
> > Have you configured apache to process php scripts?
> >
> > See item 14 at
> > http://php.net/manual/en/install.unix.apache2.php
I apologise; I misread your question as not being able to use php through
apache.
I wonder if your php is configured to log errors to a file, rather than
displaying them on the screen when you connect via apache? Check your
apache log files and see if there is something in there that is related.
Cheers
--
David Robley
"Yes, I have read Gulliver's Travels," said Tom swiftly.
Today is Pungenday, the 24th day of Bureaucracy in the YOLD 3174.
--- End Message ---
--- Begin Message ---
http://blogs.zdnet.com/security/?p=1835
That was great.
Human captcha resolvers.
$2 per 1000 resloved captchas...
ouch...
--- End Message ---
--- Begin Message ---
On Sat, 2008-08-30 at 15:02 +0100, Stut wrote:
> On 30 Aug 2008, at 14:05, tedd wrote:
> > At 11:39 PM +0200 8/29/08, Jochem Maas wrote:
> >> I think both tedd and Stut make good points, I guess we'll all be
> >> hacking away at such issues for a long time to come.
> >
> > That's the nature of the beast (no not Stut!)
>
> I am Stut - hear me Roar!!
>
> CAPTCHA's are not a magic bullet, and I'm definitely of the opinion no
> such bullet exists. Each problem is different and we need to think
> about them differently. We all know there has to be a better way, and
> I think we all agree that if possible we wouldn't be using them at
> all. However, while we must recognise that each site we create will
> present different opportunities for validating UGC without needing to
> "fall back" to CAPTCHA's we must also recognise that CAPTCHA's work to
> a certain extent and should not be avoided simply because they're not
> perfect.
>
> I can't remember who said it and I apologise for that, but someone
> mentioned that the person who comes up with a better replacement for
> CAPTCHA's will make billions. Unfortunately this is not true. Any idea
> that has the potential to change the way the world works or plays will
> not reach that potential if it comes with prohibitive licenses or
> royalty fees attached. If it works make it free or adoption will be
> severely restricted which makes it essentially worthless.
>
> That's all I've got to say about that.
Unfortunately I see a convergence of conventional email spam
technologies and online web form spam technologies. Basically this means
wasted time and computer energy filtering out all the crap. As Stut has
pointed out already, the best filter for spam I've encountered is to
reject posts with links :/ Another approach in a similar vein is to
calculate the link to non-link content ratio. I've noticed most spammers
just post a block of links or a sinle link without any content.
Unfortunately, ratio measuring will not be a lasting measure for
reducing spam and we may end up employing full on measures of the likes
of spamassasin once CAPTCHA becomes more weak to automated attacks.
Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP
--- End Message ---
--- Begin Message ---
On Sat, 2008-08-30 at 10:17 -0400, tedd wrote:
> At 3:27 PM +0200 8/30/08, Jochem Maas wrote:
> >
> >2. you can't shut him down either, he does'nt have an off button.
>
> Yeah, he's a lot like his blow-up dolls except you can't deflate him. :-)
WHOOOOOOOOOOAAAAA... "my" blow-up dolls? Since when did they become
mine? I expressly said I was just borrowing them from you.
:)
Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP
--- End Message ---
--- Begin Message ---
On Sat, 2008-08-30 at 19:22 +0200, Jochem Maas wrote:
> tedd schreef:
> > At 3:25 PM +0100 8/30/08, Stut wrote:
> >> in the meantime I stand by my assertion that a 'phone number people
> >> can call with any type of telephone to interact with another human who
> >> can get them past the check without compromising the protection the
> >> check affords is ultimate accessibility.
> >
> > Well, even you can't be right all of the time. :-)
> >
> > That's not bad out of all we discussed to have only one difference of
> > opinion.
>
> obviously Cummings' brainwashing program is not 100% effective ;-)
It all began to fall apart when they refused to look into my eyes while
I waved my hands around and used a low monotone voice.
Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP
--- End Message ---
--- Begin Message ---
Well, I don't know how, but google folks @ gmail are doing a great job
with anti-spam tecnology... i believe that is has something to do with
the massive user base that can more accuratly say what is spam and
blacklist it plus mispelling 'spam' words and the original ones, plus
that '1000's from the same guy with same content' wow.
I really get so less spam comparing with all other webmail clients...
I love gmail :)
On Sun, Aug 31, 2008 at 10:42 AM, Robert Cummings <[EMAIL PROTECTED]> wrote:
> On Sat, 2008-08-30 at 19:22 +0200, Jochem Maas wrote:
>> tedd schreef:
>> > At 3:25 PM +0100 8/30/08, Stut wrote:
>> >> in the meantime I stand by my assertion that a 'phone number people
>> >> can call with any type of telephone to interact with another human who
>> >> can get them past the check without compromising the protection the
>> >> check affords is ultimate accessibility.
>> >
>> > Well, even you can't be right all of the time. :-)
>> >
>> > That's not bad out of all we discussed to have only one difference of
>> > opinion.
>>
>> obviously Cummings' brainwashing program is not 100% effective ;-)
>
> It all began to fall apart when they refused to look into my eyes while
> I waved my hands around and used a low monotone voice.
>
> Cheers,
> Rob.
> --
> http://www.interjinn.com
> Application and Templating Framework for PHP
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
Thanks for your attention,
Diogo Neves
Web Developer @ SAPO.pt by PrimeIT.pt
--- End Message ---
--- Begin Message ---
On Sun, 31 Aug 2008 05:35:42 -0400, Robert Cummings wrote:
>[...] As Stut has
>pointed out already, the best filter for spam I've encountered is to
>reject posts with links :/
This also is what works for me. However, this is for commercial
websites, not blogs / forums, so links are not expected in posts to
these websites. If they were, well... :/
--
Ross McKay, Toronto, NSW Australia
"The chief cause of problems is solutions" -Eric Sevareid
--- End Message ---
--- Begin Message ---
On Sun, 2008-08-31 at 10:58 +0100, Diogo Neves wrote:
> Well, I don't know how, but google folks @ gmail are doing a great job
> with anti-spam tecnology... i believe that is has something to do with
> the massive user base that can more accuratly say what is spam and
> blacklist it plus mispelling 'spam' words and the original ones, plus
> that '1000's from the same guy with same content' wow.
>
> I really get so less spam comparing with all other webmail clients...
> I love gmail :)
I think you hit the nail on the head thought when you mention massive
user base. Probably at the outset of a spam campaign a bunch of users
get the spam, flag it as spam and then google just marks the rest as
spam for the several other million users :)
That said, gmail isn't perfect either which indicates a measure of the
difficulty of this problem.
Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP
--- End Message ---
--- Begin Message ---
Maybe a protocol of SPAM notifications can do da trick...
Something like a system, more or less central that smtp server should
use to exchange information about SPAM, like that u get not only the
gmail base, but a yet bigger set off it... that whould do the trick,
and possible take the internet routers down :)
And even with a more global system it would not be perfect, but @
least I only should need too mark 2/3 mails as spam a day, instead of
10, and with other web clients 100 or more...
Maybe google wanna do it in is 'we are the good folks, not the biggest
monopoly on da world' opensource developement... ;)
On Sun, Aug 31, 2008 at 11:26 AM, Robert Cummings <[EMAIL PROTECTED]> wrote:
> On Sun, 2008-08-31 at 10:58 +0100, Diogo Neves wrote:
>> Well, I don't know how, but google folks @ gmail are doing a great job
>> with anti-spam tecnology... i believe that is has something to do with
>> the massive user base that can more accuratly say what is spam and
>> blacklist it plus mispelling 'spam' words and the original ones, plus
>> that '1000's from the same guy with same content' wow.
>>
>> I really get so less spam comparing with all other webmail clients...
>> I love gmail :)
>
> I think you hit the nail on the head thought when you mention massive
> user base. Probably at the outset of a spam campaign a bunch of users
> get the spam, flag it as spam and then google just marks the rest as
> spam for the several other million users :)
>
> That said, gmail isn't perfect either which indicates a measure of the
> difficulty of this problem.
>
> Cheers,
> Rob.
> --
> http://www.interjinn.com
> Application and Templating Framework for PHP
>
>
--
Thanks for your attention,
Diogo Neves
Web Developer @ SAPO.pt by PrimeIT.pt
--- End Message ---
--- Begin Message ---
Hi all,
Why a static var don't cast as a dynamic one?
See file for more info...
--
Thanks for your attention,
Diogo Neves
Web Developer @ SAPO.pt by PrimeIT.pt
--- End Message ---
