php-general Digest 24 Oct 2005 14:52:02 -0000 Issue 3755

Topics (messages 224530 through 224547):

Re: error reporting php-5.0.4-10.4 on FC4
        224530 by: Bob Hartung
        224531 by: Jasper Bryant-Greene
        224532 by: Derek Williams
        224533 by: Bob Hartung
        224534 by: Jasper Bryant-Greene
        224538 by: Jochem Maas

Re: error reporting php-5.0.4-10.4 on FC4 - RESOLVED!!
        224535 by: Bob Hartung

Re: Abstract Classes?
        224536 by: Richard Lynch
        224537 by: Colin Shreffler
        224541 by: Alan Lord
        224545 by: Oliver Grätz

Problem reading SimpleXML array
        224539 by: George Pitcher

Re: Function that convert national characters into ASCII
        224540 by: Robin Vickery

Re: php, expect and screen
        224542 by: Olivier Cant

Php, Rails and ajax
        224543 by: Jacob Friis Saxberg

Output files encoding
        224544 by: Yannick Warnier
        224546 by: Yannick Warnier

cleanly written shop-system (php5, object-oriented)?
        224547 by: Phillip Oertel

Administrivia:

To subscribe to the digest, e-mail:
        [EMAIL PROTECTED]

To unsubscribe from the digest, e-mail:
        [EMAIL PROTECTED]

To post to the list, e-mail:
        [email protected]


----------------------------------------------------------------------
--- Begin Message ---
Jasper
  If if make a file containing only
  <?php
    phpinfo() ;
  ?>
  I get what I expected.

  If I make a file containing
<?php

phpinfo() ;

// Now a simple class and a call to the class
    class Simple()
    {
        void __construct()
        {
            echo "In the constructor" ;
        }
    }

    $newSimple = new Simple ;

?>

I get NO output or errors in the browser window. If I select "view source" it returns:
   <html><body></body><html>

Eh?  Anyone with any other ideas

Tnx

Bob Hartung

Jasper Bryant-Greene wrote:
<snip all before.

--- End Message ---
--- Begin Message ---
On Sun, 2005-10-23 at 21:31 -0400, Bob Hartung wrote:
> Jasper
>    If if make a file containing only
>    <?php
>      phpinfo() ;
>    ?>
>    I get what I expected.
> 
>    If I make a file containing
> <?php
> 
> phpinfo() ;
> 
> // Now a simple class and a call to the class
>       class Simple()

