php-general Digest 6 Aug 2009 12:21:00 -0000 Issue 6270
Topics (messages 296360 through 296376):
Re: Time keeping in DB
296360 by: Ralph Deffke
296363 by: Shawn McKenzie
296364 by: Shawn McKenzie
Re: PHP programming strategy
296361 by: Clancy
296373 by: Ashley Sheridan
296374 by: Ralph Deffke
296375 by: Ashley Sheridan
Re: dynamically naming PHP vars on the fly?
296362 by: Govinda
296371 by: Nisse Engström
"PHP 6 and MySQL 5 for Dynamic Web Sites" Book
296365 by: sono-io.fannullone.us
296366 by: Ralph Deffke
296372 by: Ashley Sheridan
Displaying user data and picture
296367 by: nashrul
Re: navigation include not functioning (RESOLVED)
296368 by: Paul M Foster
Re: Need quick got written up yesterday!! OUCH (RESOLVED)
296369 by: Michael A. Peters
New-York games
296370 by: Abena Barton
Re: Warning: OutsourcingRoom.com
296376 by: abdulazeez alugo
Administrivia:
To subscribe to the digest, e-mail:
php-general-digest-subscr...@lists.php.net
To unsubscribe from the digest, e-mail:
php-general-digest-unsubscr...@lists.php.net
To post to the list, e-mail:
php-gene...@lists.php.net
----------------------------------------------------------------------
--- Begin Message ---
as I said, the job is to store a time sheet.
u came up with:
1. One record for each 7 day week (year, week_num, d1, d2, d3, d4, d5,
d6, d7) where the dX field holds the hours worked
2. One record for each day (date, hours)
it seems that just the first record is fine. in a data design u dont hold
the same data twice. so why to use the second record?
if u want to use two tables, then the d1-d7 fields should not be in that
record.
if u use the second record it could be that there are two records with the
same date, what to do with it?, whichone is valid? date-time field are a bit
complicated and it is not a good idear to do them unique, that is because
internally those field are stored in databases as long unsigned integer
often the passed seconds since 1982 (the birth of the ibm pc) or even
miliseconds. that means there is always internally a big juggling to format
the date.
Ralph
<ralph_def...@yahoo.de>
"Shawn McKenzie" <nos...@mckenzies.net> wrote in message
news:e9.66.14714.5b80a...@pb1.pair.com...
> Ben Dunlap wrote:
> >> sorry man, but a good data design keeps only data in a table u can not
> >> calculate. in ur case that would be only <date> <start> and <end> time.
> >> refernces to user and project/tasks in other tables.
> >>
> >> ur time sheet is definately a job for a report. that type of design
limits u
> >> to nothing. a user can start ans stop as many times he wants a day or
time
> >> range. u can report any number of time bits to any number of project a
day
> >> or time range
> >
> > I agree (unless the app just doesn't have access to the start/stop
data).
> >
> > Ben
>
> OK, I think I understand most points except the start and stop time.
> Every time sheet I have used, SAP and several other smaller ones, I
> enter a weeks worth of time data like:
>
> Project Sun Mon Tues Wed Thur Fri Sat
> -------------------------------------------------------------------
> Grill steaks 8 8 8 8 0
> Vacation 0 0 0 0 8
>
> So why wouldn't I store the dates and the hours instead of start and
> stop times?
>
> --
> Thanks!
> -Shawn
> http://www.spidean.com
--- End Message ---
--- Begin Message ---
Ralph Deffke wrote:
> as I said, the job is to store a time sheet.
> u came up with:
>
> 1. One record for each 7 day week (year, week_num, d1, d2, d3, d4, d5,
> d6, d7) where the dX field holds the hours worked
> 2. One record for each day (date, hours)
>
> it seems that just the first record is fine. in a data design u dont hold
> the same data twice. so why to use the second record?
>
> if u want to use two tables, then the d1-d7 fields should not be in that
> record.
> if u use the second record it could be that there are two records with the
> same date, what to do with it?, whichone is valid? date-time field are a bit
> complicated and it is not a good idear to do them unique, that is because
> internally those field are stored in databases as long unsigned integer
> often the passed seconds since 1982 (the birth of the ibm pc) or even
> miliseconds. that means there is always internally a big juggling to format
> the date.
>
> Ralph
> <ralph_def...@yahoo.de>
>
> "Shawn McKenzie" <nos...@mckenzies.net> wrote in message
> news:e9.66.14714.5b80a...@pb1.pair.com...
>> Ben Dunlap wrote:
>>>> sorry man, but a good data design keeps only data in a table u can not
>>>> calculate. in ur case that would be only <date> <start> and <end> time.
>>>> refernces to user and project/tasks in other tables.
>>>>
>>>> ur time sheet is definately a job for a report. that type of design
> limits u
>>>> to nothing. a user can start ans stop as many times he wants a day or
> time
>>>> range. u can report any number of time bits to any number of project a
> day
>>>> or time range
>>> I agree (unless the app just doesn't have access to the start/stop
> data).
>>> Ben
>> OK, I think I understand most points except the start and stop time.
>> Every time sheet I have used, SAP and several other smaller ones, I
>> enter a weeks worth of time data like:
>>
>> Project Sun Mon Tues Wed Thur Fri Sat
>> -------------------------------------------------------------------
>> Grill steaks 8 8 8 8 0
>> Vacation 0 0 0 0 8
>>
>> So why wouldn't I store the dates and the hours instead of start and
>> stop times?
>>
>> --
>> Thanks!
>> -Shawn
>> http://www.spidean.com
>
>
In my original post I said those were the two "options", so I would
choose 1 or 2 or something else. Not both.
--
Thanks!
-Shawn
http://www.spidean.com
--- End Message ---
--- Begin Message ---
Ben Dunlap wrote:
>> OK, I think I understand most points except the start and stop time.
>> Every time sheet I have used, SAP and several other smaller ones, I
>> enter a weeks worth of time data like:
>>
>> Project Sun Mon Tues Wed Thur Fri Sat
>> -------------------------------------------------------------------
>> Grill steaks 8 8 8 8 0
>> Vacation 0 0 0 0 8
>>
>> So why wouldn't I store the dates and the hours instead of start and
>> stop times?
>>
>
> Maybe it comes down to what the users of the app prefer (or what you prefer,
> if
> you're building this app for yourself).
>
> From a user's perspective, I like start/stop data-entry better. I love that I
> can do this in Freshbooks, for example -- just click 'start' and then later
> click 'stop', 'log hours' -- and I never have to think about things like "how
> many hours are there between 11:26am and 2:12pm"?
>
> I think Ralph's point was that start/stop data is about as granular as any
> sort
> of time-keeping data gets, so if you store only start/stop data, you have
> ultimate flexibility in the way you can manipulate that data in your app.
>
> And it's probably a reasonable generalization that the most forward-looking
> database designs will store data in as simple and raw a form as possible. Or
> as
> Ralph put it, "a good data design keeps only data in a table u can not
> calculate".
>
> With start/stop data, you could create weekly timesheets like the one above,
> in
> PHP -- and you could also figure out how many hours you log before noon, on
> average, etc.
>
> On the other hand, if the simplest data you enter is already the implicit
> result of a calculation (stop_time - start_time), you've limited the
> flexibility of your app from the get-go. But maybe that limitation isn't
> significant for the app you're building.
>
> Ben
I see. I'm coming at this from an IT consultant perspective, where
you're just like an employee, you work M-F 8 or so hours a day normally.
So really your just filling it out for billing but it would normally be
8 hours M-F sometimes with vacation etc.
--
Thanks!
-Shawn
http://www.spidean.com
--- End Message ---
--- Begin Message ---
On Wed, 5 Aug 2009 09:25:20 -0400, phps...@gmail.com (Bastien Koert) wrote:
>On Wed, Aug 5, 2009 at 8:02 AM, Ashley Sheridan<a...@ashleysheridan.co.uk>
>wrote:
>> On Wed, 2009-08-05 at 21:49 +1000, Clancy wrote:
>>> Thank you to all of you who have commented on this query.
>>>
>>> On the subject of comments, I feel that Larry Garfield settled this query
>>> by pointing out
>>> that halving the size of a particular document gave a barely noticeable
>>> increase in speed.
>>> Paul Foster pointed out the problem of maintenance, but if, as I do, you do
>>> your
>>> development in-house, and then upload the working copies of the program, it
>>> would be
>>> possible to strip out comments when you upload it. If you were really
>>> paranoid, this could
>>> have the advantage that if somebody managed to steal your code from the
>>> server it would be
>>> that much harder for them to understand. On the other hand the process of
>>> stripping out
>>> the comments could potentially introduce new bugs, and I think this
>>> consideration would
>>> outweigh anything else.
>>>
>>> I have recently come to the conclusion that I should never consider
>>> anything completed
>>> until I have analysed the HTML code for an actual page. It is amazing how
>>> badly mangled
>>> tables and the like can be without producing any visible effect on the
>>> page, and on
>>> several occasions I have found PHP error messages which were mixed up with
>>> the HTML in
>>> such a way that they were not displayed at all. On at least one occasion
>>> this gave me the
>>> clue to an otherwise baffling bug.
>>>
>>> I have also discovered that the process of analysing the HTML is made
>>> substantially
>>> simpler by inserting HTML comments into the output; e.g. instead of
>>>
>>> Echo '</td></tr></table></td></tr></table>';
>>> write
>>> ?>
>>> </td></tr></table>
>>> <!-End of table 2 '
>>>
>>> </td></tr></table>
>>> <!-End of table 1 '
>>>
>>> Unfortunately, for HTML readability, it is highly desirable not to indent
>>> the code, and if
>>> you are trying to have nicely indented braces, this makes the PHP code that
>>> much harder to
>>> interpret.
>>>
>>> And on the question of functions there is some virtue (primarily from the
>>> point of view of
>>> maintenance) in not having individual files too large, so while it seems to
>>> be the general
>>> consensus that splitting up functions into groups to give smaller files
>>> will probably slow
>>> things down a bit, if they can be grouped into sets which are only loaded
>>> in particular
>>> circumstances this would be worth doing.
>>>
>>>
>> Nested tables are the devils playthings!
I must be the devil, then. I enjoy playing with them. And if they're done
right they
seem to work on every system I have tried them on. Granted Dreamweaver design
mode gets
its knickers in a knot if you nest them more than about 4 deep.
>>
>> Thanks,
>> Ash
>> http://www.ashleysheridan.co.uk
>>
>>
>> --
>> PHP General Mailing List (http://www.php.net/)
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
>
>I would agree there...we have an app that allows users to create forms
>dynamically with a left and right panel section along with some full
>width plug-in. At a minimum this is built with three nested tables.
>Here's the really rotten part, the VP (original dev for the display
>code) screwed a table close up somewhere. A bug they found literally
>minutes before it when to prod at a client site, instead of giving me
>15 minutes to trace it down, they wrapped the entire table structure
>in another table to make it look pretty.
Clearly he didn't verify the HTML before he released the original version. ;-)
>
>Drives me mental as it produces lots a visual screw up when a certain
>pattern in the form elements is created
That's the joy of HTML errors - often the output will appear normal until you
make some
minor, and apparently irrelevant, change, when it all goes haywire.
--- End Message ---
--- Begin Message ---
On Thu, 2009-08-06 at 09:24 +1000, Clancy wrote:
> On Wed, 5 Aug 2009 09:25:20 -0400, phps...@gmail.com (Bastien Koert) wrote:
>
> >On Wed, Aug 5, 2009 at 8:02 AM, Ashley Sheridan<a...@ashleysheridan.co.uk>
> >wrote:
> >> On Wed, 2009-08-05 at 21:49 +1000, Clancy wrote:
> >>> Thank you to all of you who have commented on this query.
> >>>
> >>> On the subject of comments, I feel that Larry Garfield settled this query
> >>> by pointing out
> >>> that halving the size of a particular document gave a barely noticeable
> >>> increase in speed.
> >>> Paul Foster pointed out the problem of maintenance, but if, as I do, you
> >>> do your
> >>> development in-house, and then upload the working copies of the program,
> >>> it would be
> >>> possible to strip out comments when you upload it. If you were really
> >>> paranoid, this could
> >>> have the advantage that if somebody managed to steal your code from the
> >>> server it would be
> >>> that much harder for them to understand. On the other hand the process of
> >>> stripping out
> >>> the comments could potentially introduce new bugs, and I think this
> >>> consideration would
> >>> outweigh anything else.
> >>>
> >>> I have recently come to the conclusion that I should never consider
> >>> anything completed
> >>> until I have analysed the HTML code for an actual page. It is amazing how
> >>> badly mangled
> >>> tables and the like can be without producing any visible effect on the
> >>> page, and on
> >>> several occasions I have found PHP error messages which were mixed up
> >>> with the HTML in
> >>> such a way that they were not displayed at all. On at least one occasion
> >>> this gave me the
> >>> clue to an otherwise baffling bug.
> >>>
> >>> I have also discovered that the process of analysing the HTML is made
> >>> substantially
> >>> simpler by inserting HTML comments into the output; e.g. instead of
> >>>
> >>> Echo '</td></tr></table></td></tr></table>';
> >>> write
> >>> ?>
> >>> </td></tr></table>
> >>> <!-End of table 2 '
> >>>
> >>> </td></tr></table>
> >>> <!-End of table 1 '
> >>>
> >>> Unfortunately, for HTML readability, it is highly desirable not to indent
> >>> the code, and if
> >>> you are trying to have nicely indented braces, this makes the PHP code
> >>> that much harder to
> >>> interpret.
> >>>
> >>> And on the question of functions there is some virtue (primarily from the
> >>> point of view of
> >>> maintenance) in not having individual files too large, so while it seems
> >>> to be the general
> >>> consensus that splitting up functions into groups to give smaller files
> >>> will probably slow
> >>> things down a bit, if they can be grouped into sets which are only loaded
> >>> in particular
> >>> circumstances this would be worth doing.
> >>>
> >>>
> >> Nested tables are the devils playthings!
>
> I must be the devil, then. I enjoy playing with them. And if they're done
> right they
> seem to work on every system I have tried them on. Granted Dreamweaver
> design mode gets
> its knickers in a knot if you nest them more than about 4 deep.
>
> >>
> >> Thanks,
> >> Ash
> >> http://www.ashleysheridan.co.uk
> >>
> >>
> >> --
> >> PHP General Mailing List (http://www.php.net/)
> >> To unsubscribe, visit: http://www.php.net/unsub.php
> >>
> >>
> >
> >I would agree there...we have an app that allows users to create forms
> >dynamically with a left and right panel section along with some full
> >width plug-in. At a minimum this is built with three nested tables.
> >Here's the really rotten part, the VP (original dev for the display
> >code) screwed a table close up somewhere. A bug they found literally
> >minutes before it when to prod at a client site, instead of giving me
> >15 minutes to trace it down, they wrapped the entire table structure
> >in another table to make it look pretty.
>
> Clearly he didn't verify the HTML before he released the original version. ;-)
> >
> >Drives me mental as it produces lots a visual screw up when a certain
> >pattern in the form elements is created
>
> That's the joy of HTML errors - often the output will appear normal until you
> make some
> minor, and apparently irrelevant, change, when it all goes haywire.
>
>
That's not the only point. If you're on a slow connection you'll notice
the issue. Some browsers only start displaying the page once all the
layout data has been loaded. I've seen some sites with nesting levels of
7 tables deep sometimes, and that's just a mess. I'm also unsure how
text/speech/Braille browsers deal with complex table sites too.
And tables shouldn't be used for layout, use CSS instead!...
Thanks,
Ash
http://www.ashleysheridan.co.uk
--- End Message ---
--- Begin Message ---
as it comes to this point I can recomment an O'reilly book "High Performance
Web Sites, essential knowledge for frontend engineers"
if u read that book ur eyes will grow and u will not bother about php
comments,
ralph
<ralph_def...@yahoo.de>
"Ashley Sheridan" <a...@ashleysheridan.co.uk> wrote in message
news:1249543712.3358.104.ca...@localhost...
> On Thu, 2009-08-06 at 09:24 +1000, Clancy wrote:
> > On Wed, 5 Aug 2009 09:25:20 -0400, phps...@gmail.com (Bastien Koert)
wrote:
> >
> > >On Wed, Aug 5, 2009 at 8:02 AM, Ashley
Sheridan<a...@ashleysheridan.co.uk> wrote:
> > >> On Wed, 2009-08-05 at 21:49 +1000, Clancy wrote:
> > >>> Thank you to all of you who have commented on this query.
> > >>>
> > >>> On the subject of comments, I feel that Larry Garfield settled this
query by pointing out
> > >>> that halving the size of a particular document gave a barely
noticeable increase in speed.
> > >>> Paul Foster pointed out the problem of maintenance, but if, as I do,
you do your
> > >>> development in-house, and then upload the working copies of the
program, it would be
> > >>> possible to strip out comments when you upload it. If you were
really paranoid, this could
> > >>> have the advantage that if somebody managed to steal your code from
the server it would be
> > >>> that much harder for them to understand. On the other hand the
process of stripping out
> > >>> the comments could potentially introduce new bugs, and I think this
consideration would
> > >>> outweigh anything else.
> > >>>
> > >>> I have recently come to the conclusion that I should never consider
anything completed
> > >>> until I have analysed the HTML code for an actual page. It is
amazing how badly mangled
> > >>> tables and the like can be without producing any visible effect on
the page, and on
> > >>> several occasions I have found PHP error messages which were mixed
up with the HTML in
> > >>> such a way that they were not displayed at all. On at least one
occasion this gave me the
> > >>> clue to an otherwise baffling bug.
> > >>>
> > >>> I have also discovered that the process of analysing the HTML is
made substantially
> > >>> simpler by inserting HTML comments into the output; e.g. instead of
> > >>>
> > >>> Echo '</td></tr></table></td></tr></table>';
> > >>> write
> > >>> ?>
> > >>> </td></tr></table>
> > >>> <!-End of table 2 '
> > >>>
> > >>> </td></tr></table>
> > >>> <!-End of table 1 '
> > >>>
> > >>> Unfortunately, for HTML readability, it is highly desirable not to
indent the code, and if
> > >>> you are trying to have nicely indented braces, this makes the PHP
code that much harder to
> > >>> interpret.
> > >>>
> > >>> And on the question of functions there is some virtue (primarily
from the point of view of
> > >>> maintenance) in not having individual files too large, so while it
seems to be the general
> > >>> consensus that splitting up functions into groups to give smaller
files will probably slow
> > >>> things down a bit, if they can be grouped into sets which are only
loaded in particular
> > >>> circumstances this would be worth doing.
> > >>>
> > >>>
> > >> Nested tables are the devils playthings!
> >
> > I must be the devil, then. I enjoy playing with them. And if they're
done right they
> > seem to work on every system I have tried them on. Granted Dreamweaver
design mode gets
> > its knickers in a knot if you nest them more than about 4 deep.
> >
> > >>
> > >> Thanks,
> > >> Ash
> > >> http://www.ashleysheridan.co.uk
> > >>
> > >>
> > >> --
> > >> PHP General Mailing List (http://www.php.net/)
> > >> To unsubscribe, visit: http://www.php.net/unsub.php
> > >>
> > >>
> > >
> > >I would agree there...we have an app that allows users to create forms
> > >dynamically with a left and right panel section along with some full
> > >width plug-in. At a minimum this is built with three nested tables.
> > >Here's the really rotten part, the VP (original dev for the display
> > >code) screwed a table close up somewhere. A bug they found literally
> > >minutes before it when to prod at a client site, instead of giving me
> > >15 minutes to trace it down, they wrapped the entire table structure
> > >in another table to make it look pretty.
> >
> > Clearly he didn't verify the HTML before he released the original
version. ;-)
> > >
> > >Drives me mental as it produces lots a visual screw up when a certain
> > >pattern in the form elements is created
> >
> > That's the joy of HTML errors - often the output will appear normal
until you make some
> > minor, and apparently irrelevant, change, when it all goes haywire.
> >
> >
> That's not the only point. If you're on a slow connection you'll notice
> the issue. Some browsers only start displaying the page once all the
> layout data has been loaded. I've seen some sites with nesting levels of
> 7 tables deep sometimes, and that's just a mess. I'm also unsure how
> text/speech/Braille browsers deal with complex table sites too.
>
> And tables shouldn't be used for layout, use CSS instead!...
>
> Thanks,
> Ash
> http://www.ashleysheridan.co.uk
>
--- End Message ---
--- Begin Message ---
On Thu, 2009-08-06 at 12:05 +0200, Ralph Deffke wrote:
> as it comes to this point I can recomment an O'reilly book "High Performance
> Web Sites, essential knowledge for frontend engineers"
>
> if u read that book ur eyes will grow and u will not bother about php
> comments,
>
> ralph
> <ralph_def...@yahoo.de>
>
> "Ashley Sheridan" <a...@ashleysheridan.co.uk> wrote in message
> news:1249543712.3358.104.ca...@localhost...
> > On Thu, 2009-08-06 at 09:24 +1000, Clancy wrote:
> > > On Wed, 5 Aug 2009 09:25:20 -0400, phps...@gmail.com (Bastien Koert)
> wrote:
> > >
> > > >On Wed, Aug 5, 2009 at 8:02 AM, Ashley
> Sheridan<a...@ashleysheridan.co.uk> wrote:
> > > >> On Wed, 2009-08-05 at 21:49 +1000, Clancy wrote:
> > > >>> Thank you to all of you who have commented on this query.
> > > >>>
> > > >>> On the subject of comments, I feel that Larry Garfield settled this
> query by pointing out
> > > >>> that halving the size of a particular document gave a barely
> noticeable increase in speed.
> > > >>> Paul Foster pointed out the problem of maintenance, but if, as I do,
> you do your
> > > >>> development in-house, and then upload the working copies of the
> program, it would be
> > > >>> possible to strip out comments when you upload it. If you were
> really paranoid, this could
> > > >>> have the advantage that if somebody managed to steal your code from
> the server it would be
> > > >>> that much harder for them to understand. On the other hand the
> process of stripping out
> > > >>> the comments could potentially introduce new bugs, and I think this
> consideration would
> > > >>> outweigh anything else.
> > > >>>
> > > >>> I have recently come to the conclusion that I should never consider
> anything completed
> > > >>> until I have analysed the HTML code for an actual page. It is
> amazing how badly mangled
> > > >>> tables and the like can be without producing any visible effect on
> the page, and on
> > > >>> several occasions I have found PHP error messages which were mixed
> up with the HTML in
> > > >>> such a way that they were not displayed at all. On at least one
> occasion this gave me the
> > > >>> clue to an otherwise baffling bug.
> > > >>>
> > > >>> I have also discovered that the process of analysing the HTML is
> made substantially
> > > >>> simpler by inserting HTML comments into the output; e.g. instead of
> > > >>>
> > > >>> Echo '</td></tr></table></td></tr></table>';
> > > >>> write
> > > >>> ?>
> > > >>> </td></tr></table>
> > > >>> <!-End of table 2 '
> > > >>>
> > > >>> </td></tr></table>
> > > >>> <!-End of table 1 '
> > > >>>
> > > >>> Unfortunately, for HTML readability, it is highly desirable not to
> indent the code, and if
> > > >>> you are trying to have nicely indented braces, this makes the PHP
> code that much harder to
> > > >>> interpret.
> > > >>>
> > > >>> And on the question of functions there is some virtue (primarily
> from the point of view of
> > > >>> maintenance) in not having individual files too large, so while it
> seems to be the general
> > > >>> consensus that splitting up functions into groups to give smaller
> files will probably slow
> > > >>> things down a bit, if they can be grouped into sets which are only
> loaded in particular
> > > >>> circumstances this would be worth doing.
> > > >>>
> > > >>>
> > > >> Nested tables are the devils playthings!
> > >
> > > I must be the devil, then. I enjoy playing with them. And if they're
> done right they
> > > seem to work on every system I have tried them on. Granted Dreamweaver
> design mode gets
> > > its knickers in a knot if you nest them more than about 4 deep.
> > >
> > > >>
> > > >> Thanks,
> > > >> Ash
> > > >> http://www.ashleysheridan.co.uk
> > > >>
> > > >>
> > > >> --
> > > >> PHP General Mailing List (http://www.php.net/)
> > > >> To unsubscribe, visit: http://www.php.net/unsub.php
> > > >>
> > > >>
> > > >
> > > >I would agree there...we have an app that allows users to create forms
> > > >dynamically with a left and right panel section along with some full
> > > >width plug-in. At a minimum this is built with three nested tables.
> > > >Here's the really rotten part, the VP (original dev for the display
> > > >code) screwed a table close up somewhere. A bug they found literally
> > > >minutes before it when to prod at a client site, instead of giving me
> > > >15 minutes to trace it down, they wrapped the entire table structure
> > > >in another table to make it look pretty.
> > >
> > > Clearly he didn't verify the HTML before he released the original
> version. ;-)
> > > >
> > > >Drives me mental as it produces lots a visual screw up when a certain
> > > >pattern in the form elements is created
> > >
> > > That's the joy of HTML errors - often the output will appear normal
> until you make some
> > > minor, and apparently irrelevant, change, when it all goes haywire.
> > >
> > >
> > That's not the only point. If you're on a slow connection you'll notice
> > the issue. Some browsers only start displaying the page once all the
> > layout data has been loaded. I've seen some sites with nesting levels of
> > 7 tables deep sometimes, and that's just a mess. I'm also unsure how
> > text/speech/Braille browsers deal with complex table sites too.
> >
> > And tables shouldn't be used for layout, use CSS instead!...
> >
> > Thanks,
> > Ash
> > http://www.ashleysheridan.co.uk
> >
>
>
>
Are you seriously suggesting one shouldn't comment their PHP code?!
Thanks,
Ash
http://www.ashleysheridan.co.uk
--- End Message ---
--- Begin Message ---
You can use variable variables
...
You can make more complicated statements with this technique.
$var1 = 'apple';
${ 'Fruit_' . $var1 } = 'organic';
echo $Fruit_apple; // here you are
thank you all 3, for your help!
That was just what I wanted!
-Govinda
--- End Message ---
--- Begin Message ---
On Wed, 5 Aug 2009 16:17:26 -0600, Govinda wrote:
> I want to do this:
> (I am just assuming it won't work; I haven't even tried it yet)
>
> $var1='apple';
> $Fruit_$var1="organic";
> echo "$Fruit_apple"; // I want this to return "organic"
>
> Or how are you guys dynamically naming PHP vars on the fly?
Others have mentioned variable variables. While I have
used those, I tend to prefer arrays:
$var1 = 'apple';
$fruits[$var1] = 'organic';
echo $fruits[$var1];
/Nisse
--- End Message ---
--- Begin Message ---
Has anyone read this book by Larry Ullman yet? If so, what do you
think about it? I'm looking for a well-rounded book that covers PHP
for e-commerce websites and from what little I've been able to find
online, it looks pretty good. Or would you recommend another book?
I know that no book has all the answers - I just want something in my
hands to read. However, I've bought a few Perl books that were a
waste of money, so this time, I thought I'd ask first.
Thanks,
Frank
--- End Message ---
--- Begin Message ---
why do u stick to php 6?
i would recommend www.scribd.com and have a search on PHP. there are books
on beginners for php5 and articles of the difference to php 6.
a very usefull site by the way, made me stopping buying books. loads of
material on IT stuff.
ralph
ralph_def...@yahoo.de
<sono...@fannullone.us> wrote in message
news:43bda83e-2383-48a8-87ca-4408244fa...@fannullone.us...
> Has anyone read this book by Larry Ullman yet? If so, what do you
> think about it? I'm looking for a well-rounded book that covers PHP
> for e-commerce websites and from what little I've been able to find
> online, it looks pretty good. Or would you recommend another book?
>
> I know that no book has all the answers - I just want something in my
> hands to read. However, I've bought a few Perl books that were a
> waste of money, so this time, I thought I'd ask first.
>
> Thanks,
> Frank
--- End Message ---
--- Begin Message ---
On Thu, 2009-08-06 at 02:55 +0200, Ralph Deffke wrote:
> why do u stick to php 6?
>
> i would recommend www.scribd.com and have a search on PHP. there are books
> on beginners for php5 and articles of the difference to php 6.
>
> a very usefull site by the way, made me stopping buying books. loads of
> material on IT stuff.
>
> ralph
> ralph_def...@yahoo.de
>
> <sono...@fannullone.us> wrote in message
> news:43bda83e-2383-48a8-87ca-4408244fa...@fannullone.us...
> > Has anyone read this book by Larry Ullman yet? If so, what do you
> > think about it? I'm looking for a well-rounded book that covers PHP
> > for e-commerce websites and from what little I've been able to find
> > online, it looks pretty good. Or would you recommend another book?
> >
> > I know that no book has all the answers - I just want something in my
> > hands to read. However, I've bought a few Perl books that were a
> > waste of money, so this time, I thought I'd ask first.
> >
> > Thanks,
> > Frank
>
>
>
I'd focus on PHP 5 more than 6 just now, as the majority of hosting
companies out there are still only offering PHP 5 installations.
Learning 6 without learning 5 could lead you into some very interesting
conversations with clients!
Thanks,
Ash
http://www.ashleysheridan.co.uk
--- End Message ---
--- Begin Message ---
I am new to php...
I try to make a php page that displays form submitted data and image. There
are 3 php files,
tampil_tamu_admin.php, edit_tamu.php and display_img.php.
The user lists are displayed in the tampil_tamu_admin.php, and when the user
clicks one record, it shows edit page (edit_tamu.php) that display user data
and picture. (edit_tamu.php file includes img tag that calls display_img.php
with user id)
The problem is the user data is displayed but the image is not displayed...
How can I display this image ?
The codes are attached
Thanks http://www.nabble.com/file/p24839092/guest-book.rar guest-book.rar
http://www.nabble.com/file/p24839092/guest-book.zip guest-book.zip
--
View this message in context:
http://www.nabble.com/Displaying-user-data-and-picture-tp24839092p24839092.html
Sent from the PHP - General mailing list archive at Nabble.com.
--- End Message ---
--- Begin Message ---
On Wed, Aug 05, 2009 at 02:55:07PM -0700, Ben Dunlap wrote:
> > In my navigation.php include file, I had if ($page = about) echo href....
> > I changed it to if ($page == about) echo.... and it suddenly
> worked! Imagine
> > that...
>
> Another good case for putting the variable on the right side of "==":
>
> if ("about" == $page)
>
> Then if you mis-type "==" as "=", PHP will fail immediately with a parse
> error.
>
> It feels a little weird but if it saves a lot of head-desk moments it's
> probably worth it. Now if only I could get into the habit myself...
This is common practice for a lot of C programmers for exactly this
reason.
Paul
--
Paul M. Foster
--- End Message ---
--- Begin Message ---
Miller, Terion wrote:
Shawn you know repeatedly have been nothing but an asshole to me on this list,
I have said before I'm not a php programmer, I was a front end designer, need
graphics , need a css layout...see me....need backend programming..I'm trying...
Stop being such a egomaniacal dickhead, a social life may do you good.
If your job description does not include php development, and they are
asking you to do it, then ask them to pay for the necessary books for
you to learn PHP or do not accept the assignment, pointing out that you
are not a PHP developer.
If you job description includes php development, then you need to know
what you are doing.
--- End Message ---
--- Begin Message ---
Double your chances of winning at Euro Club Casino! http://2domainfun.com/
--- End Message ---
--- Begin Message ---
> > > Well, I try not to give out my details to too many people each month,
> > > and this month they were beat to it by a nice fellow in Nigeria who I'm
> > > helping out by letting him put some money into my account.
Hello Ash,
Could that be termed as "aiding and abetting" that 'nice fellow from Nigeria'?.
Let me know your term for it and while you're at it, could you not spend the
money?
Cheers.
Alugo Abdulazeez
Greetings from Nigeria.
_________________________________________________________________
Share your memories online with anyone you want.
http://www.microsoft.com/middleeast/windows/windowslive/products/photos-share.aspx?tab=1
--- End Message ---
