Re: [PHP] NULL Date Entries...

[David Robley]

Paul M Foster wrote:

> 
> 
> 
>> 
>> However, checking to ensure the date is indeed valid and not something
>> like 31st February is a good idea I agree! :)
> 
> Wait-- there's not a 31st of February? When did they change that? ;-}
> 
> Paul
> 
I believe it was last February 30th the decision was made...



Cheers
-- 
David Robley

Kids-They're not sleeping, they're recharging!
Today is Pungenday, the 37th day of Confusion in the YOLD 3176. 


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

[PHP] Re: NULL Date Entries...

[David Robley]

Don Wieland wrote:

> In one of my forms, I am building a variable that I can use as an
> INSERT string.
> 
> On my form, I have several DATE fields which exist of 3 fields MM - DD
> - 
> 
> when I build my string it looks like this:
> 
> array('dbf'=>'applicant_dob',
> 'f'=>array('applicant_dob_1','applicant_dob_2','applicant_dob_3'),
> 'req'=>0, 's'=>'/'),
> 
> This enters in the DB fine when there is a DATE, but when these fields
> are left empty, it inserts into the the DB as 2069-12-31.
> 
> How does one deal with this?
> 
> Don Wieland

Aside from all the good advice already offered, if you want to accept a null
date, check what your DB does with it and whether you can set a default for
an empty date. Mysql for example can use -00-00


Cheers
-- 
David Robley

Microsoft - We put the "backwards" into backwards compatibility.
Today is Pungenday, the 37th day of Confusion in the YOLD 3176. 


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

[PHP] PHP 5.2.14RC2 & 5.3.3RC2 Released for Testing

[Johannes Schlüter]

The second release candidates of 5.2.14 and 5.3.3 were just released
for testing and can be downloaded here:

http://downloads.php.net/ilia/php-5.2.14RC2.tar.bz2 (md5sum:
d182560b697003d670ae8a3a804759f3)

http://downloads.php.net/johannes/php-5.3.3RC2.tar.bz2 (md5sum:
6c1b6c31f1a701a77bcb64ec4dcaac3f)

The windows binaries are available at: http://windows.php.net/qa/

This is another step in the release process of both versions and goal
is, depending on feedback, having a 3rd RC or a stable release two weeks
from now. Majority of the changes for both versions are of the "bug fix"
variety. To ensure that the release is solid, please test this RC
against your code base and report any problems that you encounter.

Johannes Schlüter
PHP 5.3 Release Master


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

[PHP] detect a script crash

[Ashley Sheridan]

Hi all,

Bit of a curve ball here (at least I couldn't find anything on Google
yet) but I need a way to be able to detect if a particular php script
crashes and generate some form of report from it.

Here is the system setup:

CentOS system, with the PHP scripts running as CLI called from a bash
script as part of a daemon. The setup is already all in-place for an
existing system, I've just been asked to implement a crash detection
system.

I know I can monitor the error logs with tail() to detect errors, but
that is likely not going to be the main issue which needs tracking.

I've found a bit of documentation online for pcntl_signal() which I
believe should do the trick, but I can't seem to find just a plain old
list of signal monikers and their meanings. Does anyone have any light
to shed on this?

Also, any other input/suggestions would be more than welcome.

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

Re: [PHP] detect a script crash

[Ashley Sheridan]

On Fri, 2010-07-02 at 11:51 +0100, Ashley Sheridan wrote:

> Hi all,
> 
> Bit of a curve ball here (at least I couldn't find anything on Google
> yet) but I need a way to be able to detect if a particular php script
> crashes and generate some form of report from it.
> 
> Here is the system setup:
> 
> CentOS system, with the PHP scripts running as CLI called from a bash
> script as part of a daemon. The setup is already all in-place for an
> existing system, I've just been asked to implement a crash detection
> system.
> 
> I know I can monitor the error logs with tail() to detect errors, but
> that is likely not going to be the main issue which needs tracking.
> 
> I've found a bit of documentation online for pcntl_signal() which I
> believe should do the trick, but I can't seem to find just a plain old
> list of signal monikers and their meanings. Does anyone have any light
> to shed on this?
> 
> Also, any other input/suggestions would be more than welcome.
> 
> Thanks,
> Ash
> http://www.ashleysheridan.co.uk
> 
> 


