php-general Digest 5 Jan 2010 01:22:49 -0000 Issue 6521

Topics (messages 300792 through 300799):

Re: strtotime - assumptions about default formatting of dates
        300792 by: Pete Ford

Re: If design patterns are not supposed to produce reusable code then why use 
them?
        300793 by: Richard Quadling
        300794 by: Robert Cummings

Intermittent etwork connection errors with apache.  Restarting apache 
temporarily fixes the problem.  PHP or apache problem?
        300795 by: Mark London
        300797 by: Andy Shellam

Streaming OGG/MP3
        300796 by: Parham Doustdar

Howto Install XAMPP XDebug Netbeans
        300798 by: German Geek

What is the difference between the two streams 5.3 and 5.2 versions and What is 
the need for maintaining two streams?
        300799 by: Varuna Seneviratna

Administrivia:

To subscribe to the digest, e-mail:
        php-general-digest-subscr...@lists.php.net

To unsubscribe from the digest, e-mail:
        php-general-digest-unsubscr...@lists.php.net

To post to the list, e-mail:
        php-gene...@lists.php.net


----------------------------------------------------------------------
--- Begin Message ---
On 24/12/09 16:59, Bastien Koert wrote:
On Thu, Dec 24, 2009 at 9:12 AM, tedd<tedd.sperl...@gmail.com>  wrote:
At 10:20 PM +1000 12/24/09, Angus Mann wrote:

Hi all. I need to allow users to enter dates and times, and for a while
now I've been forcing them to use javascript date/time pickers so I can be
absolutely sure the formatting is correct.

Some users are requesting to be able to type the entries themselves so
I've decided to allow this.

I'm in Australia, and the standard formatting of dates here is DD/MM/YYYY
or DD-MM-YYYY

I recognize this is different to what seems to happen in the US, where it
is MM/DD/YYYY or MM-DD-YYYY

When I process an entered date using strtotime() it seems to work fine.

But of course I am concerned when dates like January 2 come up.

I find that 2/1/2009 is interpreted as January 2, 2009 on my installation,
which is Windows 7 with location set to Australia.

But can I be sure that all installations of PHP, perhaps in different
countries and on different operating systems will interpret dates the same?

I can't find much mention of this question online or in the manual.

Any help much appreciated.
Angus

Angus:

You are running into a problem that cannot be solved by allowing the user to
do whatever they want. As you realize, if I enter 01-02-09 you don't know if
I mean January 2, 2009 or February 1, 2009 and there is no way to figure out
what I meant.

The solution is simply to use the html<option>  and give the user that way
to enter month and day.

I would set it to day-month-year and let US visitors live with it for I
personally think that's a better format.

Cheers and Merry Christmas.

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



I would agree with tedd. Use a JS calendar widget (requires js) or use
three select boxes for mm , dd and year


I developed my little text input AJAX (see earlier post) to work around the fact that a LOT of users I encountered were cheesed off by JS calendar widgets, especially when the date to be entered was a long way from the current date (such as a date of birth). I tried implementing some scroll-wheel events to speed up year selection on one of these but it was tricky to get cross-browser support.

Drop-downs are a pain when you have to scroll back 40+ years to find the right one and are implicitly limited by how far back and forward the designer expects to need, and then you have the problem of validating the days and months (which, to be fair, is a pretty simple javascript task)

