Re: [PHP] Re: strtotime

[gilles]

"Lester Caine" <[EMAIL PROTECTED]> a écrit dans le message de news: 
[EMAIL PROTECTED]
> Ashley Sheridan wrote:
 I'll translate

 In PHP4, strtotime works fine

 in PHP5 strtotime gives a result of 19700101 when the data entered was
 strtotime("20080950")


>>> What does "work fine" mean?  "20080950" isn't normal, so what is the
>>> expected result?
>
>> Well, for starts Micah is right, your date string will be interpreted as
>> the 50th of September, 2008, which isn't valid and defaults to the time
>> represented by the timestamp 0. If you want to turn 8-digit number
>> strings into timestamps, make sure of two things:
>>
>> 1.It's actually a string and not a number
>> 2.The string is in the format mmdd
>>
>> The strings can be a variety of formats, all found at
>> http://www.gnu.org/software/shishi/manual/html_node/Date-input-formats.html 
>> which is a link available on the strtotime manual page.
>
> I seem to remember a previous discussion about this 'bug' but I can't 
> track the notes. Is it not the case that you can simply add days or months 
> to the 'number' and then use strtotime to output the 'normalised' date. So 
> adding 30 to 20th Sept would return 20th October. This very useful feature 
> was corrected as a bug in the rewrite of Date in PHP5.1?
> Reason for looking for the notes was to remember how one has to do it now 
> 
>
> -- 
> Lester Caine - G8HFL
Thanks everybody for your answer. Yes, this is a very useful feature to add 
days in a date.
My version of PHP is 5.2.0
Fx GILLES 



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

Re: [PHP] Re: strtotime

[Thodoris]

O/H Bastien Koert ??:

2008/11/8 Maciek Sokolewicz <[EMAIL PROTECTED]>

  

gilles wrote:



Avec la version 4 de php, strtotime("20080950") fonctionne correctement en
allant sur le mois d'octobre, alors qu'en version 5: 19700101.
Merci de votre aide


  

This is an ENGLISH list, please rephrase your question in english and
people might understand.

Cette liste est une liste anglaise, reformulent svp votre question en
anglais svp.

merci,

- Tul


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




I'll translate

In PHP4, strtotime works fine
  


Define "works  fine".


in PHP5 strtotime gives a result of 19700101 when the data entered was
strtotime("20080950")

  


Linux
PHP version 5.1.6
Apache 2

This strtotime("20080950") returns nothing.

---
Thodoris

[PHP] Re: Secure redirection?

[Martin Zvarík]

I might have not read your post thorougly,
but it's important to know, that Header sends a HTTP request to the 
browser - you are not hiding the destination URL.


So, calling header("location: in PHP is basically same as redirect using JS.

Martin


Zoran Bogdanov napsal(a):

Hi,

I'm building a login system with AJAX/PHP/MySQL.

I have worked everything out... AJAX is sending request to a php login 
script (login.php) who if authentication passes initializes the session and 
sends the header using header("Location : registered_user_area.php");


The whole system works great without AJAX, but when I put AJAX in the story 
I ahve one problem:


1.When the user is successfully authenticated the login.php sends the 
header, but the AJAX XMLHttpRequest call is still in progress waiting for a 
PHP response. So when PHP using the header function redirects to another 
page that page is outputed to the login form...


My PHP login snippet is:
if ($res_hash == $u_pass) {

$logged_user = $sql_execution->last_query_result->user;

$sql_execution->exec_query("DELETE FROM seeds",false);

$sql_execution->db_disconnect();

session_start();

$_SESSION['user'] = $logged_user;

$host = $_SERVER['HTTP_HOST'];

$url = rtrim(dirname($_SERVER['PHP_SELF']), '/\\') . '/mpls/index.php';

header("Location: http://$host$url";);//--That page 
($host$url) is outputed in the login form...


exit();

}

else {

$sql_execution->exec_query("DELETE FROM seeds WHERE id=$row->id",false);

$sql_execution->db_disconnect();

echo 'BLS';//--This is sent when the password/username is 
wrong


exit();

}

???

Any help greatly appreciated

Thank you!




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

Re: [PHP] question about google maps

[Kevin Waterson]

This one time, at band camp, Sudhakar <[EMAIL PROTECTED]> wrote:

> hi
> 
> how do i go about displaying an address which appears on google maps for a
> business on a web page.
> 
> what are the steps.
> 
> if some one knows about this please let me know.

http://www.phpro.org/classes/Phproogle.html

and some docs at

http://www.phpro.org/classes/Phproogle-Docs.html

example code can be found at
http://www.phpro.org/examples/Google-Maps-With-PHP-And-Phproogle.html


Kevin


-- 
This email message (and any accompanying file attachments) may contain 
confidential or privileged information and is intended for the sole use of the 
addressee(s) named above. If you are not the intended recipient, or the person 
responsible for delivering this message to the intended recipient, please 
notify [EMAIL PROTECTED] immediately and destroy any copies of the original 
message.


Any unauthorised review, use, alteration, disclosure or distribution of this 
email (including any attachments) is prohibited.

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

Re: [PHP] It's Sunday, and I'm bored...

[Richard Heyes]

> Commit Early Commit Often. :P

That's for wimps... :-)

-- 
Richard Heyes

HTML5 Graphing for FF, Chrome, Opera and Safari:
http://www.rgraph.org (Updated November 1st)

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

[PHP] It's Sunday, and I'm bored...

[Richard Heyes]

Hi,

I just looked at my commit diff that I need to check - 1500 lines (!).
Uhhh... Maybe that policy of committing frequently wouldn't be so
terrible after all...

-- 
Richard Heyes

HTML5 Graphing for FF, Chrome, Opera and Safari:
http://www.rgraph.org (Updated November 1st)

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

Re: [PHP] It's Sunday, and I'm bored...

[Rene Veerman]

Richard Heyes wrote:

Commit Early Commit Often. :P



That's for wimps... :-)

  

and people who hate spending much time retyping last week's work...

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

Re: [PHP] question about google maps

[Richard Heyes]

> You are trapped on a desert island with the Baldwin Brothers.
> The food and rum have run out and you have a gun with a
> single bullet. Who do you shoot?

Line them all up and shoot them in a oner... ;-)

-- 
Richard Heyes

HTML5 Graphing for FF, Chrome, Opera and Safari:
http://www.rgraph.org (Updated November 1st)

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

Re: [PHP] It's Sunday, and I'm bored...

[Ólafur Waage]

Commit Early Commit Often. :P

On Sun, Nov 9, 2008 at 11:03 AM, Richard Heyes <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I just looked at my commit diff that I need to check - 1500 lines (!).
> Uhhh... Maybe that policy of committing frequently wouldn't be so
> terrible after all...
>
> --
> Richard Heyes
>
> HTML5 Graphing for FF, Chrome, Opera and Safari:
> http://www.rgraph.org (Updated November 1st)
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

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

Re: [PHP] It's Sunday, and I'm bored...

[Richard Heyes]

> and people who hate spending much time retyping last week's work...

I don't have to retype it. Just describe it. Just.

-- 
Richard Heyes

HTML5 Graphing for FF, Chrome, Opera and Safari:
http://www.rgraph.org (Updated November 1st)

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

Re: [PHP] It's Sunday, and I'm bored...

[Robert Cummings]

On Sun, 2008-11-09 at 14:29 +, Richard Heyes wrote:
> > and people who hate spending much time retyping last week's work...
> 
> I don't have to retype it. Just describe it. Just.

Well that's easy...

Description: changes from previous week.

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


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

Re: [PHP] It's Sunday, and I'm bored...

[Daniel P. Brown]

On Sun, Nov 9, 2008 at 11:00 AM, Robert Cummings <[EMAIL PROTECTED]> wrote:
>
> Description: changes from previous week.

+1.

-- 

http://www.parasane.net/
[EMAIL PROTECTED] || [EMAIL PROTECTED]
Ask me about our current hosting/dedicated server deals!

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

RE: [PHP] It's Sunday, and I'm bored...

[Robert Cummings]

Maybe he's a psychiatrist.



On Sun, 2008-11-09 at 12:44 -0500, Wolf wrote:
> Ni, he works for ACORN...
> 
> Oh wait, that would have vote early, vote often...
> 
> -Original Message-
> From: Jay Blanchard <[EMAIL PROTECTED]>
> Sent: Sunday, November 09, 2008 12:33 PM
> To: Ólafur Waage <[EMAIL PROTECTED]>; php-general@lists.php.net
> Subject: RE: [PHP] It's Sunday, and I'm bored...
> 
> [snip]
> Commit Early Commit Often. :P
> [/snip]
> 
> Are you from Louisiana? 
> 
> -- 
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
> 
> 
> 
-- 
http://www.interjinn.com
Application and Templating Framework for PHP


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

Re: [PHP] It's Sunday, and I'm bored...

[Richard Heyes]

> Well that's easy...
>
> Description: changes from previous week.

Lol. I actually do do that and put the changes in another file.


-- 
Richard Heyes

HTML5 Graphing for FF, Chrome, Opera and Safari:
http://www.rgraph.org (Updated November 1st)

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

Re: [PHP] It's Sunday, and I'm bored...

[Richard Heyes]

> What are you guys all referring to?
> My best guess is some version control software that regulars here seem to
> all know about.

Subversion, or svn for short. Helps you maintain code bases. Far
better than regular backups (though by no means a replacement).