I think I've managed to answer my own question now. I found a list of
system codes at http://www.php.net/manual/en/pcntl.constants.php but
with no accompanying descriptions of what each one means (and quite
frankly they all look foreign to me for what they're worth!)

However, Wikipedia to the rescue, http://en.wikipedia.org/wiki/SIGILL
(and all the other signal pages it has - links at the bottom of that
one) it has a good list of the codes used by Unix systems and even the
Linux only ones which are just synonyms for the Unix ones.

Hopefully, that's useful to someone else who had a similar problem!

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

RE: [PHP] php processing name vs. id field

[Bob McConnell]

From: Ashley Sheridan

> Not sure if my other email got through earlier. Replacing the name
> attribute on form fields with the id one is not feasible at all. They
> don't even behave the same. What would happen if you had two forms on
a
> page that both had an element with the same name? Using the name
> attribute, everything is fine, but not so if you were using the id
> instead.

These conditions sound like a bugs to me. I can't imagine any reason why
different forms could have the same name or id. That applies to any set
of elements on a page. Each one must have a unique moniker, no matter
which attribute you use. Even the simple validations I use will complain
about your duplicates, as they should. Making them all unique also makes
it much simpler to use tools like Selenium or Silk Test to automate the
testing process.

Looking at the HTML 4.01 references given earlier in this thread, I see
that id is now a core attribute, i.e. it is available for all but a
handful of tags, while name is only available for the tags where it is
explicitly included. So it still appears to me that id is the preferred
attribute, as it is more generally available.

Bob McConnell

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

RE: [PHP] php processing name vs. id field

[Ashley Sheridan]

On Fri, 2010-07-02 at 08:49 -0400, Bob McConnell wrote:

> From: Ashley Sheridan
> 
> > Not sure if my other email got through earlier. Replacing the name
> > attribute on form fields with the id one is not feasible at all. They
> > don't even behave the same. What would happen if you had two forms on
> a
> > page that both had an element with the same name? Using the name
> > attribute, everything is fine, but not so if you were using the id
> > instead.
> 
> These conditions sound like a bugs to me. I can't imagine any reason why
> different forms could have the same name or id. That applies to any set
> of elements on a page. Each one must have a unique moniker, no matter
> which attribute you use. Even the simple validations I use will complain
> about your duplicates, as they should. Making them all unique also makes
> it much simpler to use tools like Selenium or Silk Test to automate the
> testing process.
> 
> Looking at the HTML 4.01 references given earlier in this thread, I see
> that id is now a core attribute, i.e. it is available for all but a
> handful of tags, while name is only available for the tags where it is
> explicitly included. So it still appears to me that id is the preferred
> attribute, as it is more generally available.
> 
> Bob McConnell
> 


It's not a bug in the code. Imagine this scenario:






A valid form with two input elements given the same name, which sends a
different value to the server depending on which button was triggered.
Seems valid enough to me. Only one value is ever sent, so why do I need
to give them unique names and further complicate my server-side code?

Imagine further that there is another form on the page containing the
product listings, and each one has a delete button. Now we all know the
folly of putting things like delete code into an  tag, so a button
will do the job:

Delete
Product
Delete
Product
Delete
Product

Perfectly valid, and something that is done a lot on apps I've seen and
built. Giving each a unique name just gets in the way, as you need to
use some sort of loop and pattern matching on the server just to get the
data you need.

ID is not a substitute for name on form elements. The reason name is
only available for a few elements is because it has a specific use-case,
which is not the same as the ID attribute at all.

I never said the forms themselves would have the same name or id, but
elements within them might have the same name, and two forms might have
elements with the same name. If the ID were to be a substitute for the
name attribute, then this could never happen, our scripts would become
more complex, and all for no gain.

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

Re: [PHP] php processing name vs. id field

[Peter Lind]

On 2 July 2010 15:01, Ashley Sheridan  wrote:
> On Fri, 2010-07-02 at 08:49 -0400, Bob McConnell wrote:
>
>> From: Ashley Sheridan
>>
>> > Not sure if my other email got through earlier. Replacing the name
>> > attribute on form fields with the id one is not feasible at all. They
>> > don't even behave the same. What would happen if you had two forms on
>> a
>> > page that both had an element with the same name? Using the name
>> > attribute, everything is fine, but not so if you were using the id
>> > instead.
>>
>> These conditions sound like a bugs to me. I can't imagine any reason why
>> different forms could have the same name or id. That applies to any set
>> of elements on a page. Each one must have a unique moniker, no matter
>> which attribute you use. Even the simple validations I use will complain
>> about your duplicates, as they should. Making them all unique also makes
>> it much simpler to use tools like Selenium or Silk Test to automate the
>> testing process.
>>
>> Looking at the HTML 4.01 references given earlier in this thread, I see
>> that id is now a core attribute, i.e. it is available for all but a
>> handful of tags, while name is only available for the tags where it is
>> explicitly included. So it still appears to me that id is the preferred
>> attribute, as it is more generally available.
>>
>> Bob McConnell
>>
>
>
> It's not a bug in the code. Imagine this scenario:
>
> 
>    
>    
> 
>
> A valid form with two input elements given the same name, which sends a
> different value to the server depending on which button was triggered.
> Seems valid enough to me. Only one value is ever sent, so why do I need
> to give them unique names and further complicate my server-side code?
>
> Imagine further that there is another form on the page containing the
> product listings, and each one has a delete button. Now we all know the
> folly of putting things like delete code into an  tag, so a button
> will do the job:
>
> Delete
> Product
> Delete
> Product
> Delete
> Product
>
> Perfectly valid, and something that is done a lot on apps I've seen and
> built. Giving each a unique name just gets in the way, as you need to
> use some sort of loop and pattern matching on the server just to get the
> data you need.
>
> ID is not a substitute for name on form elements. The reason name is
> only available for a few elements is because it has a specific use-case,
> which is not the same as the ID attribute at all.
>
> I never said the forms themselves would have the same name or id, but
> elements within them might have the same name, and two forms might have
> elements with the same name. If the ID were to be a substitute for the
> name attribute, then this could never happen, our scripts would become
> more complex, and all for no gain.
>

Let's also not forget radio buttons that *by design* should have the
same name - if they don't, they don't work properly.

Regards
Peter

-- 

WWW: http://plphp.dk / http://plind.dk
LinkedIn: http://www.linkedin.com/in/plind
BeWelcome/Couchsurfing: Fake51
Twitter: http://twitter.com/kafe15


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

[PHP] filter_var_array: apply multiple filters to one field

[Peter Lafferty]

Is there any way to apply multiple filters to one field using
filter_var_array?

 

Basically I have an email field which I want to sanitize and validate.
The docs and any sites I find only tell how to apply one filter at a
time using filter_var_array.

 

Regards,

Peter Lafferty
Software Developer

Web Reservations International Ltd.,
Block D, Charlemont Exchange
Charlemont Street
Dublin 2, Ireland

email: peter.laffe...@webresint.com
 

Tel: + 353 1 4980772
Fax: +353 1 4980715

RE: [PHP] php processing name vs. id field

[tedd]

At 2:01 PM +0100 7/2/10, Ashley Sheridan wrote:

-snip-

I agree with Ash 100%.

There is an "id" and a "name" attribute for input (et al) tags -- that's html.

I can use the attribute "name" for php and the attribute "id" for 
javascript and css because these are different languages with 
different scopes running in different environments -- that's the way 
it is.


Each attribute can be accessed by a variety of languages with no 
requirement on any specific language to know what the other languages 
may, or may not, be doing -- that's logical.


I can also use the same value for any attribute because there is no 
restriction on that either -- as well as it should be.


So, what's the major beef here? Is someone objecting to having both 
"id" and "name" being legal attributes for a tag? If so, this is 
really not the place to submit a compliant. However, it is the place 
to see the error of that thinking.


Giving the slightest bit of thought to dismissing the "name" 
attribute from tags should result in the realization that the act 
would break countless forms already in use. So the "beef" here is not 
well thought out, nor is it likely to happen.


Arguments against using/dismissing the "name" attribute in tags is 
simply nonsense.


Cheers,

tedd

--
---
http://sperling.com  http://ancientstones.com  http://earthstones.com

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

RE: [PHP] php processing name vs. id field

[Bob McConnell]

From: tedd

> >At 2:01 PM +0100 7/2/10, Ashley Sheridan wrote:
> -snip-
> 
> I agree with Ash 100%.
> 
> There is an "id" and a "name" attribute for input (et al) tags --
that's html.

...

> So, what's the major beef here? Is someone objecting to having both 
> "id" and "name" being legal attributes for a tag? If so, this is 
> really not the place to submit a compliant. However, it is the place 
> to see the error of that thinking.
> 
> Giving the slightest bit of thought to dismissing the "name" 
> attribute from tags should result in the realization that the act 
> would break countless forms already in use. So the "beef" here is not 
> well thought out, nor is it likely to happen.
> 
> Arguments against using/dismissing the "name" attribute in tags is 
> simply nonsense.

This discussion began when I pointed out that the name attribute is
deprecated in XHTML. This was later confirmed when someone pointed to
the actual specification at , however
there may be some confusion about the scope of the change. The
applicable section is shown below. Apparently HTML 5 is planning to take
a different path. Of course, nobody knows that for sure since the spec
is far from complete and will likely be undergoing major changes for
several more years.

Bob McConnell

-8<
4.10. The elements with 'id' and 'name' attributes

HTML 4 defined the name attribute for the elements a, applet, form,
frame, iframe, img, and map. HTML 4 also introduced the id attribute.
Both of these attributes are designed to be used as fragment
identifiers.

In XML, fragment identifiers are of type ID, and there can only be a
single attribute of type ID per element. Therefore, in XHTML 1.0 the id
attribute is defined to be of type ID. In order to ensure that XHTML 1.0
documents are well-structured XML documents, XHTML 1.0 documents MUST
use the id attribute when defining fragment identifiers on the elements
listed above. See the HTML Compatibility Guidelines for information on
ensuring such anchors are backward compatible when serving XHTML
documents as media type text/html.

Note that in XHTML 1.0, the name attribute of these elements is formally
deprecated, and will be removed in a subsequent version of XHTML.
-8<

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

RE: [PHP] php processing name vs. id field

[tedd]

At 8:49 AM -0400 7/2/10, Bob McConnell wrote:

These conditions sound like a bugs to me. I can't imagine any reason why
different forms could have the same name or id


Bob:

No offense, but duh!

I can imagine, try this:

The first form asks for the user's email address. The input statement 
has the attributes of "name" and "id" and both have values equal to 
"email", such as:




You have a css rule that styles the email input statement via "id" as 
the browser gets it from the server and presents it to the user.


You have a javascript routine that does a live-check of the validity 
of the email address while the user enters the data.


You have a php script that processes the data using "name" after the 
submission of the form.


All of these are using name and id attributes from an input tag AND 
there is NO restriction as to what values any of these attributes can 
hold nor is there any restriction on what you call them, nor does any 
of this happen at the same time or even in the same stage of action.


The css is delivered from the server to the browser, the javascript 
routine is triggered by the user entering data via his browser, and 
the php script is run after the user clicks submit. All of these 
happen at different times.


The second form (to fulfill your "different forms requirement) simply 
repeats the email value (i.e., value="" and 
awaits the user to confirm.


End of example -- and that's done routinely.

---


 Each one must have a unique moniker, no matter
which attribute you use.


That's nonsense. Why would html require that php, javascript, and css 
use different values for different attributes?


I don't think you've thought this out.

---


Even the simple validations I use will complain
about your duplicates, as they should.


Show me any validation that requires no duplicates in attribute 
naming convention.


---


Making them all unique also makes
it much simpler to use tools like Selenium or Silk Test to automate the
testing process.


Simpler for whom?


Looking at the HTML 4.01 references given earlier in this thread, I see
that id is now a core attribute, i.e. it is available for all but a
handful of tags, while name is only available for the tags where it is
explicitly included. So it still appears to me that id is the preferred
attribute, as it is more generally available.

Bob McConnell


Popularity of attributes is not an indicator of which is correct to 
use for all languages. It is only an indicator that the "id" 
attribute is more common, which has no point. The net is a collection 
of efforts and languages -- while you may want to reduce input 
statement (and other tags) attributes from allowing both "name" and 
"id" to just "id" the practice would be devastation on a global scale.


Please rethink.

Cheers,

tedd

--
---
http://sperling.com  http://ancientstones.com  http://earthstones.com

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

RE: [PHP] php processing name vs. id field

[tedd]

At 10:53 AM -0400 7/2/10, Bob McConnell wrote:

This discussion began when I pointed out that the name attribute is
deprecated in XHTML. This was later confirmed when someone pointed to
the actual specification at , however
there may be some confusion about the scope of the change. The
applicable section is shown below. Apparently HTML 5 is planning to take
a different path. Of course, nobody knows that for sure since the spec
is far from complete and will likely be undergoing major changes for
several more years.

Bob McConnell


What XHTML does is limited to XHTML.

Simply put, HTML is the glue that holds the web-works together. The 
attributes that HTML uses/approves is what concerns other languages. 
I am sure that the "powers that be" will consider the affects of 
changing established and well entrenched attributes (remember that 
"name" was used as an attribute before "id"). As such, I seriously 
doubt that "name" will fall by the wayside any time soon.


Cheers,

tedd


--
---
http://sperling.com  http://ancientstones.com  http://earthstones.com

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

[PHP] Delegating variable-length argument lists

[Jakob Günther]

Hi,

i'm writing a custom wrapper for the mysqli_stmt class. I have to
override the method mysqli_stmt::bind_param. This function uses
"variable-length argument lists". In my function i want to delegate its
arguments to the original function.

My first naiv implementation was that:

function bind_param($types) {
$sParams=array();
$first=true;
for($i=1; i < func_num_args(); $i++) {
$sParams[] = func_get_arg($i);
}

array_unshift ($sParams ,$types);
call_user_func_array (array ($this->mysqli_stmt, 'bind_param'), 
$sParams);
}

But this is not working, because  I need to pass it by reference. Is
there a way to retrieve references to a variable number of arguments?

Thx, Jakob

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

Re: [PHP] Past discussion

[Jim Lucas]

David McGlone wrote:
> Hi everyone,
> 
> I have been searching the archives for a past discussion where some software 
> that some folks use to (I think) save code snippets from e-mails for future 
> references or something of such.
> 
> Does anyone remember that discussion? I am trying to figure out a good way to 
> create my own "wiki" type thing so I can use it to help me and be able to go 
> back and review very helpful e-mails or code that was very helpful to my 
> understanding of how it works.
> 
> Here lately I've been remembering things that were brought up on the list 
> that 
> had very helpful info, but remembering what thread they were in or what 
> topic, 
> so I can find it in the archives is harder than I thought it would be.
> 
> Anyone have any suggestions, techniques or remember that discussion so I can 
> find it in the archives again?
> 

David,

Daniel Brown wrote a weekly summary stats app that scanned his email account and
totaled the number of lines of code someone wrote in their email sent to the
mailing list.  It might worth while to ask him for this code detection 
method(s).

-- 
Jim Lucas

A: Maybe because some people are too annoyed by top-posting.
Q: Why do I not get an answer to my question(s)?
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

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

Re: [PHP] Delegating variable-length argument lists

[Jakob Günther]

I did not find a solution, so i tried passing a array with references.

$arr = array(&$a, &$b);
bind_param("ii", $arr);

function bind_param($types, $arr){
array_unshift($arr, $types);
call_user_func_array (array ($stmt, 'bind_param'), $arr);
}

This worked in a test-case in one file. But if i call the bind-param-method
from another class it did not work. Do you have any suggestions on this?


Am 02.07.2010 17:25, schrieb Jakob Günther:
> Hi,
>
> i'm writing a custom wrapper for the mysqli_stmt class. I have to
> override the method mysqli_stmt::bind_param. This function uses
> "variable-length argument lists". In my function i want to delegate its
> arguments to the original function.
>
> My first naiv implementation was that:
>
> function bind_param($types) {
>   $sParams=array();
> $first=true;
> for($i=1; i < func_num_args(); $i++) {
> $sParams[] = func_get_arg($i);
> }
>   
>   array_unshift ($sParams ,$types);
> call_user_func_array (array ($this->mysqli_stmt, 'bind_param'),   
>   $sParams);
> }
>
> But this is not working, because  I need to pass it by reference. Is
> there a way to retrieve references to a variable number of arguments?
>
> Thx, Jakob
>
>   


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

RE: [PHP] php processing name vs. id field

[Bob McConnell]

From: tedd

> At 10:53 AM -0400 7/2/10, Bob McConnell wrote:
> >This discussion began when I pointed out that the name attribute is
> >deprecated in XHTML. This was later confirmed when someone pointed to
> >the actual specification at , however
> >there may be some confusion about the scope of the change. The
> >applicable section is shown below. Apparently HTML 5 is planning to
take
> >a different path. Of course, nobody knows that for sure since the
spec
> >is far from complete and will likely be undergoing major changes for
> >several more years.
> 
> What XHTML does is limited to XHTML.
> 
> Simply put, HTML is the glue that holds the web-works together. The 
> attributes that HTML uses/approves is what concerns other languages. 
> I am sure that the "powers that be" will consider the affects of 
> changing established and well entrenched attributes (remember that 
> "name" was used as an attribute before "id"). As such, I seriously 
> doubt that "name" will fall by the wayside any time soon.

Yes, the wonderful thing about standards is that there are so many to
chose from. My head is hurting even trying to consider all of this. We
have settled on XHTML for all corporate pages, since it is final, fixed
and well supported. It can also be validated easily using the HTML
Validator plug-in for Firefox, among others. A significant portion of my
work over the past year has been improving conformance by using that
plug-in.

The only other thing I plan to think about is how soon I should retire.
I'll be eligible for social security in less than six months, and if the
stock market is kind to my 401K, I should be ready by then. Since there
isn't anything left here that allows me to use my primary skills
(Assembly language and hardware device drivers) I am pretty much
treading water until I leave. I think my managers have put me on these
web pages simply to keep me occupied until then. It's obvious I don't
understand the underlying technology very well.

For those in the USofA, have a great Fourth of July holiday.

Bob McConnell

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

RE: [PHP] php processing name vs. id field

[Kirk . Johnson]

"Bob McConnell"  wrote on 07/02/2010 08:53:30 AM:

> > Arguments against using/dismissing the "name" attribute in tags is 
> > simply nonsense.
> 
> This discussion began when I pointed out that the name attribute is
> deprecated in XHTML. This was later confirmed when someone pointed to
> the actual specification at , however
> there may be some confusion about the scope of the change. The
> applicable section is shown below. Apparently HTML 5 is planning to take
> a different path. Of course, nobody knows that for sure since the spec
> is far from complete and will likely be undergoing major changes for
> several more years.
> 
> Bob McConnell
> 
> -8<
> 4.10. The elements with 'id' and 'name' attributes
> 
> HTML 4 defined the name attribute for the elements a, applet, form,
> frame, iframe, img, and map. HTML 4 also introduced the id attribute.
> Both of these attributes are designed to be used as fragment
> identifiers.
> 
> In XML, fragment identifiers are of type ID, and there can only be a
> single attribute of type ID per element. Therefore, in XHTML 1.0 the id
> attribute is defined to be of type ID. In order to ensure that XHTML 1.0
> documents are well-structured XML documents, XHTML 1.0 documents MUST
> use the id attribute when defining fragment identifiers on the elements
> listed above. See the HTML Compatibility Guidelines for information on
> ensuring such anchors are backward compatible when serving XHTML
> documents as media type text/html.
> 
> Note that in XHTML 1.0, the name attribute of these elements is formally
> deprecated, and will be removed in a subsequent version of XHTML.

At the risk of injecting a little light into this discussion ;) note the 
list of elements in the excerpt Bob provided: a, applet, form, frame, 
iframe, img, and map. Almost all replies to date have referred to the name 
attribute of the *form elements*: input, select, and textarea. Two 
different sets of elements.

As far as I am concerned, the "authorities" are free to remove the name 
attribute from the first set. I think it is safe to say that the name 
attribute will not be removed from the *form elements* anytime soon.

For all with a holiday coming up this weekend, have a good one!

Kirk

[PHP] complex unf8 indic script rendering and cairo

[shiplu]

Anyone knows where I can find cairo (http://www.php.net/cairo) examples.

The php sites doesn't have any example or tutorial.

I am looking for a way to render complex unf8 indic script. Cairo
seems a solution for me though I haven't tried yet.

if you have any suggestion on complex indic script rendering that'll be great.

Thanks

Shiplu Mokadd.im
My talks, http://talk.cmyweb.net
Follow me, http://twitter.com/shiplu
SUST Programmers, http://groups.google.com/group/p2psust
Innovation distinguishes bet ... ... (ask Steve Jobs the rest)

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

Re: [PHP] Delegating variable-length argument lists

[Adam Richardson]

On Fri, Jul 2, 2010 at 11:49 AM, Jakob Günther  wrote:

>
> I did not find a solution, so i tried passing a array with references.
>
> $arr = array(&$a, &$b);
> bind_param("ii", $arr);
>
> function bind_param($types, $arr){
>array_unshift($arr, $types);
>call_user_func_array (array ($stmt, 'bind_param'), $arr);
> }
>
> This worked in a test-case in one file. But if i call the bind-param-method
> from another class it did not work. Do you have any suggestions on this?
>
>
> Am 02.07.2010 17:25, schrieb Jakob Günther:
> > Hi,
> >
> > i'm writing a custom wrapper for the mysqli_stmt class. I have to
> > override the method mysqli_stmt::bind_param. This function uses
> > "variable-length argument lists". In my function i want to delegate its
> > arguments to the original function.
> >
> > My first naiv implementation was that:
> >
> > function bind_param($types) {
> >   $sParams=array();
> > $first=true;
> > for($i=1; i < func_num_args(); $i++) {
> > $sParams[] = func_get_arg($i);
> > }
> >
> >   array_unshift ($sParams ,$types);
> > call_user_func_array (array ($this->mysqli_stmt, 'bind_param'),
> >   $sParams);
> > }
> >
> > But this is not working, because  I need to pass it by reference. Is
> > there a way to retrieve references to a variable number of arguments?
> >
> > Thx, Jakob
> >
> >
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Hi Jakob,

Try looking at this page:
http://www.php.net/manual/en/mysqli-stmt.bind-param.php

Specifically, search for a comment by 'gregg at mochabomb dot com', in which
Gregg presents a simple wrapper class and deals with the referencing issue
the same way you did, by setting array values by reference.

I point this out as perhaps seeing the code will give you a clue as to why
your code had issues in your second test.  If you want help figuring out
what's causing trouble, try posting some of the other code (at least the
class and instance vars, connection method, and the query method(s))
contained within the class.

Adam

P.S. Sorry for the duplicate reply, Jakob, I forgot to reply to the entire
list the first time :(

-- 
Nephtali:  PHP web framework that functions beautifully
http://nephtaliproject.com

Re: [PHP] php processing name vs. id field

[Adam Richardson]

On Fri, Jul 2, 2010 at 12:28 PM,  wrote:

> "Bob McConnell"  wrote on 07/02/2010 08:53:30 AM:
>
> > > Arguments against using/dismissing the "name" attribute in tags is
> > > simply nonsense.
> >
> > This discussion began when I pointed out that the name attribute is
> > deprecated in XHTML. This was later confirmed when someone pointed to
> > the actual specification at , however
> > there may be some confusion about the scope of the change. The
> > applicable section is shown below. Apparently HTML 5 is planning to take
> > a different path. Of course, nobody knows that for sure since the spec
> > is far from complete and will likely be undergoing major changes for
> > several more years.
> >
> > Bob McConnell
> >
> > -8<
> > 4.10. The elements with 'id' and 'name' attributes
> >
> > HTML 4 defined the name attribute for the elements a, applet, form,
> > frame, iframe, img, and map. HTML 4 also introduced the id attribute.
> > Both of these attributes are designed to be used as fragment
> > identifiers.
> >
> > In XML, fragment identifiers are of type ID, and there can only be a
> > single attribute of type ID per element. Therefore, in XHTML 1.0 the id
> > attribute is defined to be of type ID. In order to ensure that XHTML 1.0
> > documents are well-structured XML documents, XHTML 1.0 documents MUST
> > use the id attribute when defining fragment identifiers on the elements
> > listed above. See the HTML Compatibility Guidelines for information on
> > ensuring such anchors are backward compatible when serving XHTML
> > documents as media type text/html.
> >
> > Note that in XHTML 1.0, the name attribute of these elements is formally
> > deprecated, and will be removed in a subsequent version of XHTML.
>
> At the risk of injecting a little light into this discussion ;) note the
> list of elements in the excerpt Bob provided: a, applet, form, frame,
> iframe, img, and map. Almost all replies to date have referred to the name
> attribute of the *form elements*: input, select, and textarea. Two
> different sets of elements.
>
> As far as I am concerned, the "authorities" are free to remove the name
> attribute from the first set. I think it is safe to say that the name
> attribute will not be removed from the *form elements* anytime soon.
>
> For all with a holiday coming up this weekend, have a good one!
>
> Kirk


Hi Kirk,

You beat me to it, that's exactly the issue at hand in this debate.  Name IS
deprecated (both in newer versions of HTML and XHTML) for those particular
elements:
http://derickrethans.nl/html-name-attribute-deprecated.html

As Derrick points out on that page, "always read the specs carefully" ;)

Adam

-- 
Nephtali:  PHP web framework that functions beautifully
http://nephtaliproject.com

Re: [PHP] php processing name vs. id field

[Peter Lind]

On 2 July 2010 19:52, Adam Richardson  wrote:
> On Fri, Jul 2, 2010 at 12:28 PM,  wrote:
>
>> "Bob McConnell"  wrote on 07/02/2010 08:53:30 AM:
>>
>> > > Arguments against using/dismissing the "name" attribute in tags is
>> > > simply nonsense.
>> >
>> > This discussion began when I pointed out that the name attribute is
>> > deprecated in XHTML. This was later confirmed when someone pointed to
>> > the actual specification at , however
>> > there may be some confusion about the scope of the change. The
>> > applicable section is shown below. Apparently HTML 5 is planning to take
>> > a different path. Of course, nobody knows that for sure since the spec
>> > is far from complete and will likely be undergoing major changes for
>> > several more years.
>> >
>> > Bob McConnell
>> >
>> > -8<
>> > 4.10. The elements with 'id' and 'name' attributes
>> >
>> > HTML 4 defined the name attribute for the elements a, applet, form,
>> > frame, iframe, img, and map. HTML 4 also introduced the id attribute.
>> > Both of these attributes are designed to be used as fragment
>> > identifiers.
>> >
>> > In XML, fragment identifiers are of type ID, and there can only be a
>> > single attribute of type ID per element. Therefore, in XHTML 1.0 the id
>> > attribute is defined to be of type ID. In order to ensure that XHTML 1.0
>> > documents are well-structured XML documents, XHTML 1.0 documents MUST
>> > use the id attribute when defining fragment identifiers on the elements
>> > listed above. See the HTML Compatibility Guidelines for information on
>> > ensuring such anchors are backward compatible when serving XHTML
>> > documents as media type text/html.
>> >
>> > Note that in XHTML 1.0, the name attribute of these elements is formally
>> > deprecated, and will be removed in a subsequent version of XHTML.
>>
>> At the risk of injecting a little light into this discussion ;) note the
>> list of elements in the excerpt Bob provided: a, applet, form, frame,
>> iframe, img, and map. Almost all replies to date have referred to the name
>> attribute of the *form elements*: input, select, and textarea. Two
>> different sets of elements.
>>
>> As far as I am concerned, the "authorities" are free to remove the name
>> attribute from the first set. I think it is safe to say that the name
>> attribute will not be removed from the *form elements* anytime soon.
>>
>> For all with a holiday coming up this weekend, have a good one!
>>
>> Kirk
>
>
> Hi Kirk,
>
> You beat me to it, that's exactly the issue at hand in this debate.  Name IS
> deprecated (both in newer versions of HTML and XHTML) for those particular
> elements:
> http://derickrethans.nl/html-name-attribute-deprecated.html
>
> As Derrick points out on that page, "always read the specs carefully" ;)
>

