Nabble - PHP - General

Re: Multilingual website, texts in external JavaScript problem

2009-11-09T04:50:42Z

On Nov 9, 2009, at 1:04 AM, leledumbo <leledumbo_cool@...>
wrote:

>
> I need to create a multilingual website and my framework already
> gives me
> that facility. However, I also use JavaScript quite extensively and
> since
> XHTML 1.0 Strict doesn't allow inline script, I must use
> external .js file.
> The problem is in these scripts, there are strings that needs to be
> translated as well. How can I make PHP parse these scripts as well?
> Or are
> there alternative approaches?
>
> --
> View this message in context: http://old.nabble.com/Multilingual-website%2C-texts-in-external-JavaScript-problem-tp26261666p26261666.html
> Sent from the PHP - General mailing list archive at Nabble.com.
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>

I use a standard error code ( error.2510 ) treating it as the js array
key, and then call the correct language file with translated value

Bastien

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Convert deprecated POSIX functions into wrappers for equivalent PCRE functions

2009-11-09T04:11:09Z

Tony Marston wrote:
> How many hosting companies write to all their account holders to ask
> permission before upgrading PHP, not just from 4 to 5, but all the releases
> in between? Very few of them, if any, in my experience.
>
I've no idea what horrible hosting companies you've had experiences
with, however all of the companies I've used in the last few years have
had an option to move back and forth between PHP4 and PHP5 in the event
that certain scrips/frameworks/apps/whatever required one version over
the other. What makes you think these companies won't do the same thing
when they finally decide to add PHP6 to their servers? I doubt very
many reputable hosting companies would simply upgrade to the latest
flavor of PHP/Apache/MySQL/anything simply because it was released this
morning without doing ample internal testing; if you or your clients are
using one that does this - I'd advise you look elsewhere.

Whenever PHP6 reaches a stable release build, it will still be quite
some time before its offered as an option to any mainstream shared
hosting service - this should leave you ample time to adapt to incoming
changes. Failing that, you always have the option of purchasing your
own server or VPS from any number of hosts to configure as you see fit.
Or you can explain your moral outrage to potential clients detailing
your refusal to work because you disagree with a proposed change that
won't see the light of day for years to come; your call.

Incessant whining under the guise of expressing your own opinion isn't
going to make everything better. Sorry.

Re: Hash function

2009-11-09T04:05:54Z

Ok, thanks
but how can i create serial number that nobody can guess it. for example
when i use sha1() every body can examine it too! and so they can create it
themselves!
what strategy is useful to protect license?
I think it is better to add a specific hidden string to request code,
instead of user name that is known for a probable jobber user.
what do you think about it?

On Mon, Nov 9, 2009 at 3:09 PM, John Black <spam@...>wrote:

> Ali Asghar Toraby Parizy wrote:
>
>> hi friends
>> I need a hash function to build a Unique serial number by mixing a request
>> code and a user name
>> request codes are strings like this: They are literally HEX codes of MAC
>> mac
>> addresses.
>>
>> "002314EFD000544AB05345300045675609782123C3254B312123D12312EE13123F123D123123E00000000E00000000E0000000E0000000E0000000E00000000E00000000"
>> i want to create a function that mix together this request code with user
>> name that user entered and create new serial number.
>> What implications i have to satisfy to create such hash function in php?
>> Thanks for any suggestion
>>
>
> How about using sha1 to hash your string. If the data is unique then the
> hash will be unique as well.
>
> $string = $request_code.$user_name;
> $hash = sha1($string);
>
> --
> John
> Jeder hat soviel Recht, wie er Macht hat.
> [Spinoza]
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: Hash function

2009-11-09T04:05:54Z

On Mon, 2009-11-09 at 15:35 +0330, Ali Asghar Toraby Parizy wrote:

> Ok, thanks
> but how can i create serial number that nobody can guess it. for example
> when i use sha1() every body can examine it too! and so they can create it
> themselves!
> what strategy is useful to protect license?
> I think it is better to add a specific hidden string to request code,
> instead of user name that is known for a probable jobber user.
> what do you think about it?
>
> On Mon, Nov 9, 2009 at 3:09 PM, John Black <spam@...>wrote:
>
> > Ali Asghar Toraby Parizy wrote:
> >
> >> hi friends
> >> I need a hash function to build a Unique serial number by mixing a request
> >> code and a user name
> >> request codes are strings like this: They are literally HEX codes of MAC
> >> mac
> >> addresses.
> >>
> >> "002314EFD000544AB05345300045675609782123C3254B312123D12312EE13123F123D123123E00000000E00000000E0000000E0000000E0000000E00000000E00000000"
> >> i want to create a function that mix together this request code with user
> >> name that user entered and create new serial number.
> >> What implications i have to satisfy to create such hash function in php?
> >> Thanks for any suggestion
> >>
> >
> > How about using sha1 to hash your string. If the data is unique then the
> > hash will be unique as well.
> >
> > $string = $request_code.$user_name;
> > $hash = sha1($string);
> >
> > --
> > John
> > Jeder hat soviel Recht, wie er Macht hat.
> > [Spinoza]
> >
> >
> > --
> > PHP General Mailing List (http://www.php.net/)
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >

The crypt() function in PHP offers a one-way encryption, so
theoretically, it would be too difficult to work out backwards (not
impossible, but would need a fair bit of computing power to figure it
out!)

Thanks,
Ash
http://www.ashleysheridan.co.uk

Re: Multilingual website, texts in external JavaScript problem

2009-11-09T03:54:51Z

leledumbo wrote:
> I need to create a multilingual website and my framework already gives me
> that facility. However, I also use JavaScript quite extensively and since
> XHTML 1.0 Strict doesn't allow inline script, I must use external .js file.
> The problem is in these scripts, there are strings that needs to be
> translated as well. How can I make PHP parse these scripts as well? Or are
> there alternative approaches?
>

I don't see why you can't use inline script in XHTML 1.0 Strict: just put the
script in CDATA sections, like

<script type="text/javascript">
/*<![CDATA[*/

// Inline javascript here

/*]]>*/
</script>

That seems to validate fine in XHTML 1.0 Strict for me...

--
Peter Ford phone: 01580 893333
Developer fax: 01580 893399
Justcroft International Ltd., Staplehurst, Kent

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Hash function

2009-11-09T03:44:53Z

On Mon, 2009-11-09 at 12:39 +0100, John Black wrote:

> Ali Asghar Toraby Parizy wrote:
> > hi friends
> > I need a hash function to build a Unique serial number by mixing a request
> > code and a user name
> > request codes are strings like this: They are literally HEX codes of MAC mac
> > addresses.
> > "002314EFD000544AB05345300045675609782123C3254B312123D12312EE13123F123D123123E00000000E00000000E0000000E0000000E0000000E00000000E00000000"
> > i want to create a function that mix together this request code with user
> > name that user entered and create new serial number.
> > What implications i have to satisfy to create such hash function in php?
> > Thanks for any suggestion
>
> How about using sha1 to hash your string. If the data is unique then the
> hash will be unique as well.
>
> $string = $request_code.$user_name;
> $hash = sha1($string);
>
> --
> John
> Jeder hat soviel Recht, wie er Macht hat.
> [Spinoza]
>
>

I'm not sure you can guarantee uniqueness, but you can say with a high
degree of certainty that it's extremely unlikely to not be unique!

Thanks,
Ash
http://www.ashleysheridan.co.uk

Re: Paypal transaction

2009-11-09T03:41:50Z

Ali Asghar Toraby Parizy wrote:
> Hi friends
> I have an application I want to sell it in my website
> How can i use PayPal to marketing? i understand php so i am eager to write
> some php code, myself.
> How can i implement a php code to use PayPal gateway
> Thanks for any help

Create a PayPal developer account here https://developer.paypal.com/
They will provide you with sample code and access to the sandbox so you
can test your payment scripts without risking real money.

--
John
No Victim, No Crime

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Hash function

2009-11-09T03:39:37Z

Ali Asghar Toraby Parizy wrote:

> hi friends
> I need a hash function to build a Unique serial number by mixing a request
> code and a user name
> request codes are strings like this: They are literally HEX codes of MAC mac
> addresses.
> "002314EFD000544AB05345300045675609782123C3254B312123D12312EE13123F123D123123E00000000E00000000E0000000E0000000E0000000E00000000E00000000"
> i want to create a function that mix together this request code with user
> name that user entered and create new serial number.
> What implications i have to satisfy to create such hash function in php?
> Thanks for any suggestion

How about using sha1 to hash your string. If the data is unique then the
hash will be unique as well.

$string = $request_code.$user_name;
$hash = sha1($string);

--
John
Jeder hat soviel Recht, wie er Macht hat.
[Spinoza]

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Convert deprecated POSIX functions into wrappers for equivalent PCRE functions

2009-11-09T03:31:29Z

2009/11/9 Tony Marston <tony@...>:

> So you wouldn't trust the PHP developers to write simple code which takes
> each POSIX function and redirects it to a PCRE function? I have more faith
> in their ability than I do yours.

If it's as simple as you claim, why don't you mock-up your solution in
PHP, rather than C? You'll get taken more seriously if you have
working code that someone can write unit tests against.

If your solution doesn't get any traction with the core team, you'll
still be able to offer it to the community as a simple download, just
"include this at the top of your script to fix "ereg*() not found"
problems". That would be really useful to all those people whose cause
you are championing.

(BTW, the reference implementation for PHP is... PHP. There isn't an
ISO standard or anything here. How PHP6 behaves is correct, because
it's PHP6).

(BTW^2 - you're on the wrong list for this. If you want to influence
the guys who make the decisions you need to take this to
php-internals, where the heavyweights hang out).

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Convert deprecated POSIX functions into wrappers for equivalent PCRE functions

2009-11-09T03:25:17Z

"Ashley Sheridan" <ash@...> wrote in message
news:1257764339.1076.56.camel@localhost...
> On Mon, 2009-11-09 at 00:23 +0000, Tony Marston wrote:
>
>> developer laziness
>> or incompetence is not an acceptable excuse.
>
>
> Exactly, so fix your scripts!

But my scripts aren't broken! It's PHP 6 that is broken.

> I do wonder though, what hosting company you use that would just upgrade
> to PHP6 without warning on you and 'break' your scripts,

How many hosting companies write to all their account holders to ask
permission before upgrading PHP, not just from 4 to 5, but all the releases
in between? Very few of them, if any, in my experience.

> yet at the same
> time would not allow you to install what you call an 'amateur fudge'. I
> can't think of any hosting company that would care so little about their
> customers.

Some hosting companies won't allow you to use htaccess files, refuse to
install any optional extension, let alone one from the PECL or PEAR
repositories. Some of them won't give you more than one MySQL database.
Different companies provide different levels of service. The only thing that
the DO have in common is that they charge you for it.

--
Tony Marston
http://www.tonymarston.net
http://www.radicore.org

> Thanks,
> Ash
> http://www.ashleysheridan.co.uk
>
>
>

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Paypal transaction

2009-11-09T03:22:42Z

Hi friends
I have an application I want to sell it in my website
How can i use PayPal to marketing? i understand php so i am eager to write
some php code, myself.
How can i implement a php code to use PayPal gateway
Thanks for any help

Hash function

2009-11-09T03:08:12Z

hi friends
I need a hash function to build a Unique serial number by mixing a request
code and a user name
request codes are strings like this: They are literally HEX codes of MAC mac
addresses.
"002314EFD000544AB05345300045675609782123C3254B312123D12312EE13123F123D123123E00000000E00000000E0000000E0000000E0000000E00000000E00000000"
i want to create a function that mix together this request code with user
name that user entered and create new serial number.
What implications i have to satisfy to create such hash function in php?
Thanks for any suggestion

Re: Convert deprecated POSIX functions into wrappers for equivalent PCRE functions

2009-11-09T02:58:59Z

On Mon, 2009-11-09 at 00:23 +0000, Tony Marston wrote:

> developer laziness
> or incompetence is not an acceptable excuse.

Exactly, so fix your scripts!

I do wonder though, what hosting company you use that would just upgrade
to PHP6 without warning on you and 'break' your scripts, yet at the same
time would not allow you to install what you call an 'amateur fudge'. I
can't think of any hosting company that would care so little about their
customers.

Thanks,
Ash
http://www.ashleysheridan.co.uk

Re: Multilingual website, texts in external JavaScript problem

2009-11-09T02:52:40Z

On Sun, 2009-11-08 at 22:04 -0800, leledumbo wrote:

> I need to create a multilingual website and my framework already gives me
> that facility. However, I also use JavaScript quite extensively and since
> XHTML 1.0 Strict doesn't allow inline script, I must use external .js file.
> The problem is in these scripts, there are strings that needs to be
> translated as well. How can I make PHP parse these scripts as well? Or are
> there alternative approaches?
>
> --
> View this message in context: http://old.nabble.com/Multilingual-website%2C-texts-in-external-JavaScript-problem-tp26261666p26261666.html
> Sent from the PHP - General mailing list archive at Nabble.com.
>
>

You could either use several different Javascript files to hold the
language translations and just those as variables, and then in the main
Javascript use the variables rather than the actual words. Or you could
store all the translations into a Javascript array and refer to the
specific array element you need to output

Thanks,
Ash
http://www.ashleysheridan.co.uk

Re: Convert deprecated POSIX functions into wrappers for equivalent PCRE functions

2009-11-09T02:48:50Z

"Robert Cummings" <robert@...> wrote in message
news:4AF76E1F.2050700@......

> Tony Marston wrote:
>> "Robert Cummings" <robert@...> wrote in message
>>>>> Then you've got several options:
>>>>> 1) Don't upgrade PHP.
>>>> Not an acceptable option.
>>>>
>>>>> 2) Pick a different hosting provider.
>>>> Not an acceptable optional.
>>>>
>>>>> 3) Fix your scripts.
>>>> The scripts aren't broken. It's PHP 6 that's going to be broken.
>>> I think you're missing the point of a full version increase. This is not
>>> a minor or micro version change... script breakage is *expected*.
>>
>> But breakage should be kept to an absolute minimum, and developer
>> laziness or incompetence is not an acceptable excuse.
>
> Not quite true... major version moves are an opportunity to make a break
> for freedom. All there needs to be is an upgrade path... and that is
> clearly in play right now with the warning indicating that POSIX regex
> functions are being deprecated.