> It's nice to have at least loose communities like this list so we solo
> freelancers don't think we're simply mad.

You are... :-)

-- 
Richard Heyes

HTML5 Graphing for FF, Chrome, Opera and Safari:
http://www.rgraph.org (Updated November 1st)

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

RE: [PHP] PHP - Web/list Question...

[bruce]

h

if one uses sessions, or a db store, the underlying logic to get the input
vars from the form on the individual pages (for the list) will essentially
be the same.

i'll have to have a form element, with the input items. i'll need to process
the checkboxes for each item, and when the user selects the
"continue/submit" btn, i'll perform the get/post action which then
accumulates the items from the previous page...

for each page, i'll have to process logic for the items listed in the form,
to see if the user has changed his/her mind... (ie, when the user goes back
to a previous page.)

when the user submits the "continue" btn, it'll present a list of the
selected items, allowing the user to revise the list, by going back to the
original lists (via the "back" btn) items can be deleted, via a delete
checkbox for each item in the list...

checking a "submit" btn will then write the final data to the db storage...


page 1,2,...:

  previous  - next
  state cityhospital   checkbox

  continue

the "continue" page

 -provides the list of the user selected items

  state cityhospital   checkbox

  revise - finish

on the "continue" page, the the user can "uncheck" the checkbox, to remove
an item, or the user can "add" additional items, by selecting the "revise"
btn, which goes back to the initial pages/list..



thoughts/comments



-Original Message-
From: Robert Cummings [mailto:[EMAIL PROTECTED]
Sent: Sunday, November 09, 2008 10:49 AM
To: Micah Gersten
Cc: Stut; bruce; php-general@lists.php.net
Subject: Re: [PHP] PHP - Web/list Question...


On Sun, 2008-11-09 at 12:39 -0600, Micah Gersten wrote:
> Robert Cummings wrote:
> > On Sun, 2008-11-09 at 12:26 -0600, Micah Gersten wrote:
> >
> >> Stut wrote:
> >>
> >>> On 9 Nov 2008, at 18:14, Robert Cummings wrote:
> >>>
>  On Sun, 2008-11-09 at 18:00 +, Stut wrote:
> 
> > On 9 Nov 2008, at 07:16, Robert Cummings wrote:
> >
> >> On Sat, 2008-11-08 at 20:26 -0800, bruce wrote:
> >>
> >>> I've got a question/issue that I want to bounce off the list.
> >>>
> >>> I have a list that extends over multiple pages. there might be 200
> >>> items,
> >>> and i don't want to have the items listed on the same page as it
> >>> would be
> >>> too long. i can break the list up, so i can have it be displayed
over
> >>> multiple pages. however, i want the user to select different items
> >>> from the
> >>> list. given that the selected items might be over different pages,
> >>> what's
> >>> the best way of keeping a running track of the items that have
been
> >>> selected??
> >>>
> >>> I could have each page be a form, and do a post/get where i then
> >>> keep track
> >>> of the selected items from page to page, but that would appear to
> >>> get ugly.
> >>> i'm looking for pointers to other sites/code that might have
already
> >>> implemented this kind of scenario.
> >>>
> >>> thoughts/pointers would be appreciated...
> >>>
> >> Accumulate them in the session. When done, and before final action
you
> >> could let them view a summary of selected items and allow deletion
of
> >> any entries they don't want.
> >>
> > Unless they're likely to select hundreds of items I'd either go with
a
> > persisted GET var or a cookie. No need to drag server-side storage
> > into this.
> >
>  Well he did say he had multiple pages. Maybe he's only displaying 5
per
>  page though. Still, sessions are easier to manage than GET vars since
>  you don't need to append them to every form action URL to accumulate
>  them. Session is managed transparently by PHP in most cases an
amounts
>  to the approximate overhead of an include.
> 
> >>> Seriously? You'd rather use sessions than explode, modify and implode
> >>> an array of numbers on each request? You really see that as a valuable
> >>> developer time-saver?
> >>>
> >>> The mind boggles, but as I've said before and probably will again it's
> >>> always a personal choice, I'm just suggesting alternatives.
> >>>
> >>> -Stut
> >>>
> >>>
> >> Also, by storing the information server side, there is less of a chance
> >> of the user tampering with the data.  Storing stuff in the session also
> >> saves on network bandwidth of sending and retrieving the data with each
> >> request.
> >>
> >
> > Nah, the problem is the same. Tamper with the GET data or tamper with
> > the POST date before it goes into the session. Need to check the
> > incoming data regardless.
> >
> > Cheers,
> > Rob.
> >
>
> Yes, but once it's in the session, it should be ok.

True, but the same possibility of tampering existed with the POST data.
Therefore the chance of tampering is the same.

Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framew

Re: [PHP] PHP - Web/list Question...

[Thodoris]

O/H Robert Cummings ??:

On Sun, 2008-11-09 at 12:39 -0600, Micah Gersten wrote:
  

Robert Cummings wrote:


On Sun, 2008-11-09 at 12:26 -0600, Micah Gersten wrote:
  
  

Stut wrote:



On 9 Nov 2008, at 18:14, Robert Cummings wrote:
  
  

On Sun, 2008-11-09 at 18:00 +, Stut wrote:



On 9 Nov 2008, at 07:16, Robert Cummings wrote:
  
  

On Sat, 2008-11-08 at 20:26 -0800, bruce wrote:



I've got a question/issue that I want to bounce off the list.

I have a list that extends over multiple pages. there might be 200
items,
and i don't want to have the items listed on the same page as it
would be
too long. i can break the list up, so i can have it be displayed over
multiple pages. however, i want the user to select different items
from the
list. given that the selected items might be over different pages,
what's
the best way of keeping a running track of the items that have been
selected??

I could have each page be a form, and do a post/get where i then
keep track
of the selected items from page to page, but that would appear to
get ugly.
i'm looking for pointers to other sites/code that might have already
implemented this kind of scenario.

thoughts/pointers would be appreciated...
  
  

Accumulate them in the session. When done, and before final action you
could let them view a summary of selected items and allow deletion of
any entries they don't want.



Unless they're likely to select hundreds of items I'd either go with a
persisted GET var or a cookie. No need to drag server-side storage
into this.
  
  

Well he did say he had multiple pages. Maybe he's only displaying 5 per
page though. Still, sessions are easier to manage than GET vars since
you don't need to append them to every form action URL to accumulate
them. Session is managed transparently by PHP in most cases an amounts
to the approximate overhead of an include.



Seriously? You'd rather use sessions than explode, modify and implode
an array of numbers on each request? You really see that as a valuable
developer time-saver?

The mind boggles, but as I've said before and probably will again it's
always a personal choice, I'm just suggesting alternatives.

-Stut

  
  

Also, by storing the information server side, there is less of a chance
of the user tampering with the data.  Storing stuff in the session also
saves on network bandwidth of sending and retrieving the data with each
request.



Nah, the problem is the same. Tamper with the GET data or tamper with
the POST date before it goes into the session. Need to check the
incoming data regardless.

Cheers,
Rob.
  
  

Yes, but once it's in the session, it should be ok.



True, but the same possibility of tampering existed with the POST data.
Therefore the chance of tampering is the same.

Cheers,
Rob.
  


Not true because if the data are stored in the cookie every time that 
the cookie is accessed the data are passing from the client to the 
server. This adds further network traffic and gives the client the 
chance to interfere with the cookie's data. So I think that the server 
side storage (sessions) is safer because you check once, then store and 
use as needed.


On the other hand sessions give bigger load to the web server.So  
another solution could be to encrypt the cookie's data if that is the 
way that suits you better in order to make things more secure...



Thodoris

Re: [PHP] PHP - Web/list Question...

[Robert Cummings]

On Sun, 2008-11-09 at 22:08 +0200, Thodoris wrote:
> O/H Robert Cummings έγραψε: 
> > On Sun, 2008-11-09 at 12:39 -0600, Micah Gersten wrote:
> >   
> > > Robert Cummings wrote:
> > > 
> > > > On Sun, 2008-11-09 at 12:26 -0600, Micah Gersten wrote:
> > > > > >   
> > > > > Also, by storing the information server side, there is less of
> > > > > a chance
> > > > > of the user tampering with the data.  Storing stuff in the
> > > > > session also
> > > > > saves on network bandwidth of sending and retrieving the data
> > > > > with each
> > > > > request.
> > > > > 
> > > > > 
> > > > Nah, the problem is the same. Tamper with the GET data or tamper
> > > > with
> > > > the POST date before it goes into the session. Need to check the
> > > > incoming data regardless.
> > > > 
> > > > Cheers,
> > > > Rob.
> > > >   
> > > >   
> > > Yes, but once it's in the session, it should be ok.
> > > 
> > 
> > True, but the same possibility of tampering existed with the POST
> > data.
> > Therefore the chance of tampering is the same.
> > 
> > Cheers,
> > Rob.
> >   
> 
> Not true because if the data are stored in the cookie every time that
> the cookie is accessed the data are passing from the client to the
> server. This adds further network traffic and gives the client the
> chance to interfere with the cookie's data. So I think that the server
> side storage (sessions) is safer because you check once, then store
> and use as needed.
> 
> On the other hand sessions give bigger load to the web server.So
> another solution could be to encrypt the cookie's data if that is the
> way that suits you better in order to make things more secure...

You have to check any newly checked posts anyways. So the security
implications are the same. Loop over all received IDs and ensure
integrity. With the GET system you just reloop over the previously
submitted IDs. The result while not equivalent with respect to CPU time,
is certainly equivalent with respect to checking security.

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


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

Re: [PHP] PHP - Web/list Question...

[Robert Cummings]

On Sun, 2008-11-09 at 20:16 +, Stut wrote:
> On 9 Nov 2008, at 18:37, Robert Cummings wrote:
> > On Sun, 2008-11-09 at 18:22 +, Stut wrote:
> >> On 9 Nov 2008, at 18:14, Robert Cummings wrote:
> >>> On Sun, 2008-11-09 at 18:00 +, Stut wrote:
>  On 9 Nov 2008, at 07:16, Robert Cummings wrote:
> > On Sat, 2008-11-08 at 20:26 -0800, bruce wrote:
> >> I've got a question/issue that I want to bounce off the list.
> >>
> >> I have a list that extends over multiple pages. there might be  
> >> 200
> >> items,
> >> and i don't want to have the items listed on the same page as it
> >> would be
> >> too long. i can break the list up, so i can have it be displayed
> >> over
> >> multiple pages. however, i want the user to select different  
> >> items
> >> from the
> >> list. given that the selected items might be over different  
> >> pages,
> >> what's
> >> the best way of keeping a running track of the items that have  
> >> been
> >> selected??
> >>
> >> I could have each page be a form, and do a post/get where i then
> >> keep track
> >> of the selected items from page to page, but that would appear to
> >> get ugly.
> >> i'm looking for pointers to other sites/code that might have
> >> already
> >> implemented this kind of scenario.
> >>
> >> thoughts/pointers would be appreciated...
> >
> > Accumulate them in the session. When done, and before final action
> > you
> > could let them view a summary of selected items and allow deletion
> > of
> > any entries they don't want.
> 
>  Unless they're likely to select hundreds of items I'd either go
>  with a
>  persisted GET var or a cookie. No need to drag server-side storage
>  into this.
> >>>
> >>> Well he did say he had multiple pages. Maybe he's only displaying 5
> >>> per
> >>> page though. Still, sessions are easier to manage than GET vars  
> >>> since
> >>> you don't need to append them to every form action URL to accumulate
> >>> them. Session is managed transparently by PHP in most cases an  
> >>> amounts
> >>> to the approximate overhead of an include.
> >>
> >>
> >> Seriously? You'd rather use sessions than explode, modify and implode
> >> an array of numbers on each request? You really see that as a  
> >> valuable
> >> developer time-saver?
> >>
> >> The mind boggles, but as I've said before and probably will again  
> >> it's
> >> always a personal choice, I'm just suggesting alternatives.
> >
> > Depends on the situation really. I'd really not restrict myself in an
> > environment where there is sufficient possibility for which X numbers
> > whose cumulative digits could easily break the 1024 byte lower bound  
> > for
> > GET requests. How many digits are these IDs? How man can be chosen?  
> > It's
> > not unreasonable to select pages of some kind of item. It would only
> > take 200 averaging 5 digits to break the limit. The solution here is
> > simple in both respects, and using sessions really doesn't strike me  
> > as
> > using a sledgehammer.
> 
> I don't disagree, I was just pointing out that sessions as implemented  
> by PHP are not the only answer to data storage between requests and in  
> a lot of cases are overkill. It's a decision you have to base on the  
> requirements and expected future developments of a project.
> 
> I firmly believe the advice given on this list should provide choices  
> rather than dictate methods. There's always more than one way to do  
> something.

I absolutely agree, I certainly don't think what you proposed is in any
way wrong, but *my* preference for this particular problem would
probably be to use the session. I avoid the session as much as possible
since then you can't provide a link to someone via email to bring up the
same context as you had, but in this case that seems an unlikely
scenario, whereas the possibility of accumulating many items is quite
likely given the items will be paged.

Taking further context though on my stream of responses... you did say:

Seriously? You'd rather use sessions than explode, modify and
implode an array of numbers on each request?

This suggests you thought my particular opinion to be ludicrous ;) As
such, I felt inclined to more strongly defend my stance.

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


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