That was pointed out more than a day ago ...


-- 

WWW: http://plphp.dk / http://plind.dk
LinkedIn: http://www.linkedin.com/in/plind
BeWelcome/Couchsurfing: Fake51
Twitter: http://twitter.com/kafe15


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

Re: [PHP] php processing name vs. id field

[Adam Richardson]

On Fri, Jul 2, 2010 at 1:59 PM, Peter Lind  wrote:

> On 2 July 2010 19:52, Adam Richardson  wrote:
> > On Fri, Jul 2, 2010 at 12:28 PM,  wrote:
> >
> >> "Bob McConnell"  wrote on 07/02/2010 08:53:30 AM:
> >>
> >> > > Arguments against using/dismissing the "name" attribute in tags is
> >> > > simply nonsense.
> >> >
> >> > This discussion began when I pointed out that the name attribute is
> >> > deprecated in XHTML. This was later confirmed when someone pointed to
> >> > the actual specification at , however
> >> > there may be some confusion about the scope of the change. The
> >> > applicable section is shown below. Apparently HTML 5 is planning to
> take
> >> > a different path. Of course, nobody knows that for sure since the spec
> >> > is far from complete and will likely be undergoing major changes for
> >> > several more years.
> >> >
> >> > Bob McConnell
> >> >
> >> > -8<
> >> > 4.10. The elements with 'id' and 'name' attributes
> >> >
> >> > HTML 4 defined the name attribute for the elements a, applet, form,
> >> > frame, iframe, img, and map. HTML 4 also introduced the id attribute.
> >> > Both of these attributes are designed to be used as fragment
> >> > identifiers.
> >> >
> >> > In XML, fragment identifiers are of type ID, and there can only be a
> >> > single attribute of type ID per element. Therefore, in XHTML 1.0 the
> id
> >> > attribute is defined to be of type ID. In order to ensure that XHTML
> 1.0
> >> > documents are well-structured XML documents, XHTML 1.0 documents MUST
> >> > use the id attribute when defining fragment identifiers on the
> elements
> >> > listed above. See the HTML Compatibility Guidelines for information on
> >> > ensuring such anchors are backward compatible when serving XHTML
> >> > documents as media type text/html.
> >> >
> >> > Note that in XHTML 1.0, the name attribute of these elements is
> formally
> >> > deprecated, and will be removed in a subsequent version of XHTML.
> >>
> >> At the risk of injecting a little light into this discussion ;) note the
> >> list of elements in the excerpt Bob provided: a, applet, form, frame,
> >> iframe, img, and map. Almost all replies to date have referred to the
> name
> >> attribute of the *form elements*: input, select, and textarea. Two
> >> different sets of elements.
> >>
> >> As far as I am concerned, the "authorities" are free to remove the name
> >> attribute from the first set. I think it is safe to say that the name
> >> attribute will not be removed from the *form elements* anytime soon.
> >>
> >> For all with a holiday coming up this weekend, have a good one!
> >>
> >> Kirk
> >
> >
> > Hi Kirk,
> >
> > You beat me to it, that's exactly the issue at hand in this debate.  Name
> IS
> > deprecated (both in newer versions of HTML and XHTML) for those
> particular
> > elements:
> > http://derickrethans.nl/html-name-attribute-deprecated.html
> >
> > As Derrick points out on that page, "always read the specs carefully" ;)
> >
>
> That was pointed out more than a day ago ...
>
>
> --
> 
> WWW: http://plphp.dk / http://plind.dk
> LinkedIn: http://www.linkedin.com/in/plind
> BeWelcome/Couchsurfing: Fake51
> Twitter: http://twitter.com/kafe15
> 
>

