php-general Digest 13 Dec 2010 07:42:51 -0000 Issue 7084
Topics (messages 309986 through 309999):
Re: ORM doctrine
309986 by: Nathan Rixham
309989 by: Tommy Pham
309990 by: Tommy Pham
309992 by: Nathan Rixham
309995 by: Tommy Pham
309997 by: Tommy Pham
309999 by: Lester Caine
Re: code quest - ECHO?!?
309987 by: Alexandru Patranescu
309988 by: [email protected]
Parsing a phrase
309991 by: Rick Dwyer
309993 by: Nathan Rixham
309994 by: Rick Dwyer
309996 by: Rick Dwyer
Re: Scalable Vector Graphics with PHP
309998 by: sudarshana sampath
Administrivia:
To subscribe to the digest, e-mail:
[email protected]
To unsubscribe from the digest, e-mail:
[email protected]
To post to the list, e-mail:
[email protected]
----------------------------------------------------------------------
--- Begin Message ---
Lester Caine wrote:
For fixed pages this is the best way of handling the information. And
handling those fixed pages is ... from my point of view ... not a
problem since they can be cached at that level, or even stored locally
in the browser cache. I've just been hitting re-load every time for a
few updates I've just been processing! In order to actually see the
result. But for the majority of my work, the data to be displayed is
being rebuilt with every browser hit. In that case generating dynamic
pages fast becomes the bottleneck.
If you've got an example, and you'd like to know how to approach these
problems, I'd be happy to go through the process of making these always
dynamic pages HTTP friendly with you :) (and on the list or in private)
Best,
Nathan
--- End Message ---
--- Begin Message ---
> -----Original Message-----
> From: Nathan Rixham [mailto:[email protected]]
> Sent: Sunday, December 12, 2010 8:23 AM
> To: Tommy Pham
> Cc: 'Peter Lind'; [email protected]; 'Lester Caine'
> Subject: Re: [PHP] ORM doctrine
>
> Tommy Pham wrote:
> >> -----Original Message-----
> >> From: Peter Lind [mailto:[email protected]]
> >> Sent: Sunday, December 12, 2010 5:27 AM
> >> To: Lester Caine
> >> Cc: [email protected]
> >> Subject: Re: [PHP] ORM doctrine
> >>
> >
> > <snip>
> >
> >>> The reason for 'caching' needs to be understood before it is applied
> >>> in
> >> order to avoid the black holes that random caching is causing
> >> nowadays already. How often do you hear "wipe the xxx browser cache"?
> >> And I know if I am changing theme elements in bitweaver or phpgedview
> >> then I HAVE to wipe the cache to ensure that smarty rebuilds the relevant
> pages.
> >>
> >> Which underlines my point: caching is not icing on the cake but
> >> should be thought of sooner in the process, contrary to Tommys point.
> >>
> >
> > If the app is well designed, then you still could implement it later w/o
> major rewrite.
>
> It's only well designed if caching is considered from the start - thus, as
> Peter
> says, caching is not the icing on the cake, but should, must, be thought of in
> the initial design process - if it's not, then the app isn't well designed.
I'll take a crack at it ;)
Bare minimum:
- parseRequest();
- fetchData();
- output();
With auth / acl:
parseRequest()
{
// parse
// add auth/acl and redirect accordingly
}
fetchData();
output();
With auth/acl + cache:
parseRequest()
{
// parse
// add auth/acl and redirect accordingly
}
fetchData()
{
If ($useCache) getCache();
else getFromDB();
}
output();
That seems to me as a minor rewrite with lots of additional modules from bare
minimum to auth/acl+cache, as I've stated before with the points: Understand
the problem, understand the objective + possible growth/expansion, app design
(framework and what not). So whether I choose to implement cache is relevant,
IMO, because data to me is either cache or from DB depending in specific cases
(which is handle by the caching module). If from cache, that's the cache
management problem (a shortcomings).
Regards,
Tommy
--- End Message ---
--- Begin Message ---
> -----Original Message-----
> From: Bastien [mailto:[email protected]]
> Sent: Sunday, December 12, 2010 9:20 AM
> To: Nathan Rixham
> Cc: Lester Caine; php-general List
> Subject: Re: [PHP] ORM doctrine
>
>
>
> On 2010-12-12, at 11:45 AM, Nathan Rixham <[email protected]> wrote:
>
> > Lester Caine wrote:
> >> Nathan Rixham wrote:
> >>> In your application itself, caching can be introduced at every
> >>> level, you've already got filesystem io caches provided by the
> >>> operating system, a well tuned db server cache can make a big
> >>> difference as well, then on to opcode caches in languages like PHP
> >>> since it's interpreted rather than compiled, and then on to code
> >>> optimizations such as using static class cache's behind getByID
> >>> methods and similar, and finally down to micro optimizations, static
> >>> code analysis and dead code elimination, replacing (4*10) with (40),
> >>> inlining static class members / constants and such like. Finally,
> >>> language specific nuances and micro optimizations.
> >> Actually THAT probably sums things up nicely. An approach suitable for
> MySQL WILL probably be wrong for Postgres or Firebird. Certainly the
> optimised SQL I use for my own applications is much improved if I simply
> ignore compatibility with the databases other developers are using.
> Libraries like doctrine and even PDO are probably not using the best
> approach that a database specific approch may take. Firebird will maintain
> the 'results' of previous searches in cache and give results sets a lot
faster,
> such as being ready to return the next page of results BEFORE the web page
> asks for it ;) But a database agnostic approach is not as efficient.
> >
> > Yes, but you snipped a key paragraph there, because all the forms of
> caching and optimization listed above, including db cache optimization
will
> only increase performance of the app by small percentages, whereas
> moving to a publishing model and producing static output will increase
> performance by several factors:
> >
> > [[[
> > As a web developer, the most important interface you need to introduce
> caching on, is HTTP - a "static" or "published" HTML document which
> leverages HTTP caching using Last-Modified / ETag headers will give circa
> 100 times better performance (or more) than a dynamically generated each
> time doc. Not only that, but transparent proxies on the network can come
in
> to effect and reduce weight on the server to zero, and further, web
> browsers will serve repeat requests to the document straight from RAM,
> again leading to zero weight. When you include those two factors it
doesn't
> take long to see that the performance difference over the network is so
> good that it's nigh on unmeasurable.
> > ]]]
> >
> > Feel free to ignore this yourself, but please don't promote a bit of SQL
and
> db server optimization as being the most important factor in optimizing
PHP
> applications, it is important, but the net result is minimal in comparison
to
> leveraging HTTP caching and static publishing of components or entire
> documents.
> >
> > Best,
> >
> > Nathan
> >
> > --
> > PHP General Mailing List (http://www.php.net/) To unsubscribe, visit:
> > http://www.php.net/unsub.php
> >
>
> I would definitely agree with Nathan here. In our classic asp (don't ask)
the
> vp of our company designed a survey app ( poorly I might add ) that
> dynamically generated the form and all of it's associated drop downs
> including the locations ( some 2000 of them ). The client was requiring
1000
> user concurrency and the app as it was only handled 10 users. I re-
> architected the app to cache out the form since it was identical for each
> user, and we easily hit the required benchmark.
You're just proving the points I made. The app was poorly designed because
he/she didn't truly understand my point #2: understand the objective +
possible growth/expansion. Also, mostly like that he/she didn't fully
understand point #1: understand the problem (needs of the business,
programming language in use, etc). Failing both points 1 & 2 will make
point 3 even far worse. Hence you had to 're-architect'.
Regards,
Tommy
>
> Form caching is one of the most important omptimizations that can be made
> ( especially in our app where a major ( and I am not allowed to fix it )
design
> flaw loops through the form and associated data set 4 ( yes, 4! ) times
and
> nothing is cached ).
>
> Db calls are expensive but not as expensive as extremely poor design!
>
> Bastien Koert
>
> Sent from my iPhone
> --
--- End Message ---
--- Begin Message ---
Tommy Pham wrote:
-----Original Message-----
From: Nathan Rixham [mailto:[email protected]]
Sent: Sunday, December 12, 2010 8:23 AM
To: Tommy Pham
Cc: 'Peter Lind'; [email protected]; 'Lester Caine'
Subject: Re: [PHP] ORM doctrine
Tommy Pham wrote:
-----Original Message-----
From: Peter Lind [mailto:[email protected]]
Sent: Sunday, December 12, 2010 5:27 AM
To: Lester Caine
Cc: [email protected]
Subject: Re: [PHP] ORM doctrine
<snip>
The reason for 'caching' needs to be understood before it is applied
in
order to avoid the black holes that random caching is causing
nowadays already. How often do you hear "wipe the xxx browser cache"?
And I know if I am changing theme elements in bitweaver or phpgedview
then I HAVE to wipe the cache to ensure that smarty rebuilds the relevant
pages.
Which underlines my point: caching is not icing on the cake but
should be thought of sooner in the process, contrary to Tommys point.
If the app is well designed, then you still could implement it later w/o
major rewrite.
It's only well designed if caching is considered from the start - thus, as Peter
says, caching is not the icing on the cake, but should, must, be thought of in
the initial design process - if it's not, then the app isn't well designed.
I'll take a crack at it ;)
Bare minimum:
- parseRequest();
- fetchData();
- output();
With auth / acl:
parseRequest()
{
// parse
// add auth/acl and redirect accordingly
}
fetchData();
output();
With auth/acl + cache:
parseRequest()
{
// parse
// add auth/acl and redirect accordingly
}
fetchData()
{
If ($useCache) getCache();
else getFromDB();
}
output();
That seems to me as a minor rewrite with lots of additional modules from bare
minimum to auth/acl+cache, as I've stated before with the points: Understand
the problem, understand the objective + possible growth/expansion, app design
(framework and what not). So whether I choose to implement cache is relevant,
IMO, because data to me is either cache or from DB depending in specific cases
(which is handle by the caching module). If from cache, that's the cache
management problem (a shortcomings).
That is only one form of relatively minor caching, and you've already
missed most of the opportunities because you're already in a dynamic
application / script environment there... try scoping out to the bigger
picture here:
3 UI instances with 2 different presentation tiers
2 Application instances
1 db instance
And here are pretty much the full entry points
GET /something HTTP/1.1
POST /processor HTTP/1.1
You're job is to respond to those calls as quickly as possible,
Here are six simple interface edges you can cache on:
1
--------------http---------------
2 | | |
UI UI UI
3 | | |
------------------------------
4 | |
App App
5 | |
--------------
6 |
DB
You're talking about caching 5 or 6 levels down, thus already missing 4
other opportunities, which are exponentially more important.
Best,
Nathan
--- End Message ---
--- Begin Message ---
> -----Original Message-----
> From: Nathan Rixham [mailto:[email protected]]
> Sent: Sunday, December 12, 2010 11:41 AM
> To: Tommy Pham
> Cc: 'Peter Lind'; [email protected]; 'Lester Caine'
> Subject: Re: [PHP] ORM doctrine
>
> Tommy Pham wrote:
> >> -----Original Message-----
> >> From: Nathan Rixham [mailto:[email protected]]
> >> Sent: Sunday, December 12, 2010 8:23 AM
> >> To: Tommy Pham
> >> Cc: 'Peter Lind'; [email protected]; 'Lester Caine'
> >> Subject: Re: [PHP] ORM doctrine
> >>
> >> Tommy Pham wrote:
> >>>> -----Original Message-----
> >>>> From: Peter Lind [mailto:[email protected]]
> >>>> Sent: Sunday, December 12, 2010 5:27 AM
> >>>> To: Lester Caine
> >>>> Cc: [email protected]
> >>>> Subject: Re: [PHP] ORM doctrine
> >>>>
> >>> <snip>
> >>>
> >>>>> The reason for 'caching' needs to be understood before it is
> >>>>> applied in
> >>>> order to avoid the black holes that random caching is causing
> >>>> nowadays already. How often do you hear "wipe the xxx browser
> cache"?
> >>>> And I know if I am changing theme elements in bitweaver or
> >>>> phpgedview then I HAVE to wipe the cache to ensure that smarty
> >>>> rebuilds the relevant
> >> pages.
> >>>> Which underlines my point: caching is not icing on the cake but
> >>>> should be thought of sooner in the process, contrary to Tommys point.
> >>>>
> >>> If the app is well designed, then you still could implement it later
> >>> w/o
> >> major rewrite.
> >>
> >> It's only well designed if caching is considered from the start -
> >> thus, as Peter says, caching is not the icing on the cake, but
> >> should, must, be thought of in the initial design process - if it's not,
> >> then
> the app isn't well designed.
> >
> > I'll take a crack at it ;)
> >
> > Bare minimum:
> > - parseRequest();
> > - fetchData();
> > - output();
> >
> > With auth / acl:
> > parseRequest()
> > {
> > // parse
> > // add auth/acl and redirect accordingly } fetchData(); output();
> >
> > With auth/acl + cache:
> > parseRequest()
> > {
> > // parse
> > // add auth/acl and redirect accordingly }
> > fetchData()
> > {
> > If ($useCache) getCache();
> > else getFromDB();
> > }
> > output();
> >
> > That seems to me as a minor rewrite with lots of additional modules from
> bare minimum to auth/acl+cache, as I've stated before with the points:
> Understand the problem, understand the objective + possible
> growth/expansion, app design (framework and what not). So whether I
> choose to implement cache is relevant, IMO, because data to me is either
> cache or from DB depending in specific cases (which is handle by the caching
> module). If from cache, that's the cache management problem (a
> shortcomings).
>
> That is only one form of relatively minor caching, and you've already missed
> most of the opportunities because you're already in a dynamic application /
> script environment there... try scoping out to the bigger picture here:
>
> 3 UI instances with 2 different presentation tiers
> 2 Application instances
> 1 db instance
>
> And here are pretty much the full entry points
>
> GET /something HTTP/1.1
>
> POST /processor HTTP/1.1
>
> You're job is to respond to those calls as quickly as possible,
>
> Here are six simple interface edges you can cache on:
>
> 1
> --------------http---------------
> 2 | | |
> UI UI UI
> 3 | | |
> ------------------------------
> 4 | |
> App App
> 5 | |
> --------------
> 6 |
> DB
>
> You're talking about caching 5 or 6 levels down, thus already missing 4 other
> opportunities, which are exponentially more important.
>
> Best,
>
> Nathan
Example, user never been to site before and found link on google. 1st thing
that has to be done is to insure that url is valid format and not something
like /goto/here/../try/to/hack/your/server or induce some other URL hacking to
create a buffer overflow. Does this involve cache? Hence parseRequest().
Second, if the URL is valid, check if the user is logged in and authorized? If
the user is authorized, continue processing the request and get the data.
Thus: if ($useCache) getCache(); /* handles by cache module for all that’s
needed static/dynamic */ else getFromDb();. Finally, output() is responsible
for transmitting the info whether it was from cache or DB. Such as if
$countries represents the list of countries, then both cache & db should return
the exact values (provided no change since last cache fetch). Now that the
user has been to the site and clicks on a link on the page which sends request
back. Again, parseRequest(); fetchData(); and the cache module within the
fetchData() has to determine where to get the required data... again - cache
management problem. And so on so forth... Whether is caching is done via local
filesystem on the webserver or via apc or via memcached... that's all the
'cache' module problem to me. As for levels down, the fetchData() is already
considered as 1st leve, IMO, one need to ensure of valid request and authorized
permission before any data retrieval is done, whether from cache or DB. The
internal workings between data objects and/or arrays and the output is program
flow design. Now if you're to include some AJAX async calls, each call should
be treated just same... valid URL? Authorized user? Then finally fetchData();
As for whether something that's common to all or not such as list countries,
and if it's to get from cache, then that's the cache management problem (as
I've said, shortcoming). If it's from DB, DB is already cached. Case in
point, I run a 2 table join query for 3k+ categories on MySQL workbench. 1st
time execution: duration .125 sec/ fetch .032 sec. 2nd time execution after a
query of manufacturers: duration 0/ fetch 0. 3rd time execution on a separate
instance of workbench: duration 0 / fetch 0.
Regards,
Tommy
Disclaimer: data in this context is considered as anything that's not 100%
static images, css, js, etc... files. Whether it's PHP generating 100% of the
form input, generated PDF doc, fetching a list rows from a particular table in
the DB, etc., what's get cached or not depends all on the cache module and its
cache management inside the fetchData().
--- End Message ---
--- Begin Message ---
> -----Original Message-----
> From: Tommy Pham [mailto:[email protected]]
> Sent: Sunday, December 12, 2010 12:53 PM
> To: '[email protected]'
> Cc: 'Peter Lind'; '[email protected]'; 'Lester Caine'
> Subject: RE: [PHP] ORM doctrine
>
> > -----Original Message-----
> > From: Nathan Rixham [mailto:[email protected]]
> > Sent: Sunday, December 12, 2010 11:41 AM
> > To: Tommy Pham
> > Cc: 'Peter Lind'; [email protected]; 'Lester Caine'
> > Subject: Re: [PHP] ORM doctrine
> >
> > Tommy Pham wrote:
> > >> -----Original Message-----
> > >> From: Nathan Rixham [mailto:[email protected]]
> > >> Sent: Sunday, December 12, 2010 8:23 AM
> > >> To: Tommy Pham
> > >> Cc: 'Peter Lind'; [email protected]; 'Lester Caine'
> > >> Subject: Re: [PHP] ORM doctrine
> > >>
> > >> Tommy Pham wrote:
> > >>>> -----Original Message-----
> > >>>> From: Peter Lind [mailto:[email protected]]
> > >>>> Sent: Sunday, December 12, 2010 5:27 AM
> > >>>> To: Lester Caine
> > >>>> Cc: [email protected]
> > >>>> Subject: Re: [PHP] ORM doctrine
> > >>>>
> > >>> <snip>
> > >>>
> > >>>>> The reason for 'caching' needs to be understood before it is
> > >>>>> applied in
> > >>>> order to avoid the black holes that random caching is causing
> > >>>> nowadays already. How often do you hear "wipe the xxx browser
> > cache"?
> > >>>> And I know if I am changing theme elements in bitweaver or
> > >>>> phpgedview then I HAVE to wipe the cache to ensure that smarty
> > >>>> rebuilds the relevant
> > >> pages.
> > >>>> Which underlines my point: caching is not icing on the cake but
> > >>>> should be thought of sooner in the process, contrary to Tommys
> point.
> > >>>>
> > >>> If the app is well designed, then you still could implement it
> > >>> later w/o
> > >> major rewrite.
> > >>
> > >> It's only well designed if caching is considered from the start -
> > >> thus, as Peter says, caching is not the icing on the cake, but
> > >> should, must, be thought of in the initial design process - if it's
> > >> not, then
> > the app isn't well designed.
> > >
> > > I'll take a crack at it ;)
> > >
> > > Bare minimum:
> > > - parseRequest();
> > > - fetchData();
> > > - output();
> > >
> > > With auth / acl:
> > > parseRequest()
> > > {
> > > // parse
> > > // add auth/acl and redirect accordingly } fetchData(); output();
> > >
> > > With auth/acl + cache:
> > > parseRequest()
> > > {
> > > // parse
> > > // add auth/acl and redirect accordingly }
> > > fetchData()
> > > {
> > > If ($useCache) getCache();
> > > else getFromDB();
> > > }
> > > output();
> > >
> > > That seems to me as a minor rewrite with lots of additional modules
> > > from
> > bare minimum to auth/acl+cache, as I've stated before with the points:
> > Understand the problem, understand the objective + possible
> > growth/expansion, app design (framework and what not). So whether I
> > choose to implement cache is relevant, IMO, because data to me is
That's supposed to say 'cache is irrelevant'. Time for me to hit the sack....
I've been up about 23 hours w/o caffeine :D
> > either cache or from DB depending in specific cases (which is handle
> > by the caching module). If from cache, that's the cache management
> > problem (a shortcomings).
> >
> > That is only one form of relatively minor caching, and you've already
> > missed most of the opportunities because you're already in a dynamic
> > application / script environment there... try scoping out to the bigger
> picture here:
> >
> > 3 UI instances with 2 different presentation tiers
> > 2 Application instances
> > 1 db instance
> >
> > And here are pretty much the full entry points
> >
> > GET /something HTTP/1.1
> >
> > POST /processor HTTP/1.1
> >
> > You're job is to respond to those calls as quickly as possible,
> >
> > Here are six simple interface edges you can cache on:
> >
> > 1
> > --------------http---------------
> > 2 | | |
> > UI UI UI
> > 3 | | |
> > ------------------------------
> > 4 | |
> > App App
> > 5 | |
> > --------------
> > 6 |
> > DB
> >
> > You're talking about caching 5 or 6 levels down, thus already missing
> > 4 other opportunities, which are exponentially more important.
> >
> > Best,
> >
> > Nathan
>
> Example, user never been to site before and found link on google. 1st thing
> that has to be done is to insure that url is valid format and not something
> like /goto/here/../try/to/hack/your/server or induce some other URL
> hacking to create a buffer overflow. Does this involve cache? Hence
> parseRequest(). Second, if the URL is valid, check if the user is logged in
> and authorized? If the user is authorized, continue processing the request
> and get the data. Thus: if ($useCache) getCache(); /* handles by cache
> module for all that’s needed static/dynamic */ else getFromDb();. Finally,
> output() is responsible for transmitting the info whether it was from cache
> or DB. Such as if $countries represents the list of countries, then both cache
> & db should return the exact values (provided no change since last cache
> fetch). Now that the user has been to the site and clicks on a link on the
> page which sends request back. Again, parseRequest(); fetchData(); and
> the cache module within the fetchData() has to determine where to get the
> required data... again - cache management problem. And so on so forth...
> Whether is caching is done via local filesystem on the webserver or via apc
> or via memcached... that's all the 'cache' module problem to me. As for
> levels down, the fetchData() is already considered as 1st leve, IMO, one
> need to ensure of valid request and authorized permission before any data
> retrieval is done, whether from cache or DB. The internal workings
> between data objects and/or arrays and the output is program flow design.
> Now if you're to include some AJAX async calls, each call should be treated
> just same... valid URL? Authorized user? Then finally fetchData();
>
> As for whether something that's common to all or not such as list countries,
> and if it's to get from cache, then that's the cache management problem (as
> I've said, shortcoming). If it's from DB, DB is already cached. Case in
> point, I
> run a 2 table join query for 3k+ categories on MySQL workbench. 1st time
> execution: duration .125 sec/ fetch .032 sec. 2nd time execution after a
> query of manufacturers: duration 0/ fetch 0. 3rd time execution on a
> separate instance of workbench: duration 0 / fetch 0.
>
> Regards,
> Tommy
>
> Disclaimer: data in this context is considered as anything that's not 100%
> static images, css, js, etc... files. Whether it's PHP generating 100% of the
> form input, generated PDF doc, fetching a list rows from a particular table in
> the DB, etc., what's get cached or not depends all on the cache module and
> its cache management inside the fetchData().
--- End Message ---
--- Begin Message ---
Nathan Rixham wrote:
For fixed pages this is the best way of handling the information. And
handling those fixed pages is ... from my point of view ... not a
problem since they can be cached at that level, or even stored locally
in the browser cache. I've just been hitting re-load every time for a
few updates I've just been processing! In order to actually see the
result. But for the majority of my work, the data to be displayed is
being rebuilt with every browser hit. In that case generating dynamic
pages fast becomes the bottleneck.
If you've got an example, and you'd like to know how to approach these
problems, I'd be happy to go through the process of making these always
dynamic pages HTTP friendly with you :) (and on the list or in private)
I'm quite happy with my current page generating process, but we are always
looking for ways of improving the base bitweaver framework. When the original
port was done from tikiwiki, we changed from a large percentage of processing
time accessing the database to establish even if a user was allowed to access a
page to something a lot more responsive and a lot less sensitive to DOS attack.
Certainly improving the 'static' base on which the dynamic information is laid
is an area where page generation times could be reduced.
doctrine is an abstraction layer that I had a play with some time back, but in
many cases we are building a multi-table query that returns all of the data in a
single result set ... including the selected security model ... and that is
something that ORM does not seem to provide an easy access to? But I stand to be
corrected on that.
--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php
--- End Message ---
--- Begin Message ---
They are almost identical.
Echo supports multiple parameters like "echo $a, $b;"
print is 20% slower than echo (by some tests).
"echo" is shorter than "print" so it's easy to write.
In fact it's all a matter of taste. The same reason we user die instead of
exit.
Alex
On Sun, Dec 12, 2010 at 6:23 PM, Kirk Bailey <[email protected]>wrote:
> Groovy; they appear to be identical in all but name. IDENTICAL. Or am I
> missing a subtle definition difference?
>
>
>
> David Robley wrote:
>
>> Kirk Bailey wrote:
>>
>>
>>
>>> Ok, so what is echo, and how is it different from print.
>>>
>>> The code in code quest used echo. I have a copy of learning php 5.0 from
>>> O'Reilly, and noplace does it mention echo. Why? What's the difference?
>>> IS there a difference? Is there an advantage to either? Please clarify
>>> for this newbie.
>>>
>>>
>>>
>>
>> The documentation says it all better than I can:
>>
>> http://php.net/manual/en/function.echo.php
>> http://php.net/manual/en/function.print.php
>>
>> Cheers
>>
>>
>
> --
> end
>
> Very Truly yours,
> - Kirk Bailey,
> Largo Florida
>
> kniht +-----+
> | BOX | +-----+ think
>
--- End Message ---
--- Begin Message ---
And the obvious difference, print returns true on success. I'm not sure what
would cause an echo it print to ever fail, so it really doesn't make a huge
difference.
Thanks,
Ash
http://www.ashleysheridan.co.uk
----- Reply message -----
From: "Alexandru Patranescu" <[email protected]>
Date: Sun, Dec 12, 2010 18:56
Subject: [PHP] code quest - ECHO?!?
To: "Kirk Bailey" <[email protected]>
Cc: <[email protected]>
They are almost identical.
Echo supports multiple parameters like "echo $a, $b;"
print is 20% slower than echo (by some tests).
"echo" is shorter than "print" so it's easy to write.
In fact it's all a matter of taste. The same reason we user die instead of
exit.
Alex
On Sun, Dec 12, 2010 at 6:23 PM, Kirk Bailey <[email protected]>wrote:
> Groovy; they appear to be identical in all but name. IDENTICAL. Or am I
> missing a subtle definition difference?
>
>
>
> David Robley wrote:
>
>> Kirk Bailey wrote:
>>
>>
>>
>>> Ok, so what is echo, and how is it different from print.
>>>
>>> The code in code quest used echo. I have a copy of learning php 5.0 from
>>> O'Reilly, and noplace does it mention echo. Why? What's the difference?
>>> IS there a difference? Is there an advantage to either? Please clarify
>>> for this newbie.
>>>
>>>
>>>
>>
>> The documentation says it all better than I can:
>>
>> http://php.net/manual/en/function.echo.php
>> http://php.net/manual/en/function.print.php
>>
>> Cheers
>>
>>
>
> --
> end
>
> Very Truly yours,
> - Kirk Bailey,
> Largo Florida
>
> kniht +-----+
> | BOX | +-----+ think
>
--- End Message ---
--- Begin Message ---
Hello all.
I have a page where the user can enter a search phrase and upon
submitting, the search phrase is queried in MySQL.
However, I need to modify is so each word in the phrase is searched
for... not just the exact phrase.
So, "big blue hat" will return results like:
"A big hat - blue in color"
"Hat - blue, big"
SQL would look like ....
WHERE (item_description like "%big%" and item_description like "%blue
%" and item_description like "%hat%" )
So, via PHP, what is the best way to extract each word from the search
phrase to it's own variable so I can place them dynamically into the
SQL statement.
Thanks,
--Rick
--- End Message ---
--- Begin Message ---
Rick Dwyer wrote:
Hello all.
I have a page where the user can enter a search phrase and upon
submitting, the search phrase is queried in MySQL.
However, I need to modify is so each word in the phrase is searched
for... not just the exact phrase.
So, "big blue hat" will return results like:
"A big hat - blue in color"
"Hat - blue, big"
SQL would look like ....
WHERE (item_description like "%big%" and item_description like "%blue%"
and item_description like "%hat%" )
You may be better to use full text and MATCH for this, see:
http://dev.mysql.com/doc/refman/5.1/en/fulltext-boolean.html
However..
So, via PHP, what is the best way to extract each word from the search
phrase to it's own variable so I can place them dynamically into the SQL
statement.
There are many ways you can do this:
http://php.net/explode
http://php.net/str_split
http://php.net/preg_split
Many examples can be found on the above pages, and you're real solution
depends on how many edge-cases you want to cover, but the above will
cover most approaches :)
Best,
Nathan
--- End Message ---
--- Begin Message ---
Thanks Nathan.
The MySQL Match/Against will probably work well... but I would need to
somehow add a "+" to the beginning of each word in the phrase so PHP
will still be involved.
--Rick
On Dec 12, 2010, at 2:51 PM, Nathan Rixham wrote:
Rick Dwyer wrote:
Hello all.
I have a page where the user can enter a search phrase and upon
submitting, the search phrase is queried in MySQL.
However, I need to modify is so each word in the phrase is searched
for... not just the exact phrase.
So, "big blue hat" will return results like:
"A big hat - blue in color"
"Hat - blue, big"
SQL would look like ....
WHERE (item_description like "%big%" and item_description like
"%blue%" and item_description like "%hat%" )
You may be better to use full text and MATCH for this, see:
http://dev.mysql.com/doc/refman/5.1/en/fulltext-boolean.html
However..
So, via PHP, what is the best way to extract each word from the
search phrase to it's own variable so I can place them dynamically
into the SQL statement.
There are many ways you can do this:
http://php.net/explode
http://php.net/str_split
http://php.net/preg_split
Many examples can be found on the above pages, and you're real
solution depends on how many edge-cases you want to cover, but the
above will cover most approaches :)
Best,
Nathan
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--- End Message ---
--- Begin Message ---
I have it working now using preg_replace.
--Rick
On Dec 12, 2010, at 3:50 PM, Rick Dwyer wrote:
Thanks Nathan.
The MySQL Match/Against will probably work well... but I would need
to somehow add a "+" to the beginning of each word in the phrase so
PHP will still be involved.
--Rick
On Dec 12, 2010, at 2:51 PM, Nathan Rixham wrote:
Rick Dwyer wrote:
Hello all.
I have a page where the user can enter a search phrase and upon
submitting, the search phrase is queried in MySQL.
However, I need to modify is so each word in the phrase is
searched for... not just the exact phrase.
So, "big blue hat" will return results like:
"A big hat - blue in color"
"Hat - blue, big"
SQL would look like ....
WHERE (item_description like "%big%" and item_description like
"%blue%" and item_description like "%hat%" )
You may be better to use full text and MATCH for this, see:
http://dev.mysql.com/doc/refman/5.1/en/fulltext-boolean.html
However..
So, via PHP, what is the best way to extract each word from the
search phrase to it's own variable so I can place them dynamically
into the SQL statement.
There are many ways you can do this:
http://php.net/explode
http://php.net/str_split
http://php.net/preg_split
Many examples can be found on the above pages, and you're real
solution depends on how many edge-cases you want to cover, but the
above will cover most approaches :)
Best,
Nathan
--
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
--- End Message ---
--- Begin Message ---
Nathan, Thank you very much for your response, we are going to visualize
network management system(topolgy view) with SVG and AJAX.
We found a jQuery plugin, following are urls.
http://plugins.jquery.com/project/svg
http://keith-wood.name/svg.html
On Thu, Dec 9, 2010 at 10:50 PM, Nathan Nobbe <[email protected]>wrote:
> On Thu, Dec 9, 2010 at 4:55 AM, sudarshana sampath <
> [email protected]> wrote:
>
>> Hi,
>>
>> We are going add a topology view to our Network Management System.
>> Our Network Management System is based on PHP, CakePHP, jQuery and other
>> web
>> related tools(middle tier written using C++).
>>
>> So we are going to work with Scalable Vector Graphics.
>>
>> We are looking for the best solution for doing that.
>>
>> Are there any extensions, plugins, frameworks available for SVG related
>> things ?
>>
>
> not sure exactly what youre trying to accomplish, but obviously you could
> use any number of vector programs over the cli from php.
>
> you might also have a peak at the cairo library which php allegedly
> supports (ive never tried it myself).
>
> http://us.php.net/manual/en/intro.cairo.php
>
> -nathan
>
--
Cheers,
Sudarshana Sampath.
--- End Message ---