I suspect that with a bit of thought I could put together a Javascript date validator that parsed most possible inputs and produced a sensible interpretation of them, but I was lazy and had AJAX machinery set up already in my project.
--- End Message ---
--- Begin Message ---
2009/12/30 Tony Marston <t...@marston-home.demon.co.uk>:
> I have recently been engaged in an argument via email with someone who
> criticises my low opinion of design patterns (refer to
> http://www.tonymarston.net/php-mysql/design-patterns.html ). He says that
> design patterns are merely a convention and not a reusable component. My
> argument is that something called a pattern is supposed to have a recurring
> theme, some element of reusability, so that all subsequent implementations
> of a pattern should require less effort than the first implementation. If
> design patterns do not provide any reusable code then what is the point of
> using them?
>
>
>
> I do not use design patterns as I consider them to be the wrong level of
> abstraction. I am in the business of designing and developing entire
> applications which comprise of numerous application transactions, so I much
> prefer to use transaction patterns (refer to
> http://www.tonymarston.net/php-mysql/design-patterns-are-dead.html and
> http://www.tonymarston.net/php-mysql/transaction-patterns.html ) as these
> provide large amounts of reusable code and are therefore a significant aid
> to programmer productivity.
>
>
>
> What is your opinion? Are design patterns supposed to provide reusable code
> or not? If not, and each implementation of a pattern takes just as much time
> as the first, then where are the productivity gains from using design
> patterns?
>
>
> --
> 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
>
>

Hello Tony and everyone else (is it too late to say Happy New Year and
back to work?).

I think there seems to be a bit of a chicken and egg issue with your
comments of design patterns.

Design patterns are not blue-sky, out-of-the-box, (insert some other
marketing-speak here) concepts.

They are standardized descriptions of the purpose of code commonly seem.

They are not blocks of code to be reused.

They are nothing to do with code reuse per se.

They are to show you that the there are ways of standardizing your
approach to a problem based upon others experience. They are there to
act as templates for how you should be thinking.

Do they make you a better programmer? That depends. Do you have to
play with others? Is it easier to say we use the MVC, Active Record,
Registry and Factory Patterns? If the other members of your team do
NOT know these terms, then it is easy enough to read about them and
learn what they are for and then see how they've been implemented.
They give a common base.

Consider the alternative. I used to work on ICL System 25 running dmfx
with a 4GL style language which was converted to C before compilation
(and for the life of me I can't remember its name - it was over 20
years ago!).

The code I had to maintain was written by developers who used to write
in assembler macros. That whole argument about goto in modern
languages ... well, let's just say that THAT argument certainly didn't
exist for them.

The name that I heard for this style of coding was called "ladder
logic". No structure or common style that a newbie like me could see.

New programs were bastardised from old programs. Not cleanly, just
cobbled and a few goto's thrown in to bypass the unrequired bits. Why?
Cause only the original programmer knew what was going on and they'd
died a decade ago. Literally!

Jump forward through procedural and OOP and maybe AOP.

We all learn from the previous generation ("standing on the shoulders
of giants"). So. If they'd used design patterns back when I started
out, I'd've been able to understand the code better and faster.

I'd probably take just as long to write it, but I'd've been able to
describe it clearer and easier.

Design patterns are tools to help solve a problem. The solution MAY
involve some coding.

If you follow a design pattern, then others will be able to follow your code.

Design patterns are for community development. And probably for the
non-developer interviewers who want to see if the dweeb sat in front
of them knows his (reading from script) "Active Record" from his
(reading from script again) "Active Record" (No, sorry, just said
that, ...) "MVC" (wasn't that a chain of music shops in the UK?)...

Having said that, a real programmer only knows not to use Pascal!
Pretty much everything else is up for grabs.

Regards,

Richard.

P.S. I know nothing.

-- 
-----
Richard Quadling
"Standing on the shoulders of some very clever giants!"
EE : http://www.experts-exchange.com/M_248814.html
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
ZOPA : http://uk.zopa.com/member/RQuadling

--- End Message ---
--- Begin Message ---
Richard Quadling wrote:
2009/12/30 Tony Marston <t...@marston-home.demon.co.uk>:
I have recently been engaged in an argument via email with someone who
criticises my low opinion of design patterns (refer to
http://www.tonymarston.net/php-mysql/design-patterns.html ). He says that
design patterns are merely a convention and not a reusable component. My
argument is that something called a pattern is supposed to have a recurring
theme, some element of reusability,

Design patterns re-use the approach to solving a particular problem set. Note that I said approach, because the code may not be re-usable, but the tenets of the solution are embodied by the pattern regardless of the language used. In this way, design patterns are indeed re-usable. When you see that a particular problem falls within the domain of a Design Pattern, then the implementation is straightforward since you can use the design pattern to guide your implementation.

so that all subsequent implementations
of a pattern should require less effort than the first implementation. If
design patterns do not provide any reusable code then what is the point of
using them?

Each subsequent use of a design pattern should indeed require less effort. As you absorb fully the pattern, it becomes easier and easier to see how problems fit within one pattern or another or multiple patterns. Having at that point already implemented solutions using design patterns, it should become easier each time you create a solution using a previously used design pattern.

I do not use design patterns as I consider them to be the wrong level of
abstraction. I am in the business of designing and developing entire
applications which comprise of numerous application transactions, so I much
prefer to use transaction patterns (refer to
http://www.tonymarston.net/php-mysql/design-patterns-are-dead.html and
http://www.tonymarston.net/php-mysql/transaction-patterns.html ) as these
provide large amounts of reusable code and are therefore a significant aid
to programmer productivity.

What is your opinion? Are design patterns supposed to provide reusable code
or not? If not, and each implementation of a pattern takes just as much time
as the first, then where are the productivity gains from using design
patterns?

If I ask you to classify bugs by genus, does it not become easier and easier to classify any given bug based on your previous experience of knowing what constitutes membership in a particular genus? The same is true of design patterns.

Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP

--- End Message ---
--- Begin Message --- Hi - At the top of my php scripts, I have code to connect to our ldap server, in order for the scripts to make ldap requests. I don't have any disconnect call in my code. Lately I have noticed that the apache server will get into a state where connection requests will occasionally fail. When I refresh the page, the connection almost always succeeds on the 2nd attempt. If I restart the apache server, the problem totally goes away for a long period of time. So I assume that somewhere, something is causing connections to stay opened when the script ends, rather than automatically closing them.

This error occurs with other types of network connections that the script makes (besides ldap), so it's not an ldap issue.

How does Apache automatically close connections when the script ends? Is it possible that connections are being left opened? Is there any way to debug the problem, i.e. to see if connections are left opened in some way?

I'm running redhat 5, httpd-2.2.3-31.el5_4.2 php-5.1.6-23.2.el5_3

Thanks. - Mark


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


> I don't have any disconnect call in my code.  

Is this the same for all your connections code, apart from your LDAP?  It's 
good practice to never assume that PHP will disconnect connections for you - 
explicitly call the disconnect function when your connection is done with.

> Lately I have noticed that the apache server will get into a state where 
> connection requests will occasionally fail.  When I refresh the page, the 
> connection almost always succeeds on the 2nd attempt.   If I restart the 
> apache server, the problem totally goes away for a long period of time.   

Are you talking about the connection to Apache or the connection from your 
Apache server to your other servers?

> So I assume that somewhere, something is causing connections to stay opened 
> when the script ends, rather than automatically closing them.

As I said above, always explicitly disconnect from any services you connect to 
when you're finished.

> 
> This error occurs with other types of network connections that the script 
> makes (besides ldap), so it's not an ldap issue.
> 
> How does Apache automatically close connections when the script ends?  Is it 
> possible that connections are being left opened?  Is there any way to debug 
> the problem, i.e. to see if connections are left opened in some way?

Run "netstat -an|grep tcp" on the server's console before and after a page 
request - if possible prevent all other connections to your Apache server while 
you do it.

Connections that remain open will be in the state "ESTABLISHED" - server 
processes (e.g. Apache) will be listed as "LISTEN."

If you get an LDAP connection after your page request that wasn't there before 
in the ESTABLISHED state, PHP isn't disconnecting.

If any connections are listed as TIME_WAIT, it means the connection was dropped 
without the client disconnecting properly - it may be worth running netstat on 
your LDAP server as well.

Regards,
Andy

--- End Message ---
--- Begin Message ---
Hello there,
I wonder how I can stream MP3/OGG files with PHP? I'm running UniServer on a Windows machine, if that helps.
--- End Message ---
--- Begin Message ---
Hi All,

Just to save some of you some time:

http://www.ihostnz.com/howto-install-xampp-windows-7-xdebug-netbeans

Happy new year!

Cheers,
Tim
++Tim Hinnerk Heuer++

http://www.ihostnz.com

--- End Message ---
--- Begin Message ---
Since there are two stable versions 5.3 and 5.2 .What is the difference
between these two streams and What is the need for maintaining two streams?

--- End Message ---

Reply via email to