Sorry, Peter,

I didn't realize you'd addressed this in a previous message.  I saw the new
messages today and wanted to make sure the distinction had been made.

Adam

-- 
Nephtali:  PHP web framework that functions beautifully
http://nephtaliproject.com

Re: [PHP] php processing name vs. id field

[Peter Lind]

On 2 July 2010 20:03, Adam Richardson  wrote:
> On Fri, Jul 2, 2010 at 1:59 PM, Peter Lind  wrote:
>
>> On 2 July 2010 19:52, Adam Richardson  wrote:
>> > On Fri, Jul 2, 2010 at 12:28 PM,  wrote:
>> >
>> >> "Bob McConnell"  wrote on 07/02/2010 08:53:30 AM:
>> >>
>> >> > > Arguments against using/dismissing the "name" attribute in tags is
>> >> > > simply nonsense.
>> >> >
>> >> > This discussion began when I pointed out that the name attribute is
>> >> > deprecated in XHTML. This was later confirmed when someone pointed to
>> >> > the actual specification at , however
>> >> > there may be some confusion about the scope of the change. The
>> >> > applicable section is shown below. Apparently HTML 5 is planning to
>> take
>> >> > a different path. Of course, nobody knows that for sure since the spec
>> >> > is far from complete and will likely be undergoing major changes for
>> >> > several more years.
>> >> >
>> >> > Bob McConnell
>> >> >
>> >> > -8<
>> >> > 4.10. The elements with 'id' and 'name' attributes
>> >> >
>> >> > HTML 4 defined the name attribute for the elements a, applet, form,
>> >> > frame, iframe, img, and map. HTML 4 also introduced the id attribute.
>> >> > Both of these attributes are designed to be used as fragment
>> >> > identifiers.
>> >> >
>> >> > In XML, fragment identifiers are of type ID, and there can only be a
>> >> > single attribute of type ID per element. Therefore, in XHTML 1.0 the
>> id
>> >> > attribute is defined to be of type ID. In order to ensure that XHTML
>> 1.0
>> >> > documents are well-structured XML documents, XHTML 1.0 documents MUST
>> >> > use the id attribute when defining fragment identifiers on the
>> elements
>> >> > listed above. See the HTML Compatibility Guidelines for information on
>> >> > ensuring such anchors are backward compatible when serving XHTML
>> >> > documents as media type text/html.
>> >> >
>> >> > Note that in XHTML 1.0, the name attribute of these elements is
>> formally
>> >> > deprecated, and will be removed in a subsequent version of XHTML.
>> >>
>> >> At the risk of injecting a little light into this discussion ;) note the
>> >> list of elements in the excerpt Bob provided: a, applet, form, frame,
>> >> iframe, img, and map. Almost all replies to date have referred to the
>> name
>> >> attribute of the *form elements*: input, select, and textarea. Two
>> >> different sets of elements.
>> >>
>> >> As far as I am concerned, the "authorities" are free to remove the name
>> >> attribute from the first set. I think it is safe to say that the name
>> >> attribute will not be removed from the *form elements* anytime soon.
>> >>
>> >> For all with a holiday coming up this weekend, have a good one!
>> >>
>> >> Kirk
>> >
>> >
>> > Hi Kirk,
>> >
>> > You beat me to it, that's exactly the issue at hand in this debate.  Name
>> IS
>> > deprecated (both in newer versions of HTML and XHTML) for those
>> particular
>> > elements:
>> > http://derickrethans.nl/html-name-attribute-deprecated.html
>> >
>> > As Derrick points out on that page, "always read the specs carefully" ;)
>> >
>>
>> That was pointed out more than a day ago ...
>>
>>
>> --
>> 
>> WWW: http://plphp.dk / http://plind.dk
>> LinkedIn: http://www.linkedin.com/in/plind
>> BeWelcome/Couchsurfing: Fake51
>> Twitter: http://twitter.com/kafe15
>> 
>>
>
> Sorry, Peter,
>
> I didn't realize you'd addressed this in a previous message.  I saw the new
> messages today and wanted to make sure the distinction had been made.
>