RE: [PHP] PHP - Web/list Question...

[bruce]

h

if one uses sessions, or a db store, the underlying logic to get the input
vars from the form on the individual pages (for the list) will essentially
be the same.

i'll have to have a form element, with the input items. i'll need to process
the checkboxes for each item, and when the user selects the
"continue/submit" btn, i'll perform the get/post action which then
accumulates the items from the previous page...

for each page, i'll have to process logic for the items listed in the form,
to see if the user has changed his/her mind... (ie, when the user goes back
to a previous page.)

when the user submits the "continue" btn, it'll present a list of the
selected items, allowing the user to revise the list, by going back to the
original lists (via the "back" btn) items can be deleted, via a delete
checkbox for each item in the list...

checking a "submit" btn will then write the final data to the db storage...


page 1,2,...:

  previous  - next
  state cityhospital   checkbox

  continue

the "continue" page

 -provides the list of the user selected items

  state cityhospital   checkbox

  revise - finish

on the "continue" page, the the user can "uncheck" the checkbox, to remove
an item, or the user can "add" additional items, by selecting the "revise"
btn, which goes back to the initial pages/list..



thoughts/comments



-Original Message-
From: Robert Cummings [mailto:[EMAIL PROTECTED]
Sent: Sunday, November 09, 2008 10:49 AM
To: Micah Gersten
Cc: Stut; bruce; php-general@lists.php.net
Subject: Re: [PHP] PHP - Web/list Question...


On Sun, 2008-11-09 at 12:39 -0600, Micah Gersten wrote:
> Robert Cummings wrote:
> > On Sun, 2008-11-09 at 12:26 -0600, Micah Gersten wrote:
> >
> >> Stut wrote:
> >>
> >>> On 9 Nov 2008, at 18:14, Robert Cummings wrote:
> >>>
>  On Sun, 2008-11-09 at 18:00 +, Stut wrote:
> 
> > On 9 Nov 2008, at 07:16, Robert Cummings wrote:
> >
> >> On Sat, 2008-11-08 at 20:26 -0800, bruce wrote:
> >>
> >>> I've got a question/issue that I want to bounce off the list.
> >>>
> >>> I have a list that extends over multiple pages. there might be 200
> >>> items,
> >>> and i don't want to have the items listed on the same page as it
> >>> would be
> >>> too long. i can break the list up, so i can have it be displayed
over
> >>> multiple pages. however, i want the user to select different items
> >>> from the
> >>> list. given that the selected items might be over different pages,
> >>> what's
> >>> the best way of keeping a running track of the items that have
been
> >>> selected??
> >>>
> >>> I could have each page be a form, and do a post/get where i then
> >>> keep track
> >>> of the selected items from page to page, but that would appear to
> >>> get ugly.
> >>> i'm looking for pointers to other sites/code that might have
already
> >>> implemented this kind of scenario.
> >>>
> >>> thoughts/pointers would be appreciated...
> >>>
> >> Accumulate them in the session. When done, and before final action
you
> >> could let them view a summary of selected items and allow deletion
of
> >> any entries they don't want.
> >>
> > Unless they're likely to select hundreds of items I'd either go with
a
> > persisted GET var or a cookie. No need to drag server-side storage
> > into this.
> >
>  Well he did say he had multiple pages. Maybe he's only displaying 5
per
>  page though. Still, sessions are easier to manage than GET vars since
>  you don't need to append them to every form action URL to accumulate
>  them. Session is managed transparently by PHP in most cases an
amounts
>  to the approximate overhead of an include.
> 
> >>> Seriously? You'd rather use sessions than explode, modify and implode
> >>> an array of numbers on each request? You really see that as a valuable
> >>> developer time-saver?
> >>>
> >>> The mind boggles, but as I've said before and probably will again it's
> >>> always a personal choice, I'm just suggesting alternatives.
> >>>
> >>> -Stut
> >>>
> >>>
> >> Also, by storing the information server side, there is less of a chance
> >> of the user tampering with the data.  Storing stuff in the session also
> >> saves on network bandwidth of sending and retrieving the data with each
> >> request.
> >>
> >
> > Nah, the problem is the same. Tamper with the GET data or tamper with
> > the POST date before it goes into the session. Need to check the
> > incoming data regardless.
> >
> > Cheers,
> > Rob.
> >
>
> Yes, but once it's in the session, it should be ok.

True, but the same possibility of tampering existed with the POST data.
Therefore the chance of tampering is the same.

Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framew

Re: [PHP] Re: strtotime

[Thodoris]

O/H gilles έγραψε:
"Thodoris" <[EMAIL PROTECTED]> a ιcrit dans le message de news: 
[EMAIL PROTECTED]
  

O/H Bastien Koert ??:


2008/11/8 Maciek Sokolewicz <[EMAIL PROTECTED]>


  

gilles wrote:



Avec la version 4 de php, strtotime("20080950") fonctionne correctement 
en

allant sur le mois d'octobre, alors qu'en version 5: 19700101.
Merci de votre aide



  

This is an ENGLISH list, please rephrase your question in english and
people might understand.

Cette liste est une liste anglaise, reformulent svp votre question en
anglais svp.

merci,

- Tul


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





I'll translate

In PHP4, strtotime works fine

  

Define "works  fine".



in PHP5 strtotime gives a result of 19700101 when the data entered was
strtotime("20080950")


  

Linux
PHP version 5.1.6
Apache 2

This strtotime("20080950") returns nothing.

---
Thodoris

"Works fine" in php4 means date("d/m/Y",strtotime("20080950")) returns 
20/10/2008, which is correct.
Thanks 




  


In another server this:

";
print $tstamp;
?>

gives me:
01/01/1970

Funny isn't it? I gives me the epoch start date. Probably because 
strtotime returns null so date thinks that null is equivalent to 0 or 
something like that AFAIK.


Nevertheless this 20080950 is not a valid date so this behavior makes 
more sense to me than getting 20/10/2008 as a result. So any invalid 
date will probably give you 01/01/1970.

Re: [PHP] Re: strtotime

[Ashley Sheridan]

On Sun, 2008-11-09 at 19:46 +0100, gilles wrote:
> "Thodoris" <[EMAIL PROTECTED]> a crit dans le message de news: 
> [EMAIL PROTECTED]
> > O/H Bastien Koert ??:
> >> 2008/11/8 Maciek Sokolewicz <[EMAIL PROTECTED]>
> >>
> >>
> >>> gilles wrote:
> >>>
> >>>
>  Avec la version 4 de php, strtotime("20080950") fonctionne correctement 
>  en
>  allant sur le mois d'octobre, alors qu'en version 5: 19700101.
>  Merci de votre aide
> 
> 
> 
> >>> This is an ENGLISH list, please rephrase your question in english and
> >>> people might understand.
> >>>
> >>> Cette liste est une liste anglaise, reformulent svp votre question en
> >>> anglais svp.
> >>>
> >>> merci,
> >>>
> >>> - Tul
> >>>
> >>>
> >>> --
> >>> PHP General Mailing List (http://www.php.net/)
> >>> To unsubscribe, visit: http://www.php.net/unsub.php
> >>>
> >>>
> >>>
> >> I'll translate
> >>
> >> In PHP4, strtotime works fine
> >>
> >
> > Define "works  fine".
> >
> >> in PHP5 strtotime gives a result of 19700101 when the data entered was
> >> strtotime("20080950")
> >>
> >>
> >
> > Linux
> > PHP version 5.1.6
> > Apache 2
> >
> > This strtotime("20080950") returns nothing.
> >
> > ---
> > Thodoris
> "Works fine" in php4 means date("d/m/Y",strtotime("20080950")) returns 
> 20/10/2008, which is correct.
> Thanks 
> 
> 
> 
Which is actually incorrect (I've never seen the 50th of September) and
it was fixed in PHP 5. What you are assuming is correct behaviour is
actually a bug.


Ash
www.ashleysheridan.co.uk


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

Re: [PHP] PHP - Web/list Question...

[Micah Gersten]

Stut wrote:
> On 9 Nov 2008, at 07:16, Robert Cummings wrote:
>> On Sat, 2008-11-08 at 20:26 -0800, bruce wrote:
>>> I've got a question/issue that I want to bounce off the list.
>>>
>>> I have a list that extends over multiple pages. there might be 200
>>> items,
>>> and i don't want to have the items listed on the same page as it
>>> would be
>>> too long. i can break the list up, so i can have it be displayed over
>>> multiple pages. however, i want the user to select different items
>>> from the
>>> list. given that the selected items might be over different pages,
>>> what's
>>> the best way of keeping a running track of the items that have been
>>> selected??
>>>
>>> I could have each page be a form, and do a post/get where i then
>>> keep track
>>> of the selected items from page to page, but that would appear to
>>> get ugly.
>>> i'm looking for pointers to other sites/code that might have already
>>> implemented this kind of scenario.
>>>
>>> thoughts/pointers would be appreciated...
>>
>> Accumulate them in the session. When done, and before final action you
>> could let them view a summary of selected items and allow deletion of
>> any entries they don't want.
>
> Unless they're likely to select hundreds of items I'd either go with a
> persisted GET var or a cookie. No need to drag server-side storage
> into this.
>
> -Stut

Server side storage is meant to be used.  The session was one of the
greatest things that PHP has given to the web programming world.  It
should not be feared.  Also, why clutter up someone's machine with stuff
held in a cookie?

Thank you,
Micah Gersten
onShore Networks
Internal Developer
http://www.onshore.com



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

Re: [PHP] PHP - Web/list Question...

[Micah Gersten]

Stut wrote:
> On 9 Nov 2008, at 18:14, Robert Cummings wrote:
>> On Sun, 2008-11-09 at 18:00 +, Stut wrote:
>>> On 9 Nov 2008, at 07:16, Robert Cummings wrote:
 On Sat, 2008-11-08 at 20:26 -0800, bruce wrote:
> I've got a question/issue that I want to bounce off the list.
>
> I have a list that extends over multiple pages. there might be 200
> items,
> and i don't want to have the items listed on the same page as it
> would be
> too long. i can break the list up, so i can have it be displayed over
> multiple pages. however, i want the user to select different items
> from the
> list. given that the selected items might be over different pages,
> what's
> the best way of keeping a running track of the items that have been
> selected??
>
> I could have each page be a form, and do a post/get where i then
> keep track
> of the selected items from page to page, but that would appear to
> get ugly.
> i'm looking for pointers to other sites/code that might have already
> implemented this kind of scenario.
>
> thoughts/pointers would be appreciated...

 Accumulate them in the session. When done, and before final action you
 could let them view a summary of selected items and allow deletion of
 any entries they don't want.
>>>
>>> Unless they're likely to select hundreds of items I'd either go with a
>>> persisted GET var or a cookie. No need to drag server-side storage
>>> into this.
>>
>> Well he did say he had multiple pages. Maybe he's only displaying 5 per
>> page though. Still, sessions are easier to manage than GET vars since
>> you don't need to append them to every form action URL to accumulate
>> them. Session is managed transparently by PHP in most cases an amounts
>> to the approximate overhead of an include.
>
>
> Seriously? You'd rather use sessions than explode, modify and implode
> an array of numbers on each request? You really see that as a valuable
> developer time-saver?
>
> The mind boggles, but as I've said before and probably will again it's
> always a personal choice, I'm just suggesting alternatives.
>
> -Stut
>

Also, by storing the information server side, there is less of a chance
of the user tampering with the data.  Storing stuff in the session also
saves on network bandwidth of sending and retrieving the data with each
request.

Thank you,
Micah Gersten
onShore Networks
Internal Developer
http://www.onshore.com



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

RE: [PHP] It's Sunday, and I'm bored...

[Wolf]

Ni, he works for ACORN...

Oh wait, that would have vote early, vote often...

-Original Message-
From: Jay Blanchard <[EMAIL PROTECTED]>
Sent: Sunday, November 09, 2008 12:33 PM
To: Ólafur Waage <[EMAIL PROTECTED]>; php-general@lists.php.net
Subject: RE: [PHP] It's Sunday, and I'm bored...

[snip]
Commit Early Commit Often. :P
[/snip]

Are you from Louisiana? 

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



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

Re: [PHP] question about google maps

[tedd]

At 12:58 PM + 11/9/08, Richard Heyes wrote:

 > You are trapped on a desert island with the Baldwin Brothers.

 The food and rum have run out and you have a gun with a
 single bullet. Who do you shoot?


Line them all up and shoot them in a oner... ;-)

--
Richard Heyes


On XBOX Ghost Recon 4, we found that a 50 Cal sniper rifle will go 
through 5 guys, but not 4.


Amazing the amount of programming and detail that goes into those 
types of games.


That's it! Enough work for today (7:15 am - 7:00 pm Sunday).

I'm off to play Tour of Duty for the rest of the night.

Cheers,

tedd

PS: Yes, some of us old-timers just never grew up.

--
---
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] Image Manipulation

[Jochem Maas]

Ron Piggott schreef:
> Is there a way to find out the number of pixels wide and high an image
> is in PHP?
> 
> Is there a way to resize an image using PHP?

heh Ron, you've been around this list long enough to know that you
should STFW and RTFM before posting questions.

http://www.google.com/search?q=php+image+size

lo and behold the first result item.

the way it goes is like this, every time you think 'hey can I do that'
there is a very big chance some 12yo has already done it, blogged about it,
posted code on phpclasses.org (or some such place) and printed a T-Shirt
to celebrate the fact ... I know this from experience (not because I'm the
12yo .. although some might say so)

> 
> Ron
> 
> 


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

Re: [PHP] It's Sunday, and I'm bored...

[Jochem Maas]

Govinda schreef:
> 
> On Nov 9, 2008, at 12:28 PM, Richard Heyes wrote:
>>
>> Subversion, or svn for short. Helps you maintain code bases. Far
>> better than regular backups (though by no means a replacement).
> 
> I looked it over briefly and it looks smart for serious collaborated
> efforts..  but i ask - is anyone finding it makes sense for one-man shows?

hell yes, if you can't handle using it on your own, using it in a team
is next to impossible (you have all these other freaks that keep committing
stuff and either breaking things or giving merge conflicts to deal with).

svn (or the alternative, cvs, which I prefer to use) allows you to rollback
changes, compare versions and most interestingly, maybe, to tag releases which
you can then 'roll out' ... this give you an assurance of being sure about
what it is your putting live (as opposed to copying, ftping stuff and never
being quite sure as to which exact version of any given file your running live)

on windows both svn and cvs have a brilliant explorer plugin called
TortoiseCVS/TortoiseSVN for the clientside of things which any noob and
his dog can use ... it really is that easy to get started with. the 'hard'
part is setting up a repository server (which could be your local machine
but is better off being some server that is properly backed up, etc) .. STW
for setting up a repository.

DONT DELAY BUY ONE TODAY. ;-)