Your error is here    ^^ (brackets shouldn't be there)

But PHP should tell you that by throwing a Fatal error. What are the
values of error_reporting and display_errors that display in the
phpinfo() output?

By the way, the "<html><body></body></html>" is put there by your
browser, not PHP. PHP is actually outputting absolutely nothing in the
response-body.

-- 
Jasper Bryant-Greene
General Manager
Album Limited

e: [EMAIL PROTECTED]
w: http://www.album.co.nz/
p: 0800 4 ALBUM (0800 425 286) or +64 21 232 3303
a: PO Box 579, Christchurch 8015, New Zealand

--- End Message ---
--- Begin Message ---
Bob Hartung wrote:
Jasper
  If if make a file containing only
  <?php
    phpinfo() ;
  ?>
  I get what I expected.

  If I make a file containing
<?php

phpinfo() ;

// Now a simple class and a call to the class
    class Simple()
    {
        void __construct()
        {
            echo "In the constructor" ;
        }
    }

    $newSimple = new Simple ;

?>

I get NO output or errors in the browser window. If I select "view source" it returns:
   <html><body></body><html>

Eh?  Anyone with any other ideas

Tnx

Bob Hartung

Jasper Bryant-Greene wrote:
<snip all before.

How about <?php error_log('this should write to the file var/log/php_errors'); echo 'a test to write to error log file'; ?>

Which should write to your error log file,php_errors, in the existing directory "var/log". The browser should also render "a test to write to error log file".

Have you tried changing the log file name to something else? I don't think that php_errors is a key word, but you never know.
--- End Message ---
--- Begin Message ---
Jasper & Derek

  phpinfo() says:
        configuration file path     /etc/php.ini

  PHP Core
  Directive            Local Value           Master Value

display_errors            Off                   Off
error_log                no value              no value
log errors                on                     on

Derek's idea sends nothing to the log but does send to the browser.

It seems that /etc/php.ini is not being parsed since it says:

  error_reporting  =  E_ALL
  display_errors = On
  display_startup_errors = On
  log_errors = On

error_log = /var/log/php_error

I'm not sure where to turn at this point, except to get some sleep and attach this problem again tomorrow night when I return home from work.

Thanks!  Update tomorrow

Bob

Jasper Bryant-Greene wrote:
On Sun, 2005-10-23 at 21:31 -0400, Bob Hartung wrote:

Jasper
  If if make a file containing only
  <?php
    phpinfo() ;
  ?>
  I get what I expected.

  If I make a file containing
<?php

phpinfo() ;

// Now a simple class and a call to the class
        class Simple()


Your error is here    ^^ (brackets shouldn't be there)

But PHP should tell you that by throwing a Fatal error. What are the
values of error_reporting and display_errors that display in the
phpinfo() output?

By the way, the "<html><body></body></html>" is put there by your
browser, not PHP. PHP is actually outputting absolutely nothing in the
response-body.


--- End Message ---
--- Begin Message ---
On Sun, 2005-10-23 at 23:01 -0400, Bob Hartung wrote:
> Jasper & Derek
> 
>    phpinfo() says:
>       configuration file path     /etc/php.ini
> 
>    PHP Core
>    Directive            Local Value           Master Value
> 
> display_errors            Off                   Off
> error_log                no value              no value
> log errors                on                     on
> 
> Derek's idea sends nothing to the log but does send to the browser.
> 
> It seems that /etc/php.ini is not being parsed since it says:
> 
>    error_reporting  =  E_ALL
>    display_errors = On
>    display_startup_errors = On
>    log_errors = On

/etc/php.ini *is* being parsed, it says so right there (above). However,
display_errors isn't. Do a search inside /etc/php.ini for
display_errors, see if there's more than one declaration for it. Make
sure it isn't commented out (sounds silly, but you never know)...

Oh, and check the permissions on /etc/php.ini, just in case.

-- 
Jasper Bryant-Greene
General Manager
Album Limited

e: [EMAIL PROTECTED]
w: http://www.album.co.nz/
p: 0800 4 ALBUM (0800 425 286) or +64 21 232 3303
a: PO Box 579, Christchurch 8015, New Zealand

--- End Message ---
--- Begin Message ---
Bob Hartung wrote:
Jasper
  If if make a file containing only
  <?php
    phpinfo() ;
  ?>
  I get what I expected.

take a good look at where php is reading its ini file from
- it may not be where you expect


  If I make a file containing
<?php

phpinfo() ;

// Now a simple class and a call to the class
    class Simple()
    {
        void __construct()

'void' is not a php keyword. that would give a parse error


        {
            echo "In the constructor" ;
        }
    }

    $newSimple = new Simple ;

?>

I get NO output or errors in the browser window. If I select "view source" it returns:
   <html><body></body><html>

Eh?  Anyone with any other ideas

Tnx

Bob Hartung

Jasper Bryant-Greene wrote:
<snip all before.


--- End Message ---
--- Begin Message ---
It wasn't what I was looking for but I enable it:
    include_path = ".:/php/includes"

This was commented out. After uncommenting it all works as I expected except that my syntax in the class was wrong. Now I can at least start to learn.

Thanks Jasper and Derek - you gave me a shove in the right direction.

Tnx

Bob



Jasper Bryant-Greene wrote:
On Sun, 2005-10-23 at 23:01 -0400, Bob Hartung wrote:

Jasper & Derek

  phpinfo() says:
        configuration file path     /etc/php.ini

  PHP Core
  Directive            Local Value           Master Value

display_errors            Off                   Off
error_log                no value              no value
log errors                on                     on

Derek's idea sends nothing to the log but does send to the browser.

It seems that /etc/php.ini is not being parsed since it says:

  error_reporting  =  E_ALL
  display_errors = On
  display_startup_errors = On
  log_errors = On


/etc/php.ini *is* being parsed, it says so right there (above). However,
display_errors isn't. Do a search inside /etc/php.ini for
display_errors, see if there's more than one declaration for it. Make
sure it isn't commented out (sounds silly, but you never know)...

Oh, and check the permissions on /etc/php.ini, just in case.


--- End Message ---
--- Begin Message ---
On Sun, October 23, 2005 5:40 am, Alan Lord wrote:
> But what benefit is there is having it as an explicitly "abstract"
> class? Why can't it just be a "normal" class definition which you
> inherit from?

It could be just a normal class...

But assume you're working on a team with a LOT of programmers, which
is where OO really shines.

Then assume some of those programmers are... less experienced... than
others.

They're not supposed to instantiate that one Class, because it doesn't
make any sense to do that, and it's bound to cause errors somewhere
else down the line.

Have an "abstract" class as a formal definition means that if you KNOW
it should never get instantiated, you have a Safety Check on it.

The compiler can error out if somebody, like our Junior Programmer,
tries to instantiate it.

If it's just a "normal" class, maybe Junior manages to make things
work (God knows how) even while instantiating a Class that was never
meant to be instantiated, and that the Expert Programmers would KNOW
was wrong.

It's just a Sanity Check, basically.

So, sure, it COULD be a normal class, if you want to assume nobody
will ever make the mistake of instantiating it...  Or it could be an
abstract class, and if somebody screws up and instantiates it, they'll
know right away and fix it before the problem goes any further.

Hope that helps.

-- 
Like Music?
http://l-i-e.com/artists.htm

--- End Message ---
--- Begin Message ---
I don't particularly care for this explanation as it makes abstract classes
out to be a mere convention of some kind during the development life-cycle.

While I can see this as a potentially convenient byproduct of the fact that
an abstract class cannot be directly instantiated, this is NOT the whole
story as they do have a much greater purpose:  They provide polymorphism and
encapsulation to class hierarchies.

Certainly you can't instantiate an abstract class, but abstract classes
exist so that the implementation details of certain methods can be deferred
to their derived classes further down the inheritance hierarchy.  Abstract
classes can also contain implementations for other non abstract methods.

Abstract classes and Interfaces can be used in combination in MANY different
patterns and frameworks.

I think that I know what you might be getting at here, but it is not true to
say it would be a class that shouldn't be instantiated as a 'sanity check'
for junior developers.  It should be used to define classes that are truly
abstract; those where it doesn't necessarily make sense to have a 'physical'
manifestation but where it would provide reusable code to its derived
classes.

An example of an abstract class might be 'Vehicle'.  Well that is too vague
(abstract) so you wouldn't really instantiate it.  Instead you'd define more
useable derived 'concrete' classes like Car, Truck, Scooter, Airplane,
Bicycle, or Skateboard.  Each of these are well defined so it makes sense
for these to non-abstract.

Each of these derived classes would then override the Vehicle's abstract
function start() for example, because each one would do this in a different
way.  But by defining 'Vehicle' as abstract and defining the abstract
function start() in it (because 'Vehicle' itself would not have an
implementation for start()), you guarantee that each derived class MUST
provide its own unique implementation for that function.

Colin

-----Original Message-----
From: Richard Lynch [mailto:[EMAIL PROTECTED] 
Sent: Sunday, October 23, 2005 11:12 PM
To: Alan Lord
Cc: 'Jasper Bryant-Greene'; [email protected]
Subject: RE: [PHP] Abstract Classes?

On Sun, October 23, 2005 5:40 am, Alan Lord wrote:
> But what benefit is there is having it as an explicitly "abstract"
> class? Why can't it just be a "normal" class definition which you
> inherit from?

It could be just a normal class...

But assume you're working on a team with a LOT of programmers, which
is where OO really shines.

Then assume some of those programmers are... less experienced... than
others.

They're not supposed to instantiate that one Class, because it doesn't
make any sense to do that, and it's bound to cause errors somewhere
else down the line.

Have an "abstract" class as a formal definition means that if you KNOW
it should never get instantiated, you have a Safety Check on it.

The compiler can error out if somebody, like our Junior Programmer,
tries to instantiate it.

If it's just a "normal" class, maybe Junior manages to make things
work (God knows how) even while instantiating a Class that was never
meant to be instantiated, and that the Expert Programmers would KNOW
was wrong.

It's just a Sanity Check, basically.

So, sure, it COULD be a normal class, if you want to assume nobody
will ever make the mistake of instantiating it...  Or it could be an
abstract class, and if somebody screws up and instantiates it, they'll
know right away and fix it before the problem goes any further.

Hope that helps.

-- 
Like Music?
http://l-i-e.com/artists.htm

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

--- End Message ---
--- Begin Message ---
Ah ha !!!

Thanks Colin, I think I'm getting it now. That makes obvious sense to
think of the abstract class as truly abstract in what it represents...

Only thing is, this where I find most of my thinking about OOP falls
down! 

I seem to be able to think of hundreds of classes which would be
"abstract" [in the true meaning of the word] and I find it quite a
struggle to come up up with useful classes that actually do represent
real world objects :-) But that's just down my own
ignorance/inexperience I think...

Thanks for all the replies to this slightly OT post.

Al


Colin Shreffler wrote:
> I don't particularly care for this explanation as it makes abstract
classes
> out to be a mere convention of some kind during the development
life-cycle.
> 
> While I can see this as a potentially convenient byproduct of the fact
that
> an abstract class cannot be directly instantiated, this is NOT the
whole
> story as they do have a much greater purpose:  They provide
polymorphism and
> encapsulation to class hierarchies.
> 
> Certainly you can't instantiate an abstract class, but abstract
classes
> exist so that the implementation details of certain methods can be
deferred
> to their derived classes further down the inheritance hierarchy.
Abstract
> classes can also contain implementations for other non abstract
methods.
> 
> Abstract classes and Interfaces can be used in combination in MANY
different
> patterns and frameworks.
> 
> I think that I know what you might be getting at here, but it is not
true to
> say it would be a class that shouldn't be instantiated as a 'sanity
check'
> for junior developers.  It should be used to define classes that are
truly
> abstract; those where it doesn't necessarily make sense to have a
'physical'
> manifestation but where it would provide reusable code to its derived
> classes.
> 
> An example of an abstract class might be 'Vehicle'.  Well that is too
vague
> (abstract) so you wouldn't really instantiate it.  Instead you'd
define more
> useable derived 'concrete' classes like Car, Truck, Scooter, Airplane,
> Bicycle, or Skateboard.  Each of these are well defined so it makes
sense
> for these to non-abstract.
> 
> Each of these derived classes would then override the Vehicle's
abstract
> function start() for example, because each one would do this in a
different
> way.  But by defining 'Vehicle' as abstract and defining the abstract
> function start() in it (because 'Vehicle' itself would not have an
> implementation for start()), you guarantee that each derived class
MUST
> provide its own unique implementation for that function.
> 
> Colin
> 
> -----Original Message-----
> From: Richard Lynch [mailto:[EMAIL PROTECTED] 
> Sent: Sunday, October 23, 2005 11:12 PM
> To: Alan Lord
> Cc: 'Jasper Bryant-Greene'; [email protected]
> Subject: RE: [PHP] Abstract Classes?
> 
> On Sun, October 23, 2005 5:40 am, Alan Lord wrote:
> 
>>But what benefit is there is having it as an explicitly "abstract"
>>class? Why can't it just be a "normal" class definition which you
>>inherit from?
> 
> 
> It could be just a normal class...
> 
> But assume you're working on a team with a LOT of programmers, which
> is where OO really shines.
> 
> Then assume some of those programmers are... less experienced... than
> others.
<snip>

--- End Message ---
--- Begin Message ---
GamblerZG schrieb:
>>But what benefit is there is having it as an explicitly "abstract"
>>class? Why can't it just be a "normal" class definition which you
>>inherit from?
> 
> The idea is that a high-level language should prohobit you from doing 
> things that do not make sence. Why they implemented it in PHP? Because 
> it's there in Java, I guess.

No, it's there because it makes sense.
If you derive from an abstract class the mechanism forces you to
implement the abstract methods. Think of this:

class Super
{
  public function check() {} //no code!
  public function huba()
  {
    /* code */
    $this->check(); // use of method
  }
}
class MyClass extends Super {}

This is what you do without having abstract classes. You put an empty
method into the class. You rely on remembering that test() has to be
filled with meaning in the subclass. You are even allowed to forget
implementing check() which might get you into trouble because the
check() is what you meant to be called for ensuring the data integrity
of the data you intend to use a few lines later.

Or worse: You leave out the method in the superclasse and only state in
the documentation that there has to be a check() method in subclasses.
This is the way to forgetting to implement all kinds of stuff.

So there is this mechanism called "abstract class":

abstract class Super
{
  abstract public function check();
  public function huba()
  {
    /* code */
    $this->check(); // use of method
  }
}
class MyClass extends Super {}

Now, you enforce several things:
- Super cannot be instantiated.
  It is not complete and PHP knows about this.
- MyClass is not complete until you implement a check().
  This way you have to actively say "I don't need a check."
  by putting an empty check() into MyClass.

Even better: You can decide to implement just some of the abstract
methods of Super. Then PHP forces you to declare your subclass as
abstract, too. This allows for partially complete class trees and it is
not up to you to remember which classes are ready to use and which are not.

No, abstract classes are not just there "because Java has them", they
exits because they help you in managing your code repository and because
they prohibit you from doing stupid things with the code.

OLLi

--- End Message ---
--- Begin Message ---
Hi,

I'm having a problem reading an xml feed. This is my object:

SimpleXMLElement Object (
        [Header] => SimpleXMLElement Object (
                [ID] => FX12GB
                [Test] => false
                [Name] => Foreign Exchange United Kingdom Pound Noon Rates
                [Prepared] => 2005-10-24
                [Sender] => SimpleXMLElement Object (
                        [Name] => Federal Reserve Bank of New York
                        [Contact] => SimpleXMLElement Object (
                                [Name] => George Matthes
                                [Email] => [EMAIL PROTECTED] ) )
                [ReportingBegin] => 1994-01-06 )
        [DataSet] => SimpleXMLElement Object (
                [Series] => SimpleXMLElement Object (
                        [Key] => SimpleXMLElement Object (
                                [FREQ] => D
                                [CURR] => GBP
                                [FX_TIME] => 12
                                [FX_TYPE] => S )
                        [Obs] => SimpleXMLElement Object (
                                [TIME_PERIOD] => 2005-10-21
                                [OBS_VALUE] => 1.7692 ) ) ) )

I'm trying to get those last two lines: TIME_PERIOD and OBS_VALUE.

I can get the ID (third line) using $s->Header->ID (where $s is my object).

$s->DataSet->Series->Obs->TIME_PERIOD;   // 'Trying to get property of
non-object'
$s->DataSet->Series->Obs['TIME_PERIOD']  // 'Trying to get property of
non-object'
$s->DataSet->Series->TIME_PERIOD         // 'Trying to get property of
non-object'
$s->DataSet->Series['TIME_PERIOD']       // No error but no data
$s->DataSet->TIME_PERIOD                 // No error but no data
$s->DataSet['TIME_PERIOD']               // No error but no data

Can anyone point me in the right direction please?

MTIA

George

--- End Message ---
--- Begin Message ---
On 10/19/05, Wiktor <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Is there a function that will convert any european special characters
> into standard ASCII letters eg. polish "ogonki" into a,e,o or german umlauts 
> into
> ue,oe...?
>

The recode functions are probably your best bet:

   http://pl.php.net/manual/pl/ref.recode.ph

 -robin

--- End Message ---
--- Begin Message --- Actually I have to run it interactively, I can get this to work with perl and the expect module (which creates a terminal and provides two handle to read from it and to write to it) I am just wondering if there is some similar moddule in PHP?


Le 18-oct.-05 à 19:19, Ben a écrit :

Olivier Cant said the following on 10/18/05 02:53:

Hi list,
I'm wondering if any one has any experience at connecting to a screen session under linux with a PHP script, and reading the pty output (and maybe writing somme stuff as well) I have an interactive program runing under screen which give me some status info, and I may also issue command to it and would like to interfce that whole thing using PHP... and screen because I can(t keep a console attached forever to it.
Any idea ?


man screen suggests you might be attempting the impossible. Does your program have to be run interactively or are there other non- interactive ways to get your status information?

- Ben

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



--- End Message ---
--- Begin Message ---
Hello again.

Is it possible to use Php, Rails and ajax via some open source system?
How do you do it?

The most important for me is to use Php and ajax.

Thanks,
Jacob

--- End Message ---
--- Begin Message ---
Hi guys,

For a reason that I don't really understand, my PHP install outputs file
in UTF-8 by default.

I would like to output files in ISO-8859-1 in certain cases. How do I do
that?

I have tried changing default_charset to iso-8859-1 with an ini_set()
call, but it doesn't help. I also looked at the doc for fopen() and
fwrite() (the functions I am using to write my file) and to the mbstring
module, but it looks like nothing is really coded to allow me to do
this.

Help! :-)

Yannick 

--- End Message ---
--- Begin Message ---
Le lundi 24 octobre 2005 à 14:37 +0100, Yannick Warnier a écrit :
> Hi guys,
> 
> For a reason that I don't really understand, my PHP install outputs file
> in UTF-8 by default.
> 
> I would like to output files in ISO-8859-1 in certain cases. How do I do
> that?
> 
> I have tried changing default_charset to iso-8859-1 with an ini_set()
> call, but it doesn't help. I also looked at the doc for fopen() and
> fwrite() (the functions I am using to write my file) and to the mbstring
> module, but it looks like nothing is really coded to allow me to do
> this.

For some reason now I could write a fully ISO-8859-1 file, so I can
guess I had been missing something. If someone has an explanation or a
document on how the files created by PHP are encoded, I would be very
glad. Thanks.

Yannick

--- End Message ---
--- Begin Message ---
hi,

i want to create a "shop server" application. the shop client interface
will be in flash (communication with php over xml, soap or amfphp), the
administration interface will be html. most likely it will probably be a
long-running application that will be extended in several steps, so we
need a solid foundation. we also need to get started quickly (who
doesn't), otherwise i would consider starting from scratch.

i have already looked around quite a lot for a nicely adaptable
shop/ecommerce implementation, but haven't been very successful so far.
everything i found was conceived in php4 times, where OO wasn't as
wide-spread in the php community as it is today. some of the packages
are poorly documented (both in-code and separate documentation), have an
inconsistent coding style, are dead, are copies of oscommerce with a
worse interface, ...

feature-wise the best i found was xtcommerce (oscommerce fork)
admin interface wise: zencart (oscommerce fork)
code-wise: randshop
non of them use php5's features, though, none are written object-oriented.

i have no info on the performance of these shops, although that
shouldn't be a prob as long as it's not desastrous (to some extend, you
can always scale hardware-wise).

so i am looking for a cleanly layered application where i could swap out
the presentation layer. and all important shop data (products, product
categories, cart, etc.) should be represented as objects, so i could
extend them to implement required customizations.
it would be a big plus if the admin interface was well thought-out.

we need quite some features like multiple languages, multiple
categories, discounts on certain products, payment provider integration,
customer newsletters, possibly administration of several slightly
different shops in one installation, etc.

is there such an application or am i stuck with oscommerce and its forks?
i don't need it to be feature complete, as long as there is a way to
adapt the code without hacking the whole thing (and loosing the
possibility of upgrading).

as long as the code was open, i would be happy to pay a certain amount
for the application.

anyone?

phil

--- End Message ---

Reply via email to