And on that notion, let me apologize for my obvious overreaction. It's
great that people are so helpful here :)

Regards
Peter


-- 

WWW: http://plphp.dk / http://plind.dk
LinkedIn: http://www.linkedin.com/in/plind
BeWelcome/Couchsurfing: Fake51
Twitter: http://twitter.com/kafe15


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

[PHP] CFP for Surge Scalability Conference 2010

[Jason Dixon]

A quick reminder that there's one week left to submit your abstract for
this year's Surge Scalability Conference.  The event is taking place on
Sept 30 and Oct 1, 2010 in Baltimore, MD.  Surge focuses on case studies
that address production failures and the re-engineering efforts that led
to victory in Web Applications or Internet Architectures.

Our Keynote speakers include John Allspaw and Theo Schlossnagle.  We are
currently accepting submissions for the Call For Papers through July
9th.  You can find more information, including suggested topics and our
current list of speakers, online:

http://omniti.com/surge/2010

I'd also like to urge folks who are planning to attend, to get your
session passes sooner rather than later.  We have limited seating and we
are on track to sell out early.  For more information, including the
CFP, sponsorship of the event, or participating as an exhibitor, please
visit the Surge website or contact us at su...@omniti.com.

Thanks,

-- 
Jason Dixon
OmniTI Computer Consulting, Inc.
jdi...@omniti.com
443.325.1357 x.241

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