> (For the time to get up to speed with this maybe I could just pay more
> attention to making/naming my own backups?)
>>
>>
>>> It's nice to have at least loose communities like this list so we solo
>>> freelancers don't think we're simply mad.
>>
>> You are... :-)
> Well yes, but I meant without company..  See when we are in a herd, then
> even if we're all mad, then somehow it seems alright.  ;-)  We even have
> professional looking tools to track which version of madness!
>

you're not 'loose' the asylum is just bigger than you realise ... most people
know it by it's other name ... Earth.

> 


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

[PHP] Re: It's Sunday, and I'm bored...

[Colin Guthrie]

Jochem Maas wrote:

you're not 'loose' the asylum is just bigger than you realise ... most people
know it by it's other name ... Earth.


Yeah the "outside" of the Asylum is pretty small...  if you don't 
believe me, ask Wonko the Sane...


So long :p

Col


--

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mandriva Linux Contributor [http://www.mandriva.com/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]


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

[PHP] PHP / Procmail / MIME decoder, Imagemagick, MySQL, PDF fax management system

[Dan Harrington]

Hello,

I have seen procmail and PERL, and some MIME handling scripts...but I
haven't seen PHP, Procmail, Mysql, and MIME handling to effectively handle
incoming emails.  I don't know PERL, so naturally I'd like to see it all
written in stuff that I can understand and tweak if needbe.

I have a Fax to Email service that sends me emails with all my faxes.  I
want to process and parse them as follows:
Fax >> multi-page PDFs >> My Email >> Procmail >> PHP / MIME decoder /
Imagemagick >> MySQL >> save PDF >> Imagemagick each page to preview
thumbnails.

The attachments would be stored (or links to attachments stored on file
system) along with main message stored in MySQL, and Imagemagick would make
thumbnails of each page of the multi-page PDFs.

I could then have my office assistant browse the messages by web browser,
add keywords, To/From, Subject, categories to each of the
messages,images,PDFs for later perusal and searching.  And when I wanted to
go back a year ago and try to retrieve an old fax, it wouldn't be so hard.
:-)

