[PHP] Managed VPS recommendations
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
[PHP] PHP / Procmail / MIME decoder, Imagemagick, MySQL, PDF fax management system
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] Re: It's Sunday, and I'm bored...
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
Re: [PHP] Re: strtotime
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] PHP - Web/list Question...
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
Re: [PHP] It's Sunday, and I'm bored...
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
Re: [PHP] Image Manipulation
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...
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] Image Manipulation
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
[PHP] Image Manipulation
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] question about google maps
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] PHP - Web/list Question...
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...
> 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...
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] Re: strtotime
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] Re: strtotime
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] PHP - Web/list Question...
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...
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...
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...
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...
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...
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] It's Sunday, and I'm bored...
> 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] It's Sunday, and I'm bored...
> 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] 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 Framework for PHP -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: strtotime
"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] PHP - Web/list Question...
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...
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...
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] PHP - Web/list Question...
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] PHP - Web/list Question...
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
Re: [PHP] It's Sunday, and I'm bored...
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] It's Sunday, and I'm bored...
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...
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] PHP - Web/list Question...
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...
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...
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] It's Sunday, and I'm bored...
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...
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] 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
Re: [PHP] It's Sunday, and I'm bored...
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...
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...
> 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...
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
> 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...
> 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
Re: [PHP] question about google maps
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
[PHP] It's Sunday, and I'm bored...
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...
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
[PHP] Re: Secure redirection?
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] Re: strtotime
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
Re: [PHP] Re: strtotime
"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