[PHP] SELECT AVG(rating)

[Ben Miller]

Hi - I have a MySQL table full of product reviews and I'm trying to select
info for only the top 5 rated products.  The only way I can figure out how
to do it so far is something like:

$query1 = mysql_query("SELECT * FROM products");
for($i=1;$i<=mysql_num_rows($query1);$i++) {
$row1 = mysql_fetch_array($query1,MYSQL_ASSOC);
$query2 = mysql_query("SELECT AVG(rating) as rating FROM reviews
WHERE product_id='" . $row1['product_id'] . "'");
...
$product[$i]['name'] = $row1['product_name'];
$product[$i]['rating'] = $row2['rating'];
}

And then use array functions to sort and display only the first 5.

Is there any easier way to get this done with a single query - something
like "SELECT AVG(rating) WHERE product_id=DISTINCT(product_id)"? <<= I tried
that - it didn't work.  Would greatly appreciate any advice.  Thanks,

Ben 



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

Re: [PHP] SELECT AVG(rating)

[Ashley Sheridan]

On Fri, 2010-07-02 at 14:32 -0600, Ben Miller wrote:

> Hi - I have a MySQL table full of product reviews and I'm trying to select
> info for only the top 5 rated products.  The only way I can figure out how
> to do it so far is something like:
> 
> $query1 = mysql_query("SELECT * FROM products");
> for($i=1;$i<=mysql_num_rows($query1);$i++) {
>   $row1 = mysql_fetch_array($query1,MYSQL_ASSOC);
>   $query2 = mysql_query("SELECT AVG(rating) as rating FROM reviews
> WHERE product_id='" . $row1['product_id'] . "'");
>   ...
>   $product[$i]['name'] = $row1['product_name'];
>   $product[$i]['rating'] = $row2['rating'];
> }
> 
> And then use array functions to sort and display only the first 5.
> 
> Is there any easier way to get this done with a single query - something
> like "SELECT AVG(rating) WHERE product_id=DISTINCT(product_id)"? <<= I tried
> that - it didn't work.  Would greatly appreciate any advice.  Thanks,
> 
> Ben 
> 
> 
> 


How about something like this (untested)

SELECT products.product_id, AVG(reviews.rating) AS rating
FROM products
LEFT JOIN reviews ON (reviews.product_id = products.product_id)
GROUP BY products.product_id
ORDER BY rating
LIMIT 1,5

I'm unsure about that order and limit there, so you might have to wrap
that inside of a temporary table query and take your 5 out of that. A
join is the right way to go with this though I reckon.

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

RE: [PHP] SELECT AVG(rating)

[Ben Miller]

-Original Message-
From: Ashley Sheridan [mailto:a...@ashleysheridan.co.uk] 
Sent: Friday, July 02, 2010 2:43 PM
To: b...@tottd.com
Cc: php-general@lists.php.net
Subject: Re: [PHP] SELECT AVG(rating)

On Fri, 2010-07-02 at 14:32 -0600, Ben Miller wrote:

> Hi - I have a MySQL table full of product reviews and I'm trying to select
> info for only the top 5 rated products.  The only way I can figure out how
> to do it so far is something like:
> 
> $query1 = mysql_query("SELECT * FROM products");
> for($i=1;$i<=mysql_num_rows($query1);$i++) {
>   $row1 = mysql_fetch_array($query1,MYSQL_ASSOC);
>   $query2 = mysql_query("SELECT AVG(rating) as rating FROM reviews
> WHERE product_id='" . $row1['product_id'] . "'");
>   ...
>   $product[$i]['name'] = $row1['product_name'];
>   $product[$i]['rating'] = $row2['rating'];
> }
> 
> And then use array functions to sort and display only the first 5.
> 
> Is there any easier way to get this done with a single query - something
> like "SELECT AVG(rating) WHERE product_id=DISTINCT(product_id)"? <<= I
tried
> that - it didn't work.  Would greatly appreciate any advice.  Thanks,
> 
> Ben 
> 
> 
> 


How about something like this (untested)

SELECT products.product_id, AVG(reviews.rating) AS rating
FROM products
LEFT JOIN reviews ON (reviews.product_id = products.product_id)
GROUP BY products.product_id
ORDER BY rating
LIMIT 1,5

I'm unsure about that order and limit there, so you might have to wrap
that inside of a temporary table query and take your 5 out of that. A
join is the right way to go with this though I reckon.

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




Adding a DESC after ORDER BY rating did it perfectly.  I had tried a few
JOIN queries, but was building them incorrectly.  Thank you so much for your
help.

Ben



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

[PHP] What's wrong in this function? Does not work for me.

[Carlos Sura]

Hello, this function does not work for me... And I really don't know what am I 
doing wrong... Any help??

This function is in a class, and I call it in a form, to create a new user..



$objEmploye=new Employe;
if ( 
$objEmploye->insert(array($name,$lastname,$salary,$dui,$afp,$isss,$nit)) == 
true){
echo 'Saved';
}else{
echo 'Error, try again';
} 
}else{


function insert($field){
if($this->con->connect()==true){
return mysql_query("INSERT INTO employes (name,lastname, salary, 
id, afp, isss, nit) VALUES ('".$field[0]."', 
'".$field[1]."','".$field[2]."','".$field[3]."','".$field[4]."','".$field[5]."','".$field[6]."')");
}
}




Thanks.
  
_
http://clk.atdmt.com/UKM/go/19780/direct/01/
Do you have a story that started on Hotmail? Tell us now

Re: [PHP] What's wrong in this function? Does not work for me.

[Ashley Sheridan]

On Fri, 2010-07-02 at 22:05 +, Carlos Sura wrote:

> 
> Hello, this function does not work for me... And I really don't know what am 
> I doing wrong... Any help??
> 
> This function is in a class, and I call it in a form, to create a new user..
> 
> 
> 
> $objEmploye=new Employe;
> if ( 
> $objEmploye->insert(array($name,$lastname,$salary,$dui,$afp,$isss,$nit)) == 
> true){
> echo 'Saved';
> }else{
> echo 'Error, try again';
> } 
> }else{
> 
> 
> function insert($field){
> if($this->con->connect()==true){
> return mysql_query("INSERT INTO employes (name,lastname, salary, 
> id, afp, isss, nit) VALUES ('".$field[0]."', 
> '".$field[1]."','".$field[2]."','".$field[3]."','".$field[4]."','".$field[5]."','".$field[6]."')");
> }
> }
> 
> 
> 
> 
> Thanks.
> 
> _
> http://clk.atdmt.com/UKM/go/19780/direct/01/
> Do you have a story that started on Hotmail? Tell us now


I can't see anything wrong with that code excerpt. Are you getting a
specific error, and if so, what is the code on and around the line
number indicated in that error?

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

RE: [PHP] What's wrong in this function? Does not work for me.

[Carlos Sura]

Hello Ash,

No, I don't get an error message, the thing is, my post form, isn't working... 
I can't post those fields in database when I fill them up in the form... But, I 
really don't know why... Do you want my form code? all the entire class.php 
code??

Thank you for helping me.

Carlos Sura.






Subject: Re: [PHP] What's wrong in this function? Does not work for me.
From: a...@ashleysheridan.co.uk
To: carlos_s...@hotmail.com
CC: php-general@lists.php.net
Date: Sat, 3 Jul 2010 00:08:05 +0100






  
  


On Fri, 2010-07-02 at 22:05 +, Carlos Sura wrote:


Hello, this function does not work for me... And I really don't know what am I 
doing wrong... Any help??

This function is in a class, and I call it in a form, to create a new user..



$objEmploye=new Employe;
if ( 
$objEmploye->insert(array($name,$lastname,$salary,$dui,$afp,$isss,$nit)) == 
true){
echo 'Saved';
}else{
echo 'Error, try again';
} 
}else{


function insert($field){
if($this->con->connect()==true){
return mysql_query("INSERT INTO employes (name,lastname, salary, 
id, afp, isss, nit) VALUES ('".$field[0]."', 
'".$field[1]."','".$field[2]."','".$field[3]."','".$field[4]."','".$field[5]."','".$field[6]."')");
}
}




Thanks.
  
_
http://clk.atdmt.com/UKM/go/19780/direct/01/
Do you have a story that started on Hotmail? Tell us now




I can't see anything wrong with that code excerpt. Are you getting a specific 
error, and if so, what is the code on and around the line number indicated in 
that error?






Thanks,

Ash

http://www.ashleysheridan.co.uk







  
_
http://clk.atdmt.com/UKM/go/19780/direct/01/
We want to hear all your funny, exciting and crazy Hotmail stories. Tell us now

RE: [PHP] What's wrong in this function? Does not work for me.

[Ashley Sheridan]

On Fri, 2010-07-02 at 23:19 +, Carlos Sura wrote:

> Hello Ash,
> 
> No, I don't get an error message, the thing is, my post form, isn't 
> working... I can't post those fields in database when I fill them up in the 
> form... But, I really don't know why... Do you want my form code? all the 
> entire class.php code??
> 
> Thank you for helping me.
> 
> Carlos Sura.
> 
> 
> 
> 
> 
> 
> Subject: Re: [PHP] What's wrong in this function? Does not work for me.
> From: a...@ashleysheridan.co.uk
> To: carlos_s...@hotmail.com
> CC: php-general@lists.php.net
> Date: Sat, 3 Jul 2010 00:08:05 +0100
> 
> 
> 
> 
> 
> 
>   
>   
> 
> 
> On Fri, 2010-07-02 at 22:05 +, Carlos Sura wrote:
> 
> 
> Hello, this function does not work for me... And I really don't know what am 
> I doing wrong... Any help??
> 
> This function is in a class, and I call it in a form, to create a new user..
> 
> 
> 
> $objEmploye=new Employe;
> if ( 
> $objEmploye->insert(array($name,$lastname,$salary,$dui,$afp,$isss,$nit)) == 
> true){
> echo 'Saved';
> }else{
> echo 'Error, try again';
> } 
> }else{
> 
> 
> function insert($field){
> if($this->con->connect()==true){
> return mysql_query("INSERT INTO employes (name,lastname, salary, 
> id, afp, isss, nit) VALUES ('".$field[0]."', 
> '".$field[1]."','".$field[2]."','".$field[3]."','".$field[4]."','".$field[5]."','".$field[6]."')");
> }
> }
> 
> 
> 
> 
> Thanks.
> 
> _
> http://clk.atdmt.com/UKM/go/19780/direct/01/
> Do you have a story that started on Hotmail? Tell us now
> 
> 
> 
> 
> I can't see anything wrong with that code excerpt. Are you getting a specific 
> error, and if so, what is the code on and around the line number indicated in 
> that error?
> 
> 
> 
> 
> 
> 
> Thanks,
> 
> Ash
> 
> http://www.ashleysheridan.co.uk
> 
> 
> 
> 
> 
> 
> 
> 
> _
> http://clk.atdmt.com/UKM/go/19780/direct/01/
> We want to hear all your funny, exciting and crazy Hotmail stories. Tell us 
> now


Break the code down into very simple parts with echo statements. First,
I'd echo out the $_POST or $_GET data that you're using to see if the
values you think are being sent are being sent. Then, move onto the next
part of code, stepping through with echo statements to output variable
values to ensure that your data is following the right path. This is one
of the easiest ways to find a problem I've found, short of using an IDE
to step through the code.

Also, you could put the code up on something like pastebin and post a
link to it, which will let people see what the code looks like and
hopefully figure out where the problem is.

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

[PHP] Re: mail() + localhost

[Manuel Lemos]

Hello,

on 07/01/2010 10:09 AM Shreyas Agasthya said the following:
> PHP'ers,
> 
> I am sure this would have been asked a zillion times but I take this as my
> turn to get some help. I hate to ask such rhetorical questions but quite
> couldn't understand how to tweak this.
> 
> All I am trying to do is send a mail from my localhost to my Gmail ID. I
> read stuff about how the SMTP port should be accessible; should be open et
> al. My set-up is very simple:

You cannot use the mail() function because it does not support
authentication.

You need to use some other component that supports SMTP authentication.

I use the MIME message class along with a SMTP class.

http://www.phpclasses.org/mimemessage

You may want to read this article to learn how to set it right to send
messages via Gmail, Hotmail or Yahoo.

http://www.phpclasses.org/blog/package/9/post/1-Sending-email-using-SMTP-servers-of-Gmail-Hotmail-or-Yahoo-with-PHP.html

-- 

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

[PHP] Re: how to use HTML Symbol Entities with mail() ?

[Manuel Lemos]

Hello,

on 07/01/2010 10:34 AM cr.vege...@gmail.com said the following:
> Hi List,
> 
> I am working on generated emails, using the mail() function.
> Works fine, but when including characters like ∧ (= ∧) or ∨ (= 
> ∨)
> in the message, these characters are displayed as ? in the emails.
> 
> Snippet:
> $headers  = 'MIME-Version: 1.0' . "\r\n";
> $headers .= 'Content-type: text/html; charset=iso-8859-1' . "\r\n";
> ...
> $bool = mail ($mailto, $subject, $body, $headers);
> 
> also tested with:
> $headers .= 'Content-type: text/html; charset=UTF-8' . "\r\n";
> but without result.
> 
> Any ideas ?
> TIA, Cor

When those characters appear as question marks is because you are using
a font in the messages that does not have characters with those codes.

Try including the sections of those characters with some span tags like
this ∨

-- 

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