But a lot of people won't see those warnings until they run 5.3.0 for the
first time. It is common practice, at least in all the other languages that
I have used, that is something is going to be removed that it is marked as
deprecated at the start of the previous release, not at the end. So marking
the POIX functions as deprecated should have happened in 5.0, not 5.3.

>>> You don't think PHP should support legacy cruft in the core forever do
>>> you?
>>
>> Widely use regex functions are not "legacy cruft". Besides, who decides
>> what is "cruft" and should be removed from the language?
>
> They most certainly are cruft.

That is just your opinion. Other people think that PHP should be rewritten
so that it appears more like their favourite language. Among the suggestions
I have seen are:
- make all variables statically typed instead of dynamically typed.
- remove all procedural functions and make the language "pure" OO.

Who decides if they are right?

>.. hence the reason they are being removed. The people who decide what is,
>and is not, cruft are the very same people who are writing the code. If you
>are not happy with this then there's the age old saying in open source...
>"put up or shut up".

I can't because I don't program in C. So I shall do the nextbest thing -
complain at every opporunity.

>>> If unicode support is slopped onto the current POSIX regex functions
>>> won't that then make them non-POSIX? Food for thought. Also, why support
>>> two libraries for which one is obviously inferior in speed and
>>> functionality?
>>
>> That is why I suggested that instead of dropping the POSIX functions
>> entirely and seriously annoying lots of users, that they should simply be
>> rewritten as wrappers for the PCRE functions. In that way all the calls
>> to ereg_* would still work, but all they would do is immediately call the
>> relevant preg_* function. The small amount of effort that tghis would
>> take would kill two birds with one stone:
>>
>> (1) There would be only one regex engine to support, which would be PCRE.
>> (2) Lots of developers would be spared the hassle of modifying their code
>> as all the calls to POSIX functions would still work as expected because
>> the language would redirect to the PCRE function automatically.
>
> This would probably be worse than removing the POSIX functions.
> POSIX and PCRE I daresay are not completely compatible.

"probably" and "daresay" mean that you are just guessing. According to some
people who know what they are talking about there is a one-for-one
comparison between each POSIX and each PCRE function.

> At least when you remove the POSIX functions then the problem space is
> well defined.

And lots of sers will be pissed off because they won'tbe able to upgrade to
PHP 6 without major programmer intervention.

> Suddenly having POSIX regex functions that are really wrappers around PCRE
> functions may introduce subtle differences in output for the same horde of
> users but without the same explicability.

"may introduce"? There you go, guessng again. Can you point out *any* POSIX
function that cannot be converted into PCRE?

>> I am not suggesting that the POSIX functions be rewritten to deal with
>> unicode as that would require a huge amount of effort, but by redirecting
>> al POSIX calls to the equivalent PCRE function would have the same effect
>> for far less effort.
>>
>> The choice is simple - either a small amount of effort from a small
>> number of developers, or a large amount of effort from a large number of
>> seriously pissed-off users. Do the maths. It's not rocket science.
>
> This isn't a mathematical problem. It's a question of correctness.

Lot's of PHP users, myself included, do not think that it is "correct" to
remove widely used functionality just beause the developers are too lazy to
do a proper job.

> I wasn't happy to hear POSIX regex functions were going either, but when I
> heard the reasoning I did the best thing I could... I fixed my code to
> prepare for the inevitable.

So you had to fix what wasn't broken just to circumvent a stupid decision by
the PHP developers.

> There's no way I'd trust my code to "just work" with POSIX functions
> redirected through PCRE and so I'd still need to do the same legwork.

So you wouldn't trust the PHP developers to write simple code which takes
each POSIX function and redirects it to a PCRE function? I have more faith
in their ability than I do yours.

> Wrapping the POSIX regex functions around PCRE will lead to more problems
> than it solves IMHO.

IMHO your opinion does not carry much weight.

--
Tony Marston
http://www.tonymarston.net
http://www.radicore.org

> 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

Re: Convert deprecated POSIX functions into wrappers forequivalent PCRE functions

2009-11-09T02:29:26Z

"Paul M Foster" <paulf@...> wrote in message
news:20091109030235.GH3738@......
> On Sun, Nov 08, 2009 at 06:30:37PM -0500, Robert Cummings wrote:
>
>> Also, why support
>> two libraries for which one is obviously inferior in speed and
>> functionality?
>>
>
> Because Tony's Radicore framework has a bunch of ereg* calls in it. ;-}

Just like a lot of other people's work.

--
Tony Marston
http://www.tonymarston.net
http://www.radicore.org

> Paul
>
> --
> Paul M. Foster

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Connect to LDAP

2009-11-08T23:19:16Z

Yes. Correct

On Mon, Nov 9, 2009 at 7:30 AM, Ashley M. Kirchner <ashley@...>wrote:

>
> Hi folks,
>
> I've never done any PHP->LDAP code writing (nor have I ever dealt with an
> LDAP server to begin with.) However I'm writing an app which requires
> verifying a user's credentials against an LDAP server. The admin of the
> server sent me the following snippet, however also made it clear that he is
> not 100% whether it's accurate (he's not a PHP coder). And I don't have
> remote access to the server (the app is going to sit on the internal network
> and the LDAP server doesn't accept outside connections.)
>
> So, asking the wise folks on here, does the following piece look
> semantically correct?
>
> /* Check against LDAP server */
> $adServer = "server.address.hidden";
> $ldapconn = ldap_connect($adServer) or die("Connection to the AD
> server failed.");
> $ldapuser = $_POST["uname"];
> $ldappass = $_POST["pword"];
> $ldapbind = ldap_bind($ldapconn, $ldapuser, $ldappass);
>
> if ($ldapbind) {
> $msg = "User Authenticated Successfully!";
> $_SESSION['username'] = $ldapuser;
> $_SESSION['password'] = $ldappass;
> return true;
> } else {
> $msg = "Invalid username / password";
> return false;
> }
>
> Thanks.
>
> -- A
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--
Devendra Jadhav
देवेंद्र जाधव

Multilingual website, texts in external JavaScript problem

2009-11-08T22:04:06Z

I need to create a multilingual website and my framework already gives me that facility. However, I also use JavaScript quite extensively and since XHTML 1.0 Strict doesn't allow inline script, I must use external .js file. The problem is in these scripts, there are strings that needs to be translated as well. How can I make PHP parse these scripts as well? Or are there alternative approaches?

Re: Re: Checkbox in PHP form

2009-11-08T21:52:08Z

<input class=text id="myCheck1" type="checkbox" <?php if ( $row[33] ==
'no') { echo "checked="checked"; } ?> value="PFDs"
name=f_sequipment1></b><font size="2">PFDs<b>

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Convert deprecated POSIX functions into wrappers for equivalent PCRE functions

2009-11-08T19:02:35Z

On Sun, Nov 08, 2009 at 06:30:37PM -0500, Robert Cummings wrote:

> Also, why support
> two libraries for which one is obviously inferior in speed and
> functionality?
>

Because Tony's Radicore framework has a bunch of ereg* calls in it. ;-}

Paul

--
Paul M. Foster

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Connect to LDAP

2009-11-08T18:00:09Z

Hi folks,

I've never done any PHP->LDAP code writing (nor have I ever dealt
with an LDAP server to begin with.) However I'm writing an app which
requires verifying a user's credentials against an LDAP server. The
admin of the server sent me the following snippet, however also made it
clear that he is not 100% whether it's accurate (he's not a PHP coder).
And I don't have remote access to the server (the app is going to sit on
the internal network and the LDAP server doesn't accept outside
connections.)

So, asking the wise folks on here, does the following piece look
semantically correct?

/* Check against LDAP server */
$adServer = "server.address.hidden";
$ldapconn = ldap_connect($adServer) or die("Connection to the
AD server failed.");
$ldapuser = $_POST["uname"];
$ldappass = $_POST["pword"];
$ldapbind = ldap_bind($ldapconn, $ldapuser, $ldappass);

if ($ldapbind) {
$msg = "User Authenticated Successfully!";
$_SESSION['username'] = $ldapuser;
$_SESSION['password'] = $ldappass;
return true;
} else {
$msg = "Invalid username / password";
return false;
}

Thanks.

-- A

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Checkbox in PHP form

2009-11-08T17:45:00Z

Hello,

on 11/08/2009 11:39 PM Ernie Kemp said the following:

> Need some help here with checkboxes in an html form.
>
>
>
> My issue is I have a form that needs to be viewed with checkboxes filled
> in depending on the values in the table.
>
>
>
> I tried:
>
> <INPUT class=text id="myCheck1" type=checkbox <?php if ( $row[33] =
> 'no') { echo "checked=yes"; } else { echo ''; } ?> value="PFDs"
> name=f_sequipment1></b><font size="2">PFDs<b>
>
> but the checkbox field is always checked.

It should be $row[33] == 'no'

--

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

Checkbox in PHP form

2009-11-08T17:39:40Z

Need some help here with checkboxes in an html form.

My issue is I have a form that needs to be viewed with checkboxes filled in depending on the values in the table.

I tried:

<INPUT class=text id="myCheck1" type=checkbox <?php if ( $row[33] = 'no') { echo "checked=yes"; } else { echo ''; } ?> value="PFDs" name=f_sequipment1></b><font size="2">PFDs<b>

but the checkbox field is always checked.

I thought of JavaScript also but it would have to be a “if $row[33] then run a JavaScript function” . This is not working for me neither.

Sorry if this seems trivial but I need your help.

Thanks in advance.....

Re: Convert deprecated POSIX functions into wrappers for equivalent PCRE functions

2009-11-08T17:19:27Z

Tony Marston wrote:

> "Robert Cummings" <robert@...> wrote in message
>>>> Then you've got several options:
>>>> 1) Don't upgrade PHP.
>>> Not an acceptable option.
>>>
>>>> 2) Pick a different hosting provider.
>>> Not an acceptable optional.
>>>
>>>> 3) Fix your scripts.
>>> The scripts aren't broken. It's PHP 6 that's going to be broken.
>> I think you're missing the point of a full version increase. This is not a
>> minor or micro version change... script breakage is *expected*.
>
> But breakage should be kept to an absolute minimum, and developer laziness
> or incompetence is not an acceptable excuse.

Not quite true... major version moves are an opportunity to make a break
for freedom. All there needs to be is an upgrade path... and that is
clearly in play right now with the warning indicating that POSIX regex
functions are being deprecated.

>> You don't think PHP should support legacy cruft in the core forever do
>> you?
>
> Widely use regex functions are not "legacy cruft". Besides, who decides what
> is "cruft" and should be removed from the language?

They most certainly are cruft... hence the reason they are being
removed. The people who decide what is, and is not, cruft are the very
same people who are writing the code. If you are not happy with this
then there's the age old saying in open source... "put up or shut up".

>> If unicode support is slopped onto the current POSIX regex functions won't
>> that then make them non-POSIX? Food for thought. Also, why support two
>> libraries for which one is obviously inferior in speed and functionality?
>
> That is why I suggested that instead of dropping the POSIX functions
> entirely and seriously annoying lots of users, that they should simply be
> rewritten as wrappers for the PCRE functions. In that way all the calls to
> ereg_* would still work, but all they would do is immediately call the
> relevant preg_* function. The small amount of effort that tghis would take
> would kill two birds with one stone:
>
> (1) There would be only one regex engine to support, which would be PCRE.
> (2) Lots of developers would be spared the hassle of modifying their code as
> all the calls to POSIX functions would still work as expected because the
> language would redirect to the PCRE function automatically.

This would probably be worse than removing the POSIX functions. POSIX
and PCRE I daresay are not completely compatible. At least when you
remove the POSIX functions then the problem space is well defined.
Suddenly having POSIX regex functions that are really wrappers around
PCRE functions may introduce subtle differences in output for the same
horde of users but without the same explicability.