Surely someone has done this, but I can't find itand I'm too busy and
cowardly to write it myself :-)

Thanks
Dan


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

[PHP] Managed VPS recommendations

[Larry Garfield]

OK, so maybe I'm not looking for a VPS per se but I suspect I am given the 
requirements I have.

I am looking for a new web host, both for my personal work and on behalf of my 
company.  (Two separate entities entirely, but odds are I'll end up using the 
same host for both just to make my life easier.)  My specific requirements 
relate to running medium to large PHP-based web sites.  The host we've been 
using at work is having trouble scaling up nicely, and I want to see what else 
is out there.

Requirements are:

- Apache 2
+ Must include mod_rewrite, mod_deflate, and other modern tools
+ Must support at least 2 GB storage per account.

- MySQL 5 installed by default.
+ Must allow databases up to 1 GB in size at least.  Larger would be even 
nicer.
+ Must support remote database management (tunneled through SSH is OK).
+ Must allow InnoDB tables; requiring it database-wide and using a different DB 
server for it is acceptable.

- PHP 5.2.3 or better installed by default, including
+ User-configurable memory limit, up to at least 100 MB. 
+ Respectable set of PHP modules enabled, including SOAP, PDO, SQLite, 
XML/XSLT, etc.  The "modern" tools.
+ Must be able and willing to install additional PHP modules upon request.
+ Must be able and willing to configure an opcode cache upon request, or even 
have it by default.  (Here's where I suspect a VPS will be necessary.)

- Managed
I'm a web developer, not a sysadmin.  Installing, configuring, and upgrading 
the above (such as opcode caches, PHP modules, etc.) must be something the 
host does, not something they expect me to do.  I also don't want to have to 
go through a multi-week song and dance before the host is convinced to install 
a common PHP module.  (I had to do that to get SOAP support at our current 
host, and they don't allow us to tweak the memory limit, which is why we're 
looking elsewhere.

A decent control panel is, of course, a must.  I admit to not actually liking 
CPanel or Plesk, as I find them way over-featured and therefore impossible to 
navigate, but I can probably deal if the host is good otherwise.

Naturally a good reputation for not over-selling is also important.  It should 
also be based in the continental USA, but I don't particularly care if they're 
local.  Good corporate citizen track record (e.g., hosts public mirrors) is 
good icing but not make-or-break as long as they're not douchebags.  We're 
willing to pay for quality, but not be robbed for it.  We're looking for a 
company we can partner with long-term for hosing several dozen sites.

So, does this sound like anyone you know? :-)  Any hosts you can 
recommend/avoid?  So far random searching has turned up Amazon EC2 and Jaguar 
VPS as possibilities, but I'd like to get broader input if possible.

Thanks all!

-- 
Larry Garfield
[EMAIL PROTECTED]

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

Re: [PHP] PHP - Web/list Question...

[Robert Cummings]

On Sun, 2008-11-09 at 18:22 +, Stut wrote:
> On 9 Nov 2008, at 18:14, Robert Cummings wrote:
> > On Sun, 2008-11-09 at 18:00 +, Stut wrote:
> >> On 9 Nov 2008, at 07:16, Robert Cummings wrote:
> >>> On Sat, 2008-11-08 at 20:26 -0800, bruce wrote:
>  I've got a question/issue that I want to bounce off the list.
> 
>  I have a list that extends over multiple pages. there might be 200
>  items,
>  and i don't want to have the items listed on the same page as it
>  would be
>  too long. i can break the list up, so i can have it be displayed  
>  over
>  multiple pages. however, i want the user to select different items
>  from the
>  list. given that the selected items might be over different pages,
>  what's
>  the best way of keeping a running track of the items that have been
>  selected??
> 
>  I could have each page be a form, and do a post/get where i then
>  keep track
>  of the selected items from page to page, but that would appear to
>  get ugly.
>  i'm looking for pointers to other sites/code that might have  
>  already
>  implemented this kind of scenario.
> 
>  thoughts/pointers would be appreciated...
> >>>
> >>> Accumulate them in the session. When done, and before final action  
> >>> you
> >>> could let them view a summary of selected items and allow deletion  
> >>> of
> >>> any entries they don't want.
> >>
> >> Unless they're likely to select hundreds of items I'd either go  
> >> with a
> >> persisted GET var or a cookie. No need to drag server-side storage
> >> into this.
> >
> > Well he did say he had multiple pages. Maybe he's only displaying 5  
> > per
> > page though. Still, sessions are easier to manage than GET vars since
> > you don't need to append them to every form action URL to accumulate
> > them. Session is managed transparently by PHP in most cases an amounts
> > to the approximate overhead of an include.
> 
> 
> Seriously? You'd rather use sessions than explode, modify and implode  
> an array of numbers on each request? You really see that as a valuable  
> developer time-saver?
> 
> The mind boggles, but as I've said before and probably will again it's  
> always a personal choice, I'm just suggesting alternatives.

Depends on the situation really. I'd really not restrict myself in an
environment where there is sufficient possibility for which X numbers
whose cumulative digits could easily break the 1024 byte lower bound for
GET requests. How many digits are these IDs? How man can be chosen? It's
not unreasonable to select pages of some kind of item. It would only
take 200 averaging 5 digits to break the limit. The solution here is
simple in both respects, and using sessions really doesn't strike me as
using a sledgehammer.

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


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

Re: [PHP] Re: strtotime

[Eric Butera]

On Sun, Nov 9, 2008 at 3:50 PM, Ashley Sheridan
<[EMAIL PROTECTED]> wrote:
> On Sun, 2008-11-09 at 19:46 +0100, gilles wrote:
>> "Thodoris" <[EMAIL PROTECTED]> a crit dans le message de news:
>> [EMAIL PROTECTED]
>> > O/H Bastien Koert ??:
>> >> 2008/11/8 Maciek Sokolewicz <[EMAIL PROTECTED]>
>> >>
>> >>
>> >>> gilles wrote:
>> >>>
>> >>>
>>  Avec la version 4 de php, strtotime("20080950") fonctionne correctement
>>  en
>>  allant sur le mois d'octobre, alors qu'en version 5: 19700101.
>>  Merci de votre aide
>> 
>> 
>> 
>> >>> This is an ENGLISH list, please rephrase your question in english and
>> >>> people might understand.
>> >>>
>> >>> Cette liste est une liste anglaise, reformulent svp votre question en
>> >>> anglais svp.
>> >>>
>> >>> merci,
>> >>>
>> >>> - Tul
>> >>>
>> >>>
>> >>> --
>> >>> PHP General Mailing List (http://www.php.net/)
>> >>> To unsubscribe, visit: http://www.php.net/unsub.php
>> >>>
>> >>>
>> >>>
>> >> I'll translate
>> >>
>> >> In PHP4, strtotime works fine
>> >>
>> >
>> > Define "works  fine".
>> >
>> >> in PHP5 strtotime gives a result of 19700101 when the data entered was
>> >> strtotime("20080950")
>> >>
>> >>
>> >
>> > Linux
>> > PHP version 5.1.6
>> > Apache 2
>> >
>> > This strtotime("20080950") returns nothing.
>> >
>> > ---
>> > Thodoris
>> "Works fine" in php4 means date("d/m/Y",strtotime("20080950")) returns
>> 20/10/2008, which is correct.
>> Thanks
>>
>>
>>
> Which is actually incorrect (I've never seen the 50th of September) and
> it was fixed in PHP 5. What you are assuming is correct behaviour is
> actually a bug.
>
>
> Ash
> www.ashleysheridan.co.uk
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

I didn't read this thread (sorry) but I wonder if timezone/locale
might be the culprit.

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

Re: [PHP] Image Manipulation

[Ashley Sheridan]

On Sun, 2008-11-09 at 19:16 -0500, Ron Piggott wrote:
> Is there a way to find out the number of pixels wide and high an image
> is in PHP?
> 
> Is there a way to resize an image using PHP?
> 
> Ron
> 
> 
Yes. Look at the PHP GD manual.


Ash
www.ashleysheridan.co.uk


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

Re: [PHP] Re: strtotime

[gilles]

"Thodoris" <[EMAIL PROTECTED]> a écrit dans le message de news: 
[EMAIL PROTECTED]
> O/H Bastien Koert ??:
>> 2008/11/8 Maciek Sokolewicz <[EMAIL PROTECTED]>
>>
>>
>>> gilles wrote:
>>>
>>>
 Avec la version 4 de php, strtotime("20080950") fonctionne correctement 
 en
 allant sur le mois d'octobre, alors qu'en version 5: 19700101.
 Merci de votre aide



>>> This is an ENGLISH list, please rephrase your question in english and
>>> people might understand.
>>>
>>> Cette liste est une liste anglaise, reformulent svp votre question en
>>> anglais svp.
>>>
>>> merci,
>>>
>>> - Tul
>>>
>>>
>>> --
>>> PHP General Mailing List (http://www.php.net/)
>>> To unsubscribe, visit: http://www.php.net/unsub.php
>>>
>>>
>>>
>> I'll translate
>>
>> In PHP4, strtotime works fine
>>
>
> Define "works  fine".
>
>> in PHP5 strtotime gives a result of 19700101 when the data entered was
>> strtotime("20080950")
>>
>>
>
> Linux
> PHP version 5.1.6
> Apache 2
>
> This strtotime("20080950") returns nothing.
>
> ---
> Thodoris
"Works fine" in php4 means date("d/m/Y",strtotime("20080950")) returns 
20/10/2008, which is correct.
Thanks 



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

Re: [PHP] It's Sunday, and I'm bored...

[Govinda]

Being sunday, I don't feel too shy to ask:
What are you guys all referring to?
My best guess is some version control software that regulars here seem  
to all know about.
Maybe I need to get me some of that...  several times lately I dove  
into thick hairy code and got neck deep and then with only 10 mins.  
left realized there was no solution in sight and even the old working  
code was now broken...
(Sure I keep backups, but usually I know I want to go forward... I  
always fix it all OK in the end, but...)
It's nice to have at least loose communities like this list so we solo  
freelancers don't think we're simply mad.

-G

On Nov 9, 2008, at 4:03 AM, Richard Heyes wrote:


Hi,

I just looked at my commit diff that I need to check - 1500 lines (!).
Uhhh... Maybe that policy of committing frequently wouldn't be so
terrible after all...

--
Richard Heyes

HTML5 Graphing for FF, Chrome, Opera and Safari:
http://www.rgraph.org (Updated November 1st)

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




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

Re: [PHP] PHP - Web/list Question...

[tedd]

At 8:26 PM -0800 11/8/08, bruce wrote:

Hi.

I've got a question/issue that I want to bounce off the list.

I have a list that extends over multiple pages. there might be 200 items,
and i don't want to have the items listed on the same page as it would be
too long. i can break the list up, so i can have it be displayed over
multiple pages. however, i want the user to select different items from the
list. given that the selected items might be over different pages, what's
the best way of keeping a running track of the items that have been
selected??

I could have each page be a form, and do a post/get where i then keep track
of the selected items from page to page, but that would appear to get ugly.
i'm looking for pointers to other sites/code that might have already
implemented this kind of scenario.

thoughts/pointers would be appreciated...


Without reading any one else's reply, here's something you might consider.

http://webbytedd.com/bbb/paging/index.php?page=1

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 - Web/list Question...

[Stut]

On 9 Nov 2008, at 07:16, Robert Cummings wrote:

On Sat, 2008-11-08 at 20:26 -0800, bruce wrote:

I've got a question/issue that I want to bounce off the list.

I have a list that extends over multiple pages. there might be 200  
items,
and i don't want to have the items listed on the same page as it  
would be

too long. i can break the list up, so i can have it be displayed over
multiple pages. however, i want the user to select different items  
from the
list. given that the selected items might be over different pages,  
what's

the best way of keeping a running track of the items that have been
selected??

I could have each page be a form, and do a post/get where i then  
keep track
of the selected items from page to page, but that would appear to  
get ugly.

i'm looking for pointers to other sites/code that might have already
implemented this kind of scenario.

thoughts/pointers would be appreciated...


Accumulate them in the session. When done, and before final action you
could let them view a summary of selected items and allow deletion of
any entries they don't want.


Unless they're likely to select hundreds of items I'd either go with a  
persisted GET var or a cookie. No need to drag server-side storage  
into this.


-Stut

--
http://stut.net/

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

Re: [PHP] PHP - Web/list Question...

[Stut]

On 9 Nov 2008, at 18:05, Micah Gersten wrote:

Stut wrote:

On 9 Nov 2008, at 07:16, Robert Cummings wrote:

On Sat, 2008-11-08 at 20:26 -0800, bruce wrote:

I've got a question/issue that I want to bounce off the list.

I have a list that extends over multiple pages. there might be 200
items,
and i don't want to have the items listed on the same page as it
would be
too long. i can break the list up, so i can have it be displayed  
over

multiple pages. however, i want the user to select different items
from the
list. given that the selected items might be over different pages,
what's
the best way of keeping a running track of the items that have been
selected??

I could have each page be a form, and do a post/get where i then
keep track
of the selected items from page to page, but that would appear to
get ugly.
i'm looking for pointers to other sites/code that might have  
already

implemented this kind of scenario.

thoughts/pointers would be appreciated...


Accumulate them in the session. When done, and before final action  
you
could let them view a summary of selected items and allow deletion  
of

any entries they don't want.


Unless they're likely to select hundreds of items I'd either go  
with a

persisted GET var or a cookie. No need to drag server-side storage
into this.


Server side storage is meant to be used.  The session was one of the
greatest things that PHP has given to the web programming world.  It
should not be feared.  Also, why clutter up someone's machine with  
stuff

held in a cookie?


1. PHP certainly did not give sessions to the "web programming world".

2. Why clutter up your server architecture with sessions unless you're  
already using them reasonable purposes. What we're talking about here  
is a list of numbers, which I'm perhaps incorrectly assuming will be  
fairly short and extremely temporary?


IMHO sessions are overused in all web development, not just PHP. In  
most cases they're a wrecking ball when a tiny hammer will do. But  
it's your choice, wreck away!


-Stut

--
http://stut.net/

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

Re: [PHP] It's Sunday, and I'm bored...

[Govinda]

On Nov 9, 2008, at 12:28 PM, Richard Heyes wrote:


Subversion, or svn for short. Helps you maintain code bases. Far
better than regular backups (though by no means a replacement).


I looked it over briefly and it looks smart for serious collaborated  
efforts..  but i ask - is anyone finding it makes sense for one-man  
shows?
(For the time to get up to speed with this maybe I could just pay more  
attention to making/naming my own backups?)



It's nice to have at least loose communities like this list so we  
solo

freelancers don't think we're simply mad.


You are... :-)
Well yes, but I meant without company..  See when we are in a herd,  
then even if we're all mad, then somehow it seems alright.  ;-)  We  
even have professional looking tools to track which version of madness!



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

Re: [PHP] PHP - Web/list Question...

[Stut]

On 9 Nov 2008, at 18:37, Robert Cummings wrote:

On Sun, 2008-11-09 at 18:22 +, Stut wrote:

On 9 Nov 2008, at 18:14, Robert Cummings wrote:

On Sun, 2008-11-09 at 18:00 +, Stut wrote:

On 9 Nov 2008, at 07:16, Robert Cummings wrote:

On Sat, 2008-11-08 at 20:26 -0800, bruce wrote:

I've got a question/issue that I want to bounce off the list.

I have a list that extends over multiple pages. there might be  
200

items,
and i don't want to have the items listed on the same page as it
would be
too long. i can break the list up, so i can have it be displayed
over
multiple pages. however, i want the user to select different  
items

from the
list. given that the selected items might be over different  
pages,

what's
the best way of keeping a running track of the items that have  
been

selected??

I could have each page be a form, and do a post/get where i then
keep track
of the selected items from page to page, but that would appear to
get ugly.
i'm looking for pointers to other sites/code that might have
already
implemented this kind of scenario.

thoughts/pointers would be appreciated...


Accumulate them in the session. When done, and before final action
you
could let them view a summary of selected items and allow deletion
of
any entries they don't want.


Unless they're likely to select hundreds of items I'd either go
with a
persisted GET var or a cookie. No need to drag server-side storage
into this.


Well he did say he had multiple pages. Maybe he's only displaying 5
per
page though. Still, sessions are easier to manage than GET vars  
since

you don't need to append them to every form action URL to accumulate
them. Session is managed transparently by PHP in most cases an  
amounts

to the approximate overhead of an include.



Seriously? You'd rather use sessions than explode, modify and implode
an array of numbers on each request? You really see that as a  
valuable

developer time-saver?

The mind boggles, but as I've said before and probably will again  
it's

always a personal choice, I'm just suggesting alternatives.


Depends on the situation really. I'd really not restrict myself in an
environment where there is sufficient possibility for which X numbers
whose cumulative digits could easily break the 1024 byte lower bound  
for
GET requests. How many digits are these IDs? How man can be chosen?  
It's

not unreasonable to select pages of some kind of item. It would only
take 200 averaging 5 digits to break the limit. The solution here is
simple in both respects, and using sessions really doesn't strike me  
as

using a sledgehammer.


I don't disagree, I was just pointing out that sessions as implemented  
by PHP are not the only answer to data storage between requests and in  
a lot of cases are overkill. It's a decision you have to base on the  
requirements and expected future developments of a project.


I firmly believe the advice given on this list should provide choices  
rather than dictate methods. There's always more than one way to do  
something.


-Stut

--
http://stut.net/

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

Re: [PHP] PHP - Web/list Question...

[Stut]

On 9 Nov 2008, at 20:30, Robert Cummings wrote:

On Sun, 2008-11-09 at 20:16 +, Stut wrote:

On 9 Nov 2008, at 18:37, Robert Cummings wrote:

On Sun, 2008-11-09 at 18:22 +, Stut wrote:

On 9 Nov 2008, at 18:14, Robert Cummings wrote:

On Sun, 2008-11-09 at 18:00 +, Stut wrote:

On 9 Nov 2008, at 07:16, Robert Cummings wrote:

On Sat, 2008-11-08 at 20:26 -0800, bruce wrote:

I've got a question/issue that I want to bounce off the list.

I have a list that extends over multiple pages. there might be
200
items,
and i don't want to have the items listed on the same page as  
it

would be
too long. i can break the list up, so i can have it be  
displayed

over
multiple pages. however, i want the user to select different
items
from the
list. given that the selected items might be over different
pages,
what's
the best way of keeping a running track of the items that have
been
selected??

I could have each page be a form, and do a post/get where i  
then

keep track
of the selected items from page to page, but that would  
appear to

get ugly.
i'm looking for pointers to other sites/code that might have
already
implemented this kind of scenario.

thoughts/pointers would be appreciated...


Accumulate them in the session. When done, and before final  
action

you
could let them view a summary of selected items and allow  
deletion

of
any entries they don't want.


Unless they're likely to select hundreds of items I'd either go
with a
persisted GET var or a cookie. No need to drag server-side  
storage

into this.


Well he did say he had multiple pages. Maybe he's only  
displaying 5

per
page though. Still, sessions are easier to manage than GET vars
since
you don't need to append them to every form action URL to  
accumulate

them. Session is managed transparently by PHP in most cases an
amounts
to the approximate overhead of an include.



Seriously? You'd rather use sessions than explode, modify and  
implode

an array of numbers on each request? You really see that as a
valuable
developer time-saver?

The mind boggles, but as I've said before and probably will again
it's
always a personal choice, I'm just suggesting alternatives.


Depends on the situation really. I'd really not restrict myself in  
an
environment where there is sufficient possibility for which X  
numbers

whose cumulative digits could easily break the 1024 byte lower bound
for
GET requests. How many digits are these IDs? How man can be chosen?
It's
not unreasonable to select pages of some kind of item. It would only
take 200 averaging 5 digits to break the limit. The solution here is
simple in both respects, and using sessions really doesn't strike me
as
using a sledgehammer.


I don't disagree, I was just pointing out that sessions as  
implemented
by PHP are not the only answer to data storage between requests and  
in

a lot of cases are overkill. It's a decision you have to base on the
requirements and expected future developments of a project.

I firmly believe the advice given on this list should provide choices
rather than dictate methods. There's always more than one way to do
something.


I absolutely agree, I certainly don't think what you proposed is in  
any

way wrong, but *my* preference for this particular problem would
probably be to use the session. I avoid the session as much as  
possible
since then you can't provide a link to someone via email to bring up  
the

same context as you had, but in this case that seems an unlikely
scenario, whereas the possibility of accumulating many items is quite
likely given the items will be paged.


Agreed, but IMHO lack of URL-sharing is just one of many reasons to  
avoid sessions if possible.


Taking further context though on my stream of responses... you did  
say:


   Seriously? You'd rather use sessions than explode, modify and
   implode an array of numbers on each request?

This suggests you thought my particular opinion to be ludicrous ;) As
such, I felt inclined to more strongly defend my stance.


I should've explained the context of that reply. I was specifically  
referring to your assertion that "sessions are easier to manage". They  
are slightly easier than most alternatives for the developer, but they  
can quickly become a nightmare for the sysadmin.


-Stut

--
http://stut.net/

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

RE: [PHP] It's Sunday, and I'm bored...

[Jay Blanchard]

[snip]
Commit Early Commit Often. :P
[/snip]

Are you from Louisiana? 

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

Re: [PHP] It's Sunday, and I'm bored...

[Ólafur Waage]

On Sun, Nov 9, 2008 at 5:33 PM, Jay Blanchard <[EMAIL PROTECTED]> wrote:
> [snip]
> Commit Early Commit Often. :P
> [/snip]
>
> Are you from Louisiana?
>

Iceland so no

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

Re: [PHP] PHP - Web/list Question...

[Micah Gersten]

Robert Cummings wrote:
> On Sun, 2008-11-09 at 12:26 -0600, Micah Gersten wrote:
>   
>> Stut wrote:
>> 
>>> On 9 Nov 2008, at 18:14, Robert Cummings wrote:
>>>   
 On Sun, 2008-11-09 at 18:00 +, Stut wrote:
 
> On 9 Nov 2008, at 07:16, Robert Cummings wrote:
>   
>> On Sat, 2008-11-08 at 20:26 -0800, bruce wrote:
>> 
>>> I've got a question/issue that I want to bounce off the list.
>>>
>>> I have a list that extends over multiple pages. there might be 200
>>> items,
>>> and i don't want to have the items listed on the same page as it
>>> would be
>>> too long. i can break the list up, so i can have it be displayed over
>>> multiple pages. however, i want the user to select different items
>>> from the
>>> list. given that the selected items might be over different pages,
>>> what's
>>> the best way of keeping a running track of the items that have been
>>> selected??
>>>
>>> I could have each page be a form, and do a post/get where i then
>>> keep track
>>> of the selected items from page to page, but that would appear to
>>> get ugly.
>>> i'm looking for pointers to other sites/code that might have already
>>> implemented this kind of scenario.
>>>
>>> thoughts/pointers would be appreciated...
>>>   
>> Accumulate them in the session. When done, and before final action you
>> could let them view a summary of selected items and allow deletion of
>> any entries they don't want.
>> 
> Unless they're likely to select hundreds of items I'd either go with a
> persisted GET var or a cookie. No need to drag server-side storage
> into this.
>   
 Well he did say he had multiple pages. Maybe he's only displaying 5 per
 page though. Still, sessions are easier to manage than GET vars since
 you don't need to append them to every form action URL to accumulate
 them. Session is managed transparently by PHP in most cases an amounts
 to the approximate overhead of an include.
 
>>> Seriously? You'd rather use sessions than explode, modify and implode
>>> an array of numbers on each request? You really see that as a valuable
>>> developer time-saver?
>>>
>>> The mind boggles, but as I've said before and probably will again it's
>>> always a personal choice, I'm just suggesting alternatives.
>>>
>>> -Stut
>>>
>>>   
>> Also, by storing the information server side, there is less of a chance
>> of the user tampering with the data.  Storing stuff in the session also
>> saves on network bandwidth of sending and retrieving the data with each
>> request.
>> 
>
> Nah, the problem is the same. Tamper with the GET data or tamper with
> the POST date before it goes into the session. Need to check the
> incoming data regardless.
>
> Cheers,
> Rob.
>   

Yes, but once it's in the session, it should be ok.

Thank you,
Micah Gersten
onShore Networks
Internal Developer
http://www.onshore.com



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

Re: [PHP] PHP - Web/list Question...

[Wolf]

 > Accumulate them in the session. When done, and before final action you
> could let them view a summary of selected items and allow deletion of
> any entries they don't want.

You session purest!  :-P


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

Re: [PHP] PHP - Web/list Question...

[Robert Cummings]

On Sun, 2008-11-09 at 18:00 +, Stut wrote:
> On 9 Nov 2008, at 07:16, Robert Cummings wrote:
> > On Sat, 2008-11-08 at 20:26 -0800, bruce wrote:
> >> I've got a question/issue that I want to bounce off the list.
> >>
> >> I have a list that extends over multiple pages. there might be 200  
> >> items,
> >> and i don't want to have the items listed on the same page as it  
> >> would be
> >> too long. i can break the list up, so i can have it be displayed over
> >> multiple pages. however, i want the user to select different items  
> >> from the
> >> list. given that the selected items might be over different pages,  
> >> what's
> >> the best way of keeping a running track of the items that have been
> >> selected??
> >>
> >> I could have each page be a form, and do a post/get where i then  
> >> keep track
> >> of the selected items from page to page, but that would appear to  
> >> get ugly.
> >> i'm looking for pointers to other sites/code that might have already
> >> implemented this kind of scenario.
> >>
> >> thoughts/pointers would be appreciated...
> >
> > Accumulate them in the session. When done, and before final action you
> > could let them view a summary of selected items and allow deletion of
> > any entries they don't want.
> 
> Unless they're likely to select hundreds of items I'd either go with a  
> persisted GET var or a cookie. No need to drag server-side storage  
> into this.

Well he did say he had multiple pages. Maybe he's only displaying 5 per
page though. Still, sessions are easier to manage than GET vars since
you don't need to append them to every form action URL to accumulate
them. Session is managed transparently by PHP in most cases an amounts
to the approximate overhead of an include.

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


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

Re: [PHP] PHP - Web/list Question...

[Robert Cummings]

On Sun, 2008-11-09 at 12:26 -0600, Micah Gersten wrote:
> Stut wrote:
> > On 9 Nov 2008, at 18:14, Robert Cummings wrote:
> >> On Sun, 2008-11-09 at 18:00 +, Stut wrote:
> >>> On 9 Nov 2008, at 07:16, Robert Cummings wrote:
>  On Sat, 2008-11-08 at 20:26 -0800, bruce wrote:
> > I've got a question/issue that I want to bounce off the list.
> >
> > I have a list that extends over multiple pages. there might be 200
> > items,
> > and i don't want to have the items listed on the same page as it
> > would be
> > too long. i can break the list up, so i can have it be displayed over
> > multiple pages. however, i want the user to select different items
> > from the
> > list. given that the selected items might be over different pages,
> > what's
> > the best way of keeping a running track of the items that have been
> > selected??
> >
> > I could have each page be a form, and do a post/get where i then
> > keep track
> > of the selected items from page to page, but that would appear to
> > get ugly.
> > i'm looking for pointers to other sites/code that might have already
> > implemented this kind of scenario.
> >
> > thoughts/pointers would be appreciated...
> 
>  Accumulate them in the session. When done, and before final action you
>  could let them view a summary of selected items and allow deletion of
>  any entries they don't want.
> >>>
> >>> Unless they're likely to select hundreds of items I'd either go with a
> >>> persisted GET var or a cookie. No need to drag server-side storage
> >>> into this.
> >>
> >> Well he did say he had multiple pages. Maybe he's only displaying 5 per
> >> page though. Still, sessions are easier to manage than GET vars since
> >> you don't need to append them to every form action URL to accumulate
> >> them. Session is managed transparently by PHP in most cases an amounts
> >> to the approximate overhead of an include.
> >
> >
> > Seriously? You'd rather use sessions than explode, modify and implode
> > an array of numbers on each request? You really see that as a valuable
> > developer time-saver?
> >
> > The mind boggles, but as I've said before and probably will again it's
> > always a personal choice, I'm just suggesting alternatives.
> >
> > -Stut
> >
> 
> Also, by storing the information server side, there is less of a chance
> of the user tampering with the data.  Storing stuff in the session also
> saves on network bandwidth of sending and retrieving the data with each
> request.

Nah, the problem is the same. Tamper with the GET data or tamper with
the POST date before it goes into the session. Need to check the
incoming data regardless.

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


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

Re: [PHP] PHP - Web/list Question...

[Stut]

On 9 Nov 2008, at 18:14, Robert Cummings wrote:

On Sun, 2008-11-09 at 18:00 +, Stut wrote:

On 9 Nov 2008, at 07:16, Robert Cummings wrote:

On Sat, 2008-11-08 at 20:26 -0800, bruce wrote:

I've got a question/issue that I want to bounce off the list.

I have a list that extends over multiple pages. there might be 200
items,
and i don't want to have the items listed on the same page as it
would be
too long. i can break the list up, so i can have it be displayed  
over

multiple pages. however, i want the user to select different items
from the
list. given that the selected items might be over different pages,
what's
the best way of keeping a running track of the items that have been
selected??

I could have each page be a form, and do a post/get where i then
keep track
of the selected items from page to page, but that would appear to
get ugly.
i'm looking for pointers to other sites/code that might have  
already

implemented this kind of scenario.

thoughts/pointers would be appreciated...


Accumulate them in the session. When done, and before final action  
you
could let them view a summary of selected items and allow deletion  
of

any entries they don't want.


Unless they're likely to select hundreds of items I'd either go  
with a

persisted GET var or a cookie. No need to drag server-side storage
into this.


Well he did say he had multiple pages. Maybe he's only displaying 5  
per

page though. Still, sessions are easier to manage than GET vars since
you don't need to append them to every form action URL to accumulate
them. Session is managed transparently by PHP in most cases an amounts
to the approximate overhead of an include.



Seriously? You'd rather use sessions than explode, modify and implode  
an array of numbers on each request? You really see that as a valuable  
developer time-saver?


The mind boggles, but as I've said before and probably will again it's  
always a personal choice, I'm just suggesting alternatives.


-Stut

--
http://stut.net/

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

[PHP] Image Manipulation

[Ron Piggott]

Is there a way to find out the number of pixels wide and high an image
is in PHP?

Is there a way to resize an image using PHP?

Ron


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

Re: [PHP] PHP - Web/list Question...

[Robert Cummings]

On Sun, 2008-11-09 at 12:39 -0600, Micah Gersten wrote:
> Robert Cummings wrote:
> > On Sun, 2008-11-09 at 12:26 -0600, Micah Gersten wrote:
> >   
> >> Stut wrote:
> >> 
> >>> On 9 Nov 2008, at 18:14, Robert Cummings wrote:
> >>>   
>  On Sun, 2008-11-09 at 18:00 +, Stut wrote:
>  
> > On 9 Nov 2008, at 07:16, Robert Cummings wrote:
> >   
> >> On Sat, 2008-11-08 at 20:26 -0800, bruce wrote:
> >> 
> >>> I've got a question/issue that I want to bounce off the list.
> >>>
> >>> I have a list that extends over multiple pages. there might be 200
> >>> items,
> >>> and i don't want to have the items listed on the same page as it
> >>> would be
> >>> too long. i can break the list up, so i can have it be displayed over
> >>> multiple pages. however, i want the user to select different items
> >>> from the
> >>> list. given that the selected items might be over different pages,
> >>> what's
> >>> the best way of keeping a running track of the items that have been
> >>> selected??
> >>>
> >>> I could have each page be a form, and do a post/get where i then
> >>> keep track
> >>> of the selected items from page to page, but that would appear to
> >>> get ugly.
> >>> i'm looking for pointers to other sites/code that might have already
> >>> implemented this kind of scenario.
> >>>
> >>> thoughts/pointers would be appreciated...
> >>>   
> >> Accumulate them in the session. When done, and before final action you
> >> could let them view a summary of selected items and allow deletion of
> >> any entries they don't want.
> >> 
> > Unless they're likely to select hundreds of items I'd either go with a
> > persisted GET var or a cookie. No need to drag server-side storage
> > into this.
> >   
>  Well he did say he had multiple pages. Maybe he's only displaying 5 per
>  page though. Still, sessions are easier to manage than GET vars since
>  you don't need to append them to every form action URL to accumulate
>  them. Session is managed transparently by PHP in most cases an amounts
>  to the approximate overhead of an include.
>  
> >>> Seriously? You'd rather use sessions than explode, modify and implode
> >>> an array of numbers on each request? You really see that as a valuable
> >>> developer time-saver?
> >>>
> >>> The mind boggles, but as I've said before and probably will again it's
> >>> always a personal choice, I'm just suggesting alternatives.
> >>>
> >>> -Stut
> >>>
> >>>   
> >> Also, by storing the information server side, there is less of a chance
> >> of the user tampering with the data.  Storing stuff in the session also
> >> saves on network bandwidth of sending and retrieving the data with each
> >> request.
> >> 
> >
> > Nah, the problem is the same. Tamper with the GET data or tamper with
> > the POST date before it goes into the session. Need to check the
> > incoming data regardless.
> >
> > Cheers,
> > Rob.
> >   
> 
> Yes, but once it's in the session, it should be ok.

True, but the same possibility of tampering existed with the POST data.
Therefore the chance of tampering is the same.

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


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

Re: [PHP] PHP - Web/list Question...

[Jochem Maas]

Stut schreef:
> On 9 Nov 2008, at 20:30, Robert Cummings wrote:



> Agreed, but IMHO lack of URL-sharing is just one of many reasons to
> avoid sessions if possible.
> 
>> Taking further context though on my stream of responses... you did say:
>>
>>Seriously? You'd rather use sessions than explode, modify and
>>implode an array of numbers on each request?
>>
>> This suggests you thought my particular opinion to be ludicrous ;) As
>> such, I felt inclined to more strongly defend my stance.
> 
> I should've explained the context of that reply. I was specifically
> referring to your assertion that "sessions are easier to manage". They
> are slightly easier than most alternatives for the developer, but they
> can quickly become a nightmare for the sysadmin.

I here by baptise you 'Stateless Stut' ;-)

... oh, I had a drinking session on friday ... it didn't make anything
easier ... especially not driving.

> 
> -Stut
> 


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