> I am not suggesting that the POSIX functions be rewritten to deal with
> unicode as that would require a huge amount of effort, but by redirecting al
> POSIX calls to the equivalent PCRE function would have the same effect for
> far less effort.
>
> The choice is simple - either a small amount of effort from a small number
> of developers, or a large amount of effort from a large number of seriously
> pissed-off users. Do the maths. It's not rocket science.

This isn't a mathematical problem. It's a question of correctness. I
wasn't happy to hear POSIX regex functions were going either, but when I
heard the reasoning I did the best thing I could... I fixed my code to
prepare for the inevitable. There's no way I'd trust my code to "just
work" with POSIX functions redirected through PCRE and so I'd still need
to do the same legwork.

Wrapping the POSIX regex functions around PCRE will lead to more
problems than it solves IMHO.

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

Re: Convert deprecated POSIX functions into wrappers for equivalent PCRE functions

2009-11-08T16:23:22Z

"Robert Cummings" <robert@...> wrote in message
news:4AF7549D.1060005@......

> Tony Marston wrote:
>> "Eddie Drapkin" <oorza2k5@...> wrote in message
>> news:68de37340911081330v799803f3he6ed60ecc6e67bdb@......
>> On Sun, Nov 8, 2009 at 4:13 PM, Tony Marston
>> <tony@...> wrote:
>>> That's an amateur fudge, not a professional fix. Besides, what happens
>>> if
>>> your hosting company won't let you install PECL extensions?
>>>
>>> --
>>> Tony Marston
>>> http://www.tonymarston.net
>>> http://www.radicore.org
>>>
>>> "Eddie Drapkin" <oorza2k5@...> wrote in message
>>> news:68de37340911081209p45577d46r70a3c194f1079510@......
>>>> On Sun, Nov 8, 2009 at 2:47 PM, Tony Marston
>>>> <tony@...> wrote:
>>>>> "It is for the better"? How can you justify that? It is a problem that
>>>>> will
>>>>> cause a lot of headaches for a lot of users, yet the solution which I
>>>>> have
>>>>> proposed will remove that problem with only very little effort, yet
>>>>> still
>>>>> leave only one regex engine which has to be supported in PHP 6.
>>>>>
>>>>> You have to balance out the small bit of effort required in
>>>>> implementing
>>>>> this solution against the huge amount of effort required in changing
>>>>> thousands, if not millions of scripts.
>>>>>
>>>>> For the PHP developers to say "we can't be bothered to update the
>>>>> POSIX
>>>>> functions to deal with unicode, so we've decided to drop them from PHP
>>>>> entirely even though it will break lots of scripts" will not go down
>>>>> well
>>>>> in
>>>>> userland.
>>>>>
>>>>>
>>>>> --
>>>>> Tony Marston
>>>>> http://www.tonymarston.net
>>>>> http://www.radicore.org
>>>>>
>>>>> "John Black" <spam@...> wrote in message
>>>>> news:4AF70120.1040209@......
>>>>>> The same can be said about the removal of magic_quotes(), it will
>>>>>> break
>>>>>> A
>>>>>> LOT of old scripts.
>>>>>> I am in the same boat, I did not keep up to date with the PHP
>>>>>> developer
>>>>>> plans and just found out about ereg when I installed PHP 5.3.
>>>>>>
>>>>>> I think it was handled properly by displaying warning messages before
>>>>>> actually removing it. It will give people enough time to update their
>>>>>> scripts or weed out the old and insecure scripts.
>>>>>>
>>>>>> Yes, it will create some headache but, AFAIK, it is for the better.
>>>>>>
>>>>>> --
>>>>>> John
>>>>>> Intelligent Life
>>>>>> http://xkcd.com/638/
>>>>>
>>>>>
>>>>> --
>>>>> PHP General Mailing List (http://www.php.net/)
>>>>> To unsubscribe, visit: http://www.php.net/unsub.php
>>>>>
>>>>>
>>>> The plan, as far as I am aware, is to move POSIX regular expressions
>>>> into PECL as of PHP6. If you can fix your scripts by simply running
>>>> "pecl install ereg" what's all the hee-hawing about?
>>>
>>>
>>> --
>>> PHP General Mailing List (http://www.php.net/)
>>> To unsubscribe, visit: http://www.php.net/unsub.php
>>>
>>>
>>
>>> Then you've got several options:
>>> 1) Don't upgrade PHP.
>>
>> Not an acceptable option.
>>
>>> 2) Pick a different hosting provider.
>>
>> Not an acceptable optional.
>>
>>> 3) Fix your scripts.
>>
>> The scripts aren't broken. It's PHP 6 that's going to be broken.
>
> I think you're missing the point of a full version increase. This is not a
> minor or micro version change... script breakage is *expected*.

But breakage should be kept to an absolute minimum, and developer laziness
or incompetence is not an acceptable excuse.

> You don't think PHP should support legacy cruft in the core forever do
> you?

Widely use regex functions are not "legacy cruft". Besides, who decides what
is "cruft" and should be removed from the language?

> If unicode support is slopped onto the current POSIX regex functions won't
> that then make them non-POSIX? Food for thought. Also, why support two
> libraries for which one is obviously inferior in speed and functionality?

That is why I suggested that instead of dropping the POSIX functions
entirely and seriously annoying lots of users, that they should simply be
rewritten as wrappers for the PCRE functions. In that way all the calls to
ereg_* would still work, but all they would do is immediately call the
relevant preg_* function. The small amount of effort that tghis would take
would kill two birds with one stone:

(1) There would be only one regex engine to support, which would be PCRE.
(2) Lots of developers would be spared the hassle of modifying their code as
all the calls to POSIX functions would still work as expected because the
language would redirect to the PCRE function automatically.

I am not suggesting that the POSIX functions be rewritten to deal with
unicode as that would require a huge amount of effort, but by redirecting al
POSIX calls to the equivalent PCRE function would have the same effect for
far less effort.

The choice is simple - either a small amount of effort from a small number
of developers, or a large amount of effort from a large number of seriously
pissed-off users. Do the maths. It's not rocket science.

--
Tony Marston
http://www.tonymarston.net
http://www.radicore.org

> 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

Re: Convert deprecated POSIX functions into wrappers for equivalent PCRE functions

2009-11-08T15:30:37Z

Tony Marston wrote:

> "Eddie Drapkin" <oorza2k5@...> wrote in message
> news:68de37340911081330v799803f3he6ed60ecc6e67bdb@......
> On Sun, Nov 8, 2009 at 4:13 PM, Tony Marston
> <tony@...> wrote:
>> That's an amateur fudge, not a professional fix. Besides, what happens if
>> your hosting company won't let you install PECL extensions?
>>
>> --
>> Tony Marston
>> http://www.tonymarston.net
>> http://www.radicore.org
>>
>> "Eddie Drapkin" <oorza2k5@...> wrote in message
>> news:68de37340911081209p45577d46r70a3c194f1079510@......
>>> On Sun, Nov 8, 2009 at 2:47 PM, Tony Marston
>>> <tony@...> wrote:
>>>> "It is for the better"? How can you justify that? It is a problem that
>>>> will
>>>> cause a lot of headaches for a lot of users, yet the solution which I
>>>> have
>>>> proposed will remove that problem with only very little effort, yet
>>>> still
>>>> leave only one regex engine which has to be supported in PHP 6.
>>>>
>>>> You have to balance out the small bit of effort required in implementing
>>>> this solution against the huge amount of effort required in changing
>>>> thousands, if not millions of scripts.
>>>>
>>>> For the PHP developers to say "we can't be bothered to update the POSIX
>>>> functions to deal with unicode, so we've decided to drop them from PHP
>>>> entirely even though it will break lots of scripts" will not go down
>>>> well
>>>> in
>>>> userland.
>>>>
>>>>
>>>> --
>>>> Tony Marston
>>>> http://www.tonymarston.net
>>>> http://www.radicore.org
>>>>
>>>> "John Black" <spam@...> wrote in message
>>>> news:4AF70120.1040209@......
>>>>> The same can be said about the removal of magic_quotes(), it will break
>>>>> A
>>>>> LOT of old scripts.
>>>>> I am in the same boat, I did not keep up to date with the PHP developer
>>>>> plans and just found out about ereg when I installed PHP 5.3.
>>>>>
>>>>> I think it was handled properly by displaying warning messages before
>>>>> actually removing it. It will give people enough time to update their
>>>>> scripts or weed out the old and insecure scripts.
>>>>>
>>>>> Yes, it will create some headache but, AFAIK, it is for the better.
>>>>>
>>>>> --
>>>>> John
>>>>> Intelligent Life
>>>>> http://xkcd.com/638/
>>>>
>>>>
>>>> --
>>>> PHP General Mailing List (http://www.php.net/)
>>>> To unsubscribe, visit: http://www.php.net/unsub.php
>>>>
>>>>
>>> The plan, as far as I am aware, is to move POSIX regular expressions
>>> into PECL as of PHP6. If you can fix your scripts by simply running
>>> "pecl install ereg" what's all the hee-hawing about?
>>
>>
>> --
>> PHP General Mailing List (http://www.php.net/)
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
>
>> Then you've got several options:
>> 1) Don't upgrade PHP.
>
> Not an acceptable option.
>
>> 2) Pick a different hosting provider.
>
> Not an acceptable optional.
>
>> 3) Fix your scripts.
>
> The scripts aren't broken. It's PHP 6 that's going to be broken.

I think you're missing the point of a full version increase. This is not
a minor or micro version change... script breakage is *expected*. You
don't think PHP should support legacy cruft in the core forever do you?
If unicode support is slopped onto the current POSIX regex functions
won't that then make them non-POSIX? Food for thought. Also, why support
two libraries for which one is obviously inferior in speed and
functionality?

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

Re: Convert deprecated POSIX functions into wrappers for equivalent PCRE functions

2009-11-08T14:47:50Z

"Eddie Drapkin" <oorza2k5@...> wrote in message
news:68de37340911081330v799803f3he6ed60ecc6e67bdb@......
On Sun, Nov 8, 2009 at 4:13 PM, Tony Marston
<tony@...> wrote:

> That's an amateur fudge, not a professional fix. Besides, what happens if
> your hosting company won't let you install PECL extensions?
>
> --
> Tony Marston
> http://www.tonymarston.net
> http://www.radicore.org
>
> "Eddie Drapkin" <oorza2k5@...> wrote in message
> news:68de37340911081209p45577d46r70a3c194f1079510@......
>> On Sun, Nov 8, 2009 at 2:47 PM, Tony Marston
>> <tony@...> wrote:
>>> "It is for the better"? How can you justify that? It is a problem that
>>> will
>>> cause a lot of headaches for a lot of users, yet the solution which I
>>> have
>>> proposed will remove that problem with only very little effort, yet
>>> still
>>> leave only one regex engine which has to be supported in PHP 6.
>>>
>>> You have to balance out the small bit of effort required in implementing
>>> this solution against the huge amount of effort required in changing
>>> thousands, if not millions of scripts.
>>>
>>> For the PHP developers to say "we can't be bothered to update the POSIX
>>> functions to deal with unicode, so we've decided to drop them from PHP
>>> entirely even though it will break lots of scripts" will not go down
>>> well
>>> in
>>> userland.
>>>
>>>
>>> --
>>> Tony Marston
>>> http://www.tonymarston.net
>>> http://www.radicore.org
>>>
>>> "John Black" <spam@...> wrote in message
>>> news:4AF70120.1040209@......
>>>> The same can be said about the removal of magic_quotes(), it will break
>>>> A
>>>> LOT of old scripts.
>>>> I am in the same boat, I did not keep up to date with the PHP developer
>>>> plans and just found out about ereg when I installed PHP 5.3.
>>>>
>>>> I think it was handled properly by displaying warning messages before
>>>> actually removing it. It will give people enough time to update their
>>>> scripts or weed out the old and insecure scripts.
>>>>
>>>> Yes, it will create some headache but, AFAIK, it is for the better.
>>>>
>>>> --
>>>> John
>>>> Intelligent Life
>>>> http://xkcd.com/638/
>>>
>>>
>>>
>>> --
>>> PHP General Mailing List (http://www.php.net/)
>>> To unsubscribe, visit: http://www.php.net/unsub.php
>>>
>>>
>>
>> The plan, as far as I am aware, is to move POSIX regular expressions
>> into PECL as of PHP6. If you can fix your scripts by simply running
>> "pecl install ereg" what's all the hee-hawing about?
>
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

> Then you've got several options:
> 1) Don't upgrade PHP.

Not an acceptable option.

> 2) Pick a different hosting provider.

Not an acceptable optional.

> 3) Fix your scripts.

The scripts aren't broken. It's PHP 6 that's going to be broken.

> You talk about a "professional" fix. The right fix is to remove the
> depracated elements

My whole argument is that they shouldn't have been deprecated in the first
place.

> from your scripts before upgrading PHP, which
> realistically shouldn't be that big of a deal for the vast majority of
> expressions.

It is going to be a VERY big deal for all hose users who suddenly finf that
their scripts won't run in PHP 6.

> Rather than accept the change and just fix your scripts,

It's not a change, it's a removal of core functions that have worked
flawlessly for years. Both the POSIX and the PCRE functions needed to be
updated to work with unicode, but the developers couldn't be bothered to
update both. The only reason that the POSIX have been deprecated is because
the PHP developers are either too lazy or too incompetent to provide a
proper fix.

> you propose a problem that breaks a lot of other things and introduces
> way more problems than it solves.

> You're not the first person to post this exact same tantrum on this
l> list and the response has always been: fix your scripts

The scripts aren't broken, it's PHP 6 that's broken.

> or don't upgrade.

Not an acceptable option.

> Seeing as PHP 6 is a long ways away you've got plenty of
> time to fix your scripts

Just as the PHP developers have plenty of time to do a proper job.

> and it's not like this is being sprung overnight,

To a lot of peope it will appear to be sprung overnight as the first time
they will know that the POSIX functions have been removed is when their
scripts don't work.

> so do the real professional thing

The professional thing would be to fix PHP 6 so that is doesn't break
existing scripts needlessly.

> and upgrade your scripts,
> if you want to upgrade (when 6 is released). Breaking BC happens.

There is a difference between breaking BC because of genuinely
insurmountable reasons, and breaking it because of pure laziness.

--
Tony Marston
http://www.tonymarston.net
http://www.radicore.org

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Convert deprecated POSIX functions into wrappers for equivalent PCRE functions

2009-11-08T13:30:31Z

On Sun, Nov 8, 2009 at 4:13 PM, Tony Marston
<tony@...> wrote:

> That's an amateur fudge, not a professional fix. Besides, what happens if
> your hosting company won't let you install PECL extensions?
>
> --
> Tony Marston
> http://www.tonymarston.net
> http://www.radicore.org
>
> "Eddie Drapkin" <oorza2k5@...> wrote in message
> news:68de37340911081209p45577d46r70a3c194f1079510@......
>> On Sun, Nov 8, 2009 at 2:47 PM, Tony Marston
>> <tony@...> wrote:
>>> "It is for the better"? How can you justify that? It is a problem that
>>> will
>>> cause a lot of headaches for a lot of users, yet the solution which I
>>> have
>>> proposed will remove that problem with only very little effort, yet still
>>> leave only one regex engine which has to be supported in PHP 6.
>>>
>>> You have to balance out the small bit of effort required in implementing
>>> this solution against the huge amount of effort required in changing
>>> thousands, if not millions of scripts.
>>>
>>> For the PHP developers to say "we can't be bothered to update the POSIX
>>> functions to deal with unicode, so we've decided to drop them from PHP
>>> entirely even though it will break lots of scripts" will not go down well
>>> in
>>> userland.
>>>
>>>
>>> --
>>> Tony Marston
>>> http://www.tonymarston.net
>>> http://www.radicore.org
>>>
>>> "John Black" <spam@...> wrote in message
>>> news:4AF70120.1040209@......
>>>> The same can be said about the removal of magic_quotes(), it will break
>>>> A
>>>> LOT of old scripts.
>>>> I am in the same boat, I did not keep up to date with the PHP developer
>>>> plans and just found out about ereg when I installed PHP 5.3.
>>>>
>>>> I think it was handled properly by displaying warning messages before
>>>> actually removing it. It will give people enough time to update their
>>>> scripts or weed out the old and insecure scripts.
>>>>
>>>> Yes, it will create some headache but, AFAIK, it is for the better.
>>>>
>>>> --
>>>> John
>>>> Intelligent Life
>>>> http://xkcd.com/638/
>>>
>>>
>>>
>>> --
>>> PHP General Mailing List (http://www.php.net/)
>>> To unsubscribe, visit: http://www.php.net/unsub.php
>>>
>>>
>>
>> The plan, as far as I am aware, is to move POSIX regular expressions
>> into PECL as of PHP6. If you can fix your scripts by simply running
>> "pecl install ereg" what's all the hee-hawing about?
>
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Then you've got several options:
1) Don't upgrade PHP.
2) Pick a different hosting provider.
3) Fix your scripts.

You talk about a "professional" fix. The right fix is to remove the
depracated elements from your scripts before upgrading PHP, which
realistically shouldn't be that big of a deal for the vast majority of
expressions. Rather than accept the change and just fix your scripts,
you propose a problem that breaks a lot of other things and introduces
way more problems than it solves.

You're not the first person to post this exact same tantrum on this
list and the response has always been: fix your scripts or don't
upgrade. Seeing as PHP 6 is a long ways away you've got plenty of
time to fix your scripts and it's not like this is being sprung
overnight, so do the real professional thing and upgrade your scripts,
if you want to upgrade (when 6 is released). Breaking BC happens.

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Convert deprecated POSIX functions into wrappers for equivalent PCRE functions

2009-11-08T13:13:09Z

That's an amateur fudge, not a professional fix. Besides, what happens if
your hosting company won't let you install PECL extensions?

--
Tony Marston
http://www.tonymarston.net
http://www.radicore.org

"Eddie Drapkin" <oorza2k5@...> wrote in message
news:68de37340911081209p45577d46r70a3c194f1079510@......

> On Sun, Nov 8, 2009 at 2:47 PM, Tony Marston
> <tony@...> wrote:
>> "It is for the better"? How can you justify that? It is a problem that
>> will
>> cause a lot of headaches for a lot of users, yet the solution which I
>> have
>> proposed will remove that problem with only very little effort, yet still
>> leave only one regex engine which has to be supported in PHP 6.
>>
>> You have to balance out the small bit of effort required in implementing
>> this solution against the huge amount of effort required in changing
>> thousands, if not millions of scripts.
>>
>> For the PHP developers to say "we can't be bothered to update the POSIX
>> functions to deal with unicode, so we've decided to drop them from PHP
>> entirely even though it will break lots of scripts" will not go down well
>> in
>> userland.
>>
>>
>> --
>> Tony Marston
>> http://www.tonymarston.net
>> http://www.radicore.org
>>
>> "John Black" <spam@...> wrote in message
>> news:4AF70120.1040209@......
>>> The same can be said about the removal of magic_quotes(), it will break
>>> A
>>> LOT of old scripts.
>>> I am in the same boat, I did not keep up to date with the PHP developer
>>> plans and just found out about ereg when I installed PHP 5.3.
>>>
>>> I think it was handled properly by displaying warning messages before
>>> actually removing it. It will give people enough time to update their
>>> scripts or weed out the old and insecure scripts.
>>>
>>> Yes, it will create some headache but, AFAIK, it is for the better.
>>>
>>> --
>>> John
>>> Intelligent Life
>>> http://xkcd.com/638/
>>
>>
>>
>> --
>> PHP General Mailing List (http://www.php.net/)
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
>
> The plan, as far as I am aware, is to move POSIX regular expressions
> into PECL as of PHP6. If you can fix your scripts by simply running
> "pecl install ereg" what's all the hee-hawing about?

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Convert deprecated POSIX functions into wrappers for equivalent PCRE functions

2009-11-08T12:09:36Z

On Sun, Nov 8, 2009 at 2:47 PM, Tony Marston
<tony@...> wrote:

> "It is for the better"? How can you justify that? It is a problem that will
> cause a lot of headaches for a lot of users, yet the solution which I have
> proposed will remove that problem with only very little effort, yet still
> leave only one regex engine which has to be supported in PHP 6.
>
> You have to balance out the small bit of effort required in implementing
> this solution against the huge amount of effort required in changing
> thousands, if not millions of scripts.
>
> For the PHP developers to say "we can't be bothered to update the POSIX
> functions to deal with unicode, so we've decided to drop them from PHP
> entirely even though it will break lots of scripts" will not go down well in
> userland.
>
>
> --
> Tony Marston
> http://www.tonymarston.net
> http://www.radicore.org
>
> "John Black" <spam@...> wrote in message
> news:4AF70120.1040209@......
>> The same can be said about the removal of magic_quotes(), it will break A
>> LOT of old scripts.
>> I am in the same boat, I did not keep up to date with the PHP developer
>> plans and just found out about ereg when I installed PHP 5.3.
>>
>> I think it was handled properly by displaying warning messages before
>> actually removing it. It will give people enough time to update their
>> scripts or weed out the old and insecure scripts.
>>
>> Yes, it will create some headache but, AFAIK, it is for the better.
>>
>> --
>> John
>> Intelligent Life
>> http://xkcd.com/638/
>
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

The plan, as far as I am aware, is to move POSIX regular expressions
into PECL as of PHP6. If you can fix your scripts by simply running
"pecl install ereg" what's all the hee-hawing about?

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Convert deprecated POSIX functions into wrappers for equivalent PCRE functions

2009-11-08T11:47:46Z

"It is for the better"? How can you justify that? It is a problem that will
cause a lot of headaches for a lot of users, yet the solution which I have
proposed will remove that problem with only very little effort, yet still
leave only one regex engine which has to be supported in PHP 6.

You have to balance out the small bit of effort required in implementing
this solution against the huge amount of effort required in changing
thousands, if not millions of scripts.

For the PHP developers to say "we can't be bothered to update the POSIX
functions to deal with unicode, so we've decided to drop them from PHP
entirely even though it will break lots of scripts" will not go down well in
userland.

--
Tony Marston
http://www.tonymarston.net
http://www.radicore.org

"John Black" <spam@...> wrote in message
news:4AF70120.1040209@......

> The same can be said about the removal of magic_quotes(), it will break A
> LOT of old scripts.
> I am in the same boat, I did not keep up to date with the PHP developer
> plans and just found out about ereg when I installed PHP 5.3.
>
> I think it was handled properly by displaying warning messages before
> actually removing it. It will give people enough time to update their
> scripts or weed out the old and insecure scripts.
>
> Yes, it will create some headache but, AFAIK, it is for the better.
>
> --
> John
> Intelligent Life
> http://xkcd.com/638/

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Re: Die Page, Die! (Was: Preview button to show PDF without submittingpost data?)

2009-11-08T11:14:36Z

On Nov 8, 2009, at 1:20 PM, Dave M G <martin@...> wrote:

> Nathan,
>
> Thank you for responding.
>
>> yup.. forget the new window all together, if you have it set to
>> download
>> as an attachment then the user won't be taken away from the page;
>> so no
>> need for a new window at all.
>
> Right... so, we're all on board with the goals.
>
> Now... how do I do that?
>
> The whole problem here is that I keep getting a new window even
> though I
> don't want it.
>
> I would have thought if I told PHP to die immediately after outputting
> the PDF, it would give up on making the new window.
>
> I've also tried JavaScript to kill the window after it's made.
>
> *How* do I get the page to die?
>
> --
> Dave M G
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>

If you are popping up a new window just to handle the download, what
about using a small iframe or hidden frame to handle that instead?

Bastien

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Re: Die Page, Die! (Was: Preview button to show PDF without submittingpost data?)

2009-11-08T10:20:11Z

Nathan,

Thank you for responding.

> yup.. forget the new window all together, if you have it set to download
> as an attachment then the user won't be taken away from the page; so no
> need for a new window at all.

Right... so, we're all on board with the goals.

Now... how do I do that?

The whole problem here is that I keep getting a new window even though I
don't want it.

I would have thought if I told PHP to die immediately after outputting
the PDF, it would give up on making the new window.

I've also tried JavaScript to kill the window after it's made.

*How* do I get the page to die?

--
Dave M G

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Carriage Returns

2009-11-08T09:43:00Z

Dan Shirah wrote:

>> My guess is that you are getting an SQL error returned to you. What does
>> that
>> say? Is it talking about a broken SQL statement?
>>
>> Also, an example of the actual insert statement with example data would be
>> helpful.
>>
>>
>>
>
> I'm getting the generic error message: Prepare fails (E [SQLSTATE=IX 000
> SQLCODE=-282])
>
> My insert statement when echo'd out using print_r($insert) is nothing
> complex.
>
> INSERT INTO my_table VALUES (0, 'This is my text. When I use carriage
> returns it breaks. I am not sure why.')
>

informix doesn't allow new lines in sql strings; unless you enable the
"ALLOW_NEWLINE" setting on the server.

to remove newlines I'd suggest stripping all vertical space and
replacing it with spaces, then stripping down the excess horizontal
space.. something like

function strip_newlines( $string ) {
$string = preg_replace( '/\v/' , ' ' , $string );
$string = preg_replace( '/\h\h+/' , ' ' , $string );
return $string;
}

$sql = strip_newlines( $sql );

regards,

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Convert deprecated POSIX functions into wrappers for equivalent PCRE functions

2009-11-08T09:34:24Z

The same can be said about the removal of magic_quotes(), it will break
A LOT of old scripts.
I am in the same boat, I did not keep up to date with the PHP developer
plans and just found out about ereg when I installed PHP 5.3.

I think it was handled properly by displaying warning messages before
actually removing it. It will give people enough time to update their
scripts or weed out the old and insecure scripts.

Yes, it will create some headache but, AFAIK, it is for the better.

--
John
Intelligent Life
http://xkcd.com/638/

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php