Re: [PHP] Re: PHP Application Structre
Paul M Foster wrote:
On Mon, May 10, 2010 at 11:37:21PM -0400, Robert Cummings wrote:
Paul M Foster wrote:
Lots of people use templating systems and particularly Smarty. Here's
the difference between a templating system and just hand-coding:
Hand coding--
Templating system:
(Okay, I'm not familiar with Smarty syntax, but in essence template
systems allow you to type less when you want PHP values to show up on
the page.)
Advantage: It *may* be easier for non-programmers to "read" the page
with templating systems. I'm not sure this is really true. They're still
liable to say, "What the heck is {flavor}?" Besides, my inclination is
to tell designers to make everything look pretty, turn the resulting
HTML over the the coders, who will then mark it up for PHP. After that,
the designers can stay away from it.
Disadvantage: You're adding another layer (and a LOT of code) just to
save yourself some typing. With straight PHP, the server reads the code,
interprets the PHP, substitutes values and shoves the page down to the
browser. With a templating system, the system must load and call the
templating engine, which must then substitute the proper values, and
then output the built page to the browser.
Your choice.
I get tired of correcting this incorrect assertion. Some templates
engines do what you describe. Not all. Some directly generate PHP source
code which is then either directly accessed via the web server or
directly included by another page. Generating PHP code from a template
engine can provide superior benefits over pure PHP since the distilling
of simple XML (or otherwise) tags can be rendered once via simple or
complex PHP processing during template compilation versus the same
processing being done on every page request. In fact some will produce
plain HTML that doesn't even require the PHP interpreter.
Okay, you're clearly more familiar with templating systems than I am. My
impression of templating systems is that the templating engine scans the
raw page, makes substitutions, and then outputs the page to the browser,
all on the fly. You're saying this isn't always the case.
Are you saying that some templating systems simply generate output,
which may then at some later time, be requested by the browser? That is,
they would function somewhat like a combination of "make" and "m4" (a
macro processor)? So a programmer would code his page, then call the
templating engine, which would output the final page to disk, so it is
now available for download? Is that the distinction you're making?
Yes :) Or some combination of this and what you described. Or this and
caching. It doesn't necessarily have to be built like an application
such as make would do. The application can lazy load the template
engine, compile the template(s) and then subsequently do an include() on
future requests. The compiled source code would run in the context of
the including function and so would be able to pull variables from this
context and so directly embedded PHP code could output these variables
as you suggest but without the template designed using explicit PHP
calls, or having to know about functions, or parameter order, etc.
Smarty is a push template engine. You push variables to the smarty
engine. You tell smarty to load the template. Smarty processes the
template by replacing tags or macros with the pushed values. Smarty is
also responsible for the caching so you kinda need to load the whole
bundle just to get the cached output. The type of template structure I'm
describing is a pull structure where the template pulls the data that
has been initialized via PHP code generated by the template engine.
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: PHP Application Structre
On Mon, May 10, 2010 at 11:37:21PM -0400, Robert Cummings wrote:
> Paul M Foster wrote:
>>
>> Lots of people use templating systems and particularly Smarty. Here's
>> the difference between a templating system and just hand-coding:
>>
>> Hand coding--
>>
>>
>>
>> Templating system:
>>
>>
>>
>> (Okay, I'm not familiar with Smarty syntax, but in essence template
>> systems allow you to type less when you want PHP values to show up on
>> the page.)
>>
>> Advantage: It *may* be easier for non-programmers to "read" the page
>> with templating systems. I'm not sure this is really true. They're still
>> liable to say, "What the heck is {flavor}?" Besides, my inclination is
>> to tell designers to make everything look pretty, turn the resulting
>> HTML over the the coders, who will then mark it up for PHP. After that,
>> the designers can stay away from it.
>>
>> Disadvantage: You're adding another layer (and a LOT of code) just to
>> save yourself some typing. With straight PHP, the server reads the code,
>> interprets the PHP, substitutes values and shoves the page down to the
>> browser. With a templating system, the system must load and call the
>> templating engine, which must then substitute the proper values, and
>> then output the built page to the browser.
>>
>> Your choice.
>
> I get tired of correcting this incorrect assertion. Some templates
> engines do what you describe. Not all. Some directly generate PHP source
> code which is then either directly accessed via the web server or
> directly included by another page. Generating PHP code from a template
> engine can provide superior benefits over pure PHP since the distilling
> of simple XML (or otherwise) tags can be rendered once via simple or
> complex PHP processing during template compilation versus the same
> processing being done on every page request. In fact some will produce
> plain HTML that doesn't even require the PHP interpreter.
Okay, you're clearly more familiar with templating systems than I am. My
impression of templating systems is that the templating engine scans the
raw page, makes substitutions, and then outputs the page to the browser,
all on the fly. You're saying this isn't always the case.
Are you saying that some templating systems simply generate output,
which may then at some later time, be requested by the browser? That is,
they would function somewhat like a combination of "make" and "m4" (a
macro processor)? So a programmer would code his page, then call the
templating engine, which would output the final page to disk, so it is
now available for download? Is that the distinction you're making?
Paul
--
Paul M. Foster
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: PHP Application Structre
Paul M Foster wrote:
On Mon, May 10, 2010 at 06:09:00PM -0400, David McGlone wrote:
On Monday 10 May 2010 13:04:36 richard gray wrote:
On 10/05/2010 18:17, Ashley Sheridan wrote:
It makes sense sometimes to have different files for different sections
of a website. For example, blog.php, gallery.php, cart.php could deal
with the blog, gallery and shopping cart sections for an artists
website. Yes, it could all be achieved with one script handling
everything, but sometimes when the areas of the site differ greatly, it
results in a lot of extra code to deal with pulling in the right
template and content parts. I've always favoured only including the code
a page needs rather than a huge amount of stuff that it doesn't.
this isn't necessarily true - the architecture I've developed uses a
single dispatch script (works fine with the mod rewrite option 2
scenario as well) - this script does general checks/security/filters etc
then simply determines what page/function the user wants from the
request ($_GET/$_POST parameter) and passes control to the specific
handler via including the relevant controller module. The controller
module is responsible for which template is required and loads up
specific classes needed to process the request etc so each module just
loads its own stuff and nothing else so there's no overhead.
This method also has a small extra benefit that the web server document
root just has a very simple 2 liner script instead a myriad of php
scripts... if the webserver is misconfigured then someone who sees the
source code doesn't get to see much..
This thread makes me wonder if using Smarty is smart. Does anyone here use a
templeting system such as smarty or am I the only one?
Lots of people use templating systems and particularly Smarty. Here's
the difference between a templating system and just hand-coding:
Hand coding--
Templating system:
(Okay, I'm not familiar with Smarty syntax, but in essence template
systems allow you to type less when you want PHP values to show up on
the page.)
Advantage: It *may* be easier for non-programmers to "read" the page
with templating systems. I'm not sure this is really true. They're still
liable to say, "What the heck is {flavor}?" Besides, my inclination is
to tell designers to make everything look pretty, turn the resulting
HTML over the the coders, who will then mark it up for PHP. After that,
the designers can stay away from it.
Disadvantage: You're adding another layer (and a LOT of code) just to
save yourself some typing. With straight PHP, the server reads the code,
interprets the PHP, substitutes values and shoves the page down to the
browser. With a templating system, the system must load and call the
templating engine, which must then substitute the proper values, and
then output the built page to the browser.
Your choice.
I get tired of correcting this incorrect assertion. Some templates
engines do what you describe. Not all. Some directly generate PHP source
code which is then either directly accessed via the web server or
directly included by another page. Generating PHP code from a template
engine can provide superior benefits over pure PHP since the distilling
of simple XML (or otherwise) tags can be rendered once via simple or
complex PHP processing during template compilation versus the same
processing being done on every page request. In fact some will produce
plain HTML that doesn't even require the PHP interpreter.
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: PHP Application Structre
On Monday 10 May 2010 22:15:44 Paul M Foster wrote:
> On Mon, May 10, 2010 at 06:09:00PM -0400, David McGlone wrote:
> > On Monday 10 May 2010 13:04:36 richard gray wrote:
> > > On 10/05/2010 18:17, Ashley Sheridan wrote:
> > > > It makes sense sometimes to have different files for different
> > > > sections of a website. For example, blog.php, gallery.php, cart.php
> > > > could deal with the blog, gallery and shopping cart sections for an
> > > > artists website. Yes, it could all be achieved with one script
> > > > handling everything, but sometimes when the areas of the site differ
> > > > greatly, it results in a lot of extra code to deal with pulling in
> > > > the right template and content parts. I've always favoured only
> > > > including the code a page needs rather than a huge amount of stuff
> > > > that it doesn't.
> > >
> > > this isn't necessarily true - the architecture I've developed uses a
> > > single dispatch script (works fine with the mod rewrite option 2
> > > scenario as well) - this script does general checks/security/filters
> > > etc then simply determines what page/function the user wants from the
> > > request ($_GET/$_POST parameter) and passes control to the specific
> > > handler via including the relevant controller module. The controller
> > > module is responsible for which template is required and loads up
> > > specific classes needed to process the request etc so each module just
> > > loads its own stuff and nothing else so there's no overhead.
> > >
> > > This method also has a small extra benefit that the web server document
> > > root just has a very simple 2 liner script instead a myriad of php
> > > scripts... if the webserver is misconfigured then someone who sees the
> > > source code doesn't get to see much..
> >
> > This thread makes me wonder if using Smarty is smart. Does anyone here
> > use a templeting system such as smarty or am I the only one?
>
> Lots of people use templating systems and particularly Smarty. Here's
> the difference between a templating system and just hand-coding:
>
> Hand coding--
>
>
>
> Templating system:
>
>
>
> (Okay, I'm not familiar with Smarty syntax, but in essence template
> systems allow you to type less when you want PHP values to show up on
> the page.)
>
> Advantage: It *may* be easier for non-programmers to "read" the page
> with templating systems. I'm not sure this is really true. They're still
> liable to say, "What the heck is {flavor}?" Besides, my inclination is
> to tell designers to make everything look pretty, turn the resulting
> HTML over the the coders, who will then mark it up for PHP. After that,
> the designers can stay away from it.
>
> Disadvantage: You're adding another layer (and a LOT of code) just to
> save yourself some typing. With straight PHP, the server reads the code,
> interprets the PHP, substitutes values and shoves the page down to the
> browser. With a templating system, the system must load and call the
> templating engine, which must then substitute the proper values, and
> then output the built page to the browser.
I don't know how everyone else does things, but I get a feeling of being very
well organized when using smarty.
I have to say that by using smarty, it has also helped me understand PHP more
in depth. Maybe it's because of the strict organization, or maybe it's because
I've been practicing a whole lot more. dunno.
--
Blessings,
David M.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PHP Application Structre
Hi all, mod rewrite was actually inrduced to have search engne frendly urls. hnce if you want a seo site then you have to use options 1 & 2. using smarty or any templating engine for readibility is not total true. one of the major advantages of using template engines is caching On 5/11/10, David McGlone wrote: > On Monday 10 May 2010 13:04:36 richard gray wrote: >> On 10/05/2010 18:17, Ashley Sheridan wrote: >> > It makes sense sometimes to have different files for different sections >> > of a website. For example, blog.php, gallery.php, cart.php could deal >> > with the blog, gallery and shopping cart sections for an artists >> > website. Yes, it could all be achieved with one script handling >> > everything, but sometimes when the areas of the site differ greatly, it >> > results in a lot of extra code to deal with pulling in the right >> > template and content parts. I've always favoured only including the code >> > a page needs rather than a huge amount of stuff that it doesn't. >> >> this isn't necessarily true - the architecture I've developed uses a >> single dispatch script (works fine with the mod rewrite option 2 >> scenario as well) - this script does general checks/security/filters etc >> then simply determines what page/function the user wants from the >> request ($_GET/$_POST parameter) and passes control to the specific >> handler via including the relevant controller module. The controller >> module is responsible for which template is required and loads up >> specific classes needed to process the request etc so each module just >> loads its own stuff and nothing else so there's no overhead. >> >> This method also has a small extra benefit that the web server document >> root just has a very simple 2 liner script instead a myriad of php >> scripts... if the webserver is misconfigured then someone who sees the >> source code doesn't get to see much.. > > This thread makes me wonder if using Smarty is smart. Does anyone here use a > templeting system such as smarty or am I the only one? > > -- > Blessings, > David M. > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > -- Sent from my mobile device with regards, Chetan Dattaram Rane Mob : +91 9766646714 Phone: 0831-2462055 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: PHP Application Structre
On Mon, May 10, 2010 at 06:09:00PM -0400, David McGlone wrote:
> On Monday 10 May 2010 13:04:36 richard gray wrote:
> > On 10/05/2010 18:17, Ashley Sheridan wrote:
> > > It makes sense sometimes to have different files for different sections
> > > of a website. For example, blog.php, gallery.php, cart.php could deal
> > > with the blog, gallery and shopping cart sections for an artists
> > > website. Yes, it could all be achieved with one script handling
> > > everything, but sometimes when the areas of the site differ greatly, it
> > > results in a lot of extra code to deal with pulling in the right
> > > template and content parts. I've always favoured only including the code
> > > a page needs rather than a huge amount of stuff that it doesn't.
> >
> > this isn't necessarily true - the architecture I've developed uses a
> > single dispatch script (works fine with the mod rewrite option 2
> > scenario as well) - this script does general checks/security/filters etc
> > then simply determines what page/function the user wants from the
> > request ($_GET/$_POST parameter) and passes control to the specific
> > handler via including the relevant controller module. The controller
> > module is responsible for which template is required and loads up
> > specific classes needed to process the request etc so each module just
> > loads its own stuff and nothing else so there's no overhead.
> >
> > This method also has a small extra benefit that the web server document
> > root just has a very simple 2 liner script instead a myriad of php
> > scripts... if the webserver is misconfigured then someone who sees the
> > source code doesn't get to see much..
>
> This thread makes me wonder if using Smarty is smart. Does anyone here use a
> templeting system such as smarty or am I the only one?
Lots of people use templating systems and particularly Smarty. Here's
the difference between a templating system and just hand-coding:
Hand coding--
Templating system:
(Okay, I'm not familiar with Smarty syntax, but in essence template
systems allow you to type less when you want PHP values to show up on
the page.)
Advantage: It *may* be easier for non-programmers to "read" the page
with templating systems. I'm not sure this is really true. They're still
liable to say, "What the heck is {flavor}?" Besides, my inclination is
to tell designers to make everything look pretty, turn the resulting
HTML over the the coders, who will then mark it up for PHP. After that,
the designers can stay away from it.
Disadvantage: You're adding another layer (and a LOT of code) just to
save yourself some typing. With straight PHP, the server reads the code,
interprets the PHP, substitutes values and shoves the page down to the
browser. With a templating system, the system must load and call the
templating engine, which must then substitute the proper values, and
then output the built page to the browser.
Your choice.
Paul
--
Paul M. Foster
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] php path and relink
I did it: .bash_profile PATH=/usr/local/php5/bin:$PATH export PATH worked well Thanks
RE: [PHP] php path and relink
then try different paths to locate the version you want: /usr/bin/php /usr/local/bin/php /usr/sbin/php etc etc I don't have root permission to unistall the old version or remove the link or create a link in /usr/loca/bin/php I'm just call the php -v command and get the version 4. Thanks Augusto Morais _ Diseñar aplicaciones tiene premio. ¡Si eres desarrollador no esperes más! http://www.imaginemobile.es
RE: [PHP] php path and relink
do strace php -v and see what's the path for the old version. It'd be better if you uninstall the old version, but it you don't know how was it installed, simply remove the old php binary or overwrite it with newer. I. Lopez. Hi, I have a shell account with limited access. The php cli version installated is 4.4.6. But the server have also the php 5.2.6. I checked the php version and i got this: $ php -v PHP 4.4.9 (cli) (built: Sep 17 2008 11:04:03) . But i want that the php command be a link to the php5. How can i "re-link" this php command to the path /usr/local/php5/bin/php ? I tried include this path in the PATH variable env but didn't worked. Some idea? Thanks Augusto Morais. _ Diseñar aplicaciones tiene premio. ¡Si eres desarrollador no esperes más! http://www.imaginemobile.es
Re: [PHP] php path and relink
On Mon, 2010-05-10 at 21:23 -0300, Augusto Flavio wrote: > Hi, > > > I have a shell account with limited access. The php cli version installated > is 4.4.6. But the server have also the php 5.2.6. I checked the php version > and i got this: > > > $ php -v > PHP 4.4.9 (cli) (built: Sep 17 2008 11:04:03) > . > > But i want that the php command be a link to the php5. > > How can i "re-link" this php command to the path /usr/local/php5/bin/php ? > > I tried include this path in the PATH variable env but didn't worked. > > > Some idea? > > > Thanks > > Augusto Morais. How are you calling the script to be executed by PHP? Can't you add the path to the version of PHP you want to use there? Thanks, Ash http://www.ashleysheridan.co.uk
RE: [PHP] regexp questions
Is there any place where to read the changelog or something?
Thanks.
>>>
For example, the following regex doesn't work.
return (bool) preg_match('/^[\pL\pN\pZ\p{Pc}\p{Pd}\p{Po}]++$/uD',
(string) $str);
Shiplu Mokadd.im
_
Disfruta de Messenger y Hotmail en tu BlackBerry ¡Hazlo ya!
http://serviciosmoviles.es.msn.com/messenger/blackberry.aspx
[PHP] php path and relink
Hi, I have a shell account with limited access. The php cli version installated is 4.4.6. But the server have also the php 5.2.6. I checked the php version and i got this: $ php -v PHP 4.4.9 (cli) (built: Sep 17 2008 11:04:03) . But i want that the php command be a link to the php5. How can i "re-link" this php command to the path /usr/local/php5/bin/php ? I tried include this path in the PATH variable env but didn't worked. Some idea? Thanks Augusto Morais.
Re: [PHP] regexp questions
For example, the following regex doesn't work.
return (bool) preg_match('/^[\pL\pN\pZ\p{Pc}\p{Pd}\p{Po}]++$/uD',
(string) $str);
Shiplu Mokadd.im
My talks, http://talk.cmyweb.net
Follow me, http://twitter.com/shiplu
SUST Programmers, http://groups.google.com/group/p2psust
Innovation distinguishes bet ... ... (ask Steve Jobs the rest
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] regexp questions
Hi, I've recently changed from php 5.1 to 5.3.2 and I'm havong problems with preg_match, because the same regular expressions used in php 5.1 are not matching anything in 5.3.2. There are any significant changes that I should know? I've been searching but I haven't found anything. Thanks. I.Lopez. _ Recibe en tu HOTMAIL los emails de TODAS tus CUENTAS. + info http://www.vivelive.com/hotmail-la-gente-de-hoy/index.html?multiaccount
Re: [PHP] Re: PHP Application Structre
On Monday 10 May 2010 13:04:36 richard gray wrote: > On 10/05/2010 18:17, Ashley Sheridan wrote: > > It makes sense sometimes to have different files for different sections > > of a website. For example, blog.php, gallery.php, cart.php could deal > > with the blog, gallery and shopping cart sections for an artists > > website. Yes, it could all be achieved with one script handling > > everything, but sometimes when the areas of the site differ greatly, it > > results in a lot of extra code to deal with pulling in the right > > template and content parts. I've always favoured only including the code > > a page needs rather than a huge amount of stuff that it doesn't. > > this isn't necessarily true - the architecture I've developed uses a > single dispatch script (works fine with the mod rewrite option 2 > scenario as well) - this script does general checks/security/filters etc > then simply determines what page/function the user wants from the > request ($_GET/$_POST parameter) and passes control to the specific > handler via including the relevant controller module. The controller > module is responsible for which template is required and loads up > specific classes needed to process the request etc so each module just > loads its own stuff and nothing else so there's no overhead. > > This method also has a small extra benefit that the web server document > root just has a very simple 2 liner script instead a myriad of php > scripts... if the webserver is misconfigured then someone who sees the > source code doesn't get to see much.. This thread makes me wonder if using Smarty is smart. Does anyone here use a templeting system such as smarty or am I the only one? -- Blessings, David M. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] simplexml choking on apparently valid XML - Solved
I was able to resolve this by changing the XML file encoding from UTF-8 to ISO-8859-1. Works like a charm now, with the XML-encoded characters. Thanks to all who offered their help. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] PHP Image Host - Sending HTTP Headers Twice?
I have a php script which serves an image. It's very simple:
header('Content-Type: image/' . $ImageData['content_type']);
readfile($File);
When viewing the script with the Firefox Extension: LiveHTTPHeaders,
it gives the following output for a SINGLE request:
--
https://domain.tld/img.php?i=260
GET /img.php?i=260 HTTP/1.1
Host: domain.tld
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US;
rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: UTF-8,*
Keep-Alive: 115
Connection: keep-alive
Cookie: session=blahblah
Cache-Control: max-age=0
HTTP/1.1 200 OK
Server: nginx
Date: Mon, 10 May 2010 20:17:09 GMT
Content-Type: image/jpeg
Transfer-Encoding: chunked
Connection: keep-alive
--
https://domain.tld/img.php?i=260
GET /img.php?i=260 HTTP/1.1
Host: domain.tld
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US;
rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: UTF-8,*
Keep-Alive: 115
Connection: keep-alive
HTTP/1.1 200 OK
Server: nginx
Date: Mon, 10 May 2010 20:17:10 GMT
Content-Type: text/html; charset=utf-8
Transfer-Encoding: chunked
Connection: keep-alive
Content-Encoding: gzip
--
As you can see, the browser is requesting the image twice, and PHP is
sending two different Content-Type headers. Why is this?
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] How to get input from socket client
From: Ryan Sun > Stream and networking programming seems like a rock on the way to > ZCE for most people, so I'm learning some socket examples before I sit > in the room for exam. > Here is the script for server > server&client hangs after output and time out later. > > Can any1 point out whats the reason and the more correct way to get > socket client input in socket server? I have not done any socket programs in PHP, but I have in Assembler, C and Perl. First, I don't think feof() will do what you think it does. I wouldn't expect it to show up until after the other end has actually closed the connection. The other problem has to do with thinking an fread() will always give you everything you sent in an fwrite(). TCP is a stream protocol, there are no guarantees about delivering a complete message in one read, or that two writes won't be read together. It only guarantees that all octets will eventually be delivered in the same order they were sent, or you will get an error. The buffering is completely hidden and outside of your control. If you want writes to be atomic, you want UDP, but then you lose the guarantee of delivery. If you want to enforce a structure on the data in that stream, it is your application's responsibility to reconstruct that data at the receiver. One other detail that may or may not make a difference. TCP actually defines two independent pipes, one in each direction. Many Unix applications create two processes to service a socket, one to send, the other to receive. Only occasionally does a protocol require alternating messages similar to a conversation or ping-pong match. Bob McConnell -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] How to get input from socket client
Stream and networking programming seems like a rock on the way to ZCE for most people, so I'm learning some socket examples before I sit in the room for exam. Here is the script for server http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: PHP Application Structre
On 10/05/2010 18:17, Ashley Sheridan wrote: It makes sense sometimes to have different files for different sections of a website. For example, blog.php, gallery.php, cart.php could deal with the blog, gallery and shopping cart sections for an artists website. Yes, it could all be achieved with one script handling everything, but sometimes when the areas of the site differ greatly, it results in a lot of extra code to deal with pulling in the right template and content parts. I've always favoured only including the code a page needs rather than a huge amount of stuff that it doesn't. this isn't necessarily true - the architecture I've developed uses a single dispatch script (works fine with the mod rewrite option 2 scenario as well) - this script does general checks/security/filters etc then simply determines what page/function the user wants from the request ($_GET/$_POST parameter) and passes control to the specific handler via including the relevant controller module. The controller module is responsible for which template is required and loads up specific classes needed to process the request etc so each module just loads its own stuff and nothing else so there's no overhead. This method also has a small extra benefit that the web server document root just has a very simple 2 liner script instead a myriad of php scripts... if the webserver is misconfigured then someone who sees the source code doesn't get to see much.. Just my 0.02 Euros Cheers Rich -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: PHP Application Structre
On 10 May 2010 18:17, Ashley Sheridan wrote: > > >> >> 3} Unless the site is small and has few pages and applications, it is almost >> impossible to maintain. >> > > I disagree here. As long as there are useful naming conventions for all > of the files (I've seen projects where files have been named 1.php, > 2.php, etc. I wanted to bloody kill the developer who thought that was a > good idea!) It can be easier to maintain, especially when working in > teams, where one person can work on one area of the site and another > person can work on another. > > It makes sense sometimes to have different files for different sections > of a website. For example, blog.php, gallery.php, cart.php could deal > with the blog, gallery and shopping cart sections for an artists > website. Yes, it could all be achieved with one script handling > everything, but sometimes when the areas of the site differ greatly, it > results in a lot of extra code to deal with pulling in the right > template and content parts. I've always favoured only including the code > a page needs rather than a huge amount of stuff that it doesn't. I doubt anyone is proposing the "one script with all classes and functions" approach. Several files is obviously a preferable method. How you structure the code is completely different though: do you allow a user to run blog.php directly or do you funnel everything through one file and then handle request dispatching through that. Regards Peter -- WWW: http://plphp.dk / http://plind.dk LinkedIn: http://www.linkedin.com/in/plind Flickr: http://www.flickr.com/photos/fake51 BeWelcome: Fake51 Couchsurfing: Fake51 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: PHP Application Structre
On 5/10/2010 12:17 PM, Ashley Sheridan wrote: 3} Unless the site is small and has few pages and applications, it is almost impossible to maintain. I disagree here. As long as there are useful naming conventions for all of the files (I've seen projects where files have been named 1.php, 2.php, etc. I wanted to bloody kill the developer who thought that was a good idea!) It can be easier to maintain, especially when working in teams, where one person can work on one area of the site and another person can work on another. It makes sense sometimes to have different files for different sections of a website. For example, blog.php, gallery.php, cart.php could deal with the blog, gallery and shopping cart sections for an artists website. Yes, it could all be achieved with one script handling everything, but sometimes when the areas of the site differ greatly, it results in a lot of extra code to deal with pulling in the right template and content parts. I've always favoured only including the code a page needs rather than a huge amount of stuff that it doesn't. Thanks, Ash http://www.ashleysheridan.co.uk I don't think we disagree. I always give the URL to pages [i.e., files] a descriptive name e.g.; http://foo.org/Coach/RunningEconSeminar.php One site I worked on had about 1000 URL pages. Maintaining unique code for most of these would be prohibitive. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: PHP Application Structre
On Mon, May 10, 2010 at 05:17:16PM +0100, Ashley Sheridan wrote: > > > > > > 3} Unless the site is small and has few pages and applications, it > is almost > > impossible to maintain. > > > > I disagree here. As long as there are useful naming conventions for all > of the files (I've seen projects where files have been named 1.php, > 2.php, etc. I wanted to bloody kill the developer who thought that was a > good idea!) It can be easier to maintain, especially when working in > teams, where one person can work on one area of the site and another > person can work on another. +1 > > It makes sense sometimes to have different files for different sections > of a website. For example, blog.php, gallery.php, cart.php could deal > with the blog, gallery and shopping cart sections for an artists > website. Yes, it could all be achieved with one script handling > everything, but sometimes when the areas of the site differ greatly, it > results in a lot of extra code to deal with pulling in the right > template and content parts. I've always favoured only including the code > a page needs rather than a huge amount of stuff that it doesn't. +1 This is a deficiency of a lot of frameworks. By the time you display the first byte to the browser, you've loaded 150K of code, only 20K of which do you actually need for *this* page. Paul -- Paul M. Foster -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: PHP Application Structre
> > 3} Unless the site is small and has few pages and applications, it is almost > impossible to maintain. > I disagree here. As long as there are useful naming conventions for all of the files (I've seen projects where files have been named 1.php, 2.php, etc. I wanted to bloody kill the developer who thought that was a good idea!) It can be easier to maintain, especially when working in teams, where one person can work on one area of the site and another person can work on another. It makes sense sometimes to have different files for different sections of a website. For example, blog.php, gallery.php, cart.php could deal with the blog, gallery and shopping cart sections for an artists website. Yes, it could all be achieved with one script handling everything, but sometimes when the areas of the site differ greatly, it results in a lot of extra code to deal with pulling in the right template and content parts. I've always favoured only including the code a page needs rather than a huge amount of stuff that it doesn't. Thanks, Ash http://www.ashleysheridan.co.uk
[PHP] Re: PHP Application Structre
On 5/10/2010 6:39 AM, Alex Major wrote: Greetings all, This question basically surrounds how you structure your PHP applications, whether it changes depending on what you're doing and which you'd favour. I have a feeling it'll come down to a question of personal taste, but on the off-chance there's a best practice I'll ask anyways. From what I've seen and used, there seem to be three distinct ways of going about it. 1) Using a 'core' class which has a request handler in it. All pages in the site are accessed through that one page, e.g. http://www.somesite.com/index.php?page=ViewUser http://www.somesite.com/index.php?page=ViewProduct This is one that I've personally used most after becoming familiar with a bulletin board system several years ago. It means that pages are easily created as all the template/session/database handling is done by the central class. 2) Using SE friendly URL's like: http://www.somesite.com/products/22012/cool-game/ http://www.somesite.com/products/22013/other-game/ This approach seems to be becoming more common on the sites I frequent, however by accounts I've read it seems to be more intensive on apache as it requires a mod-rewrite function. 3) Using different PHP files for each page: http://www.somesite.com/viewproduct.php?product= http://www.somesite.com/viewuser.php?user=... This would appear to be the least developer friendly option? Hopefully someone can shed some insight into which is the recommended approach and why. I've been building bigger and bigger sites so having a solid foundation is becoming more and more important. Thanks for any help/feedback, I hope I've been clear. Alex. Here is my take on your 3 options: 1] Basically the approach taken by so-called CMS systems like Joomla. Three major problems. One, everything is in one core and DB; so if there is a major bug, crash, hack, whatever, it is hell to repair. If the site is very active, backups can be a problem trying to recover anything that has changed since the last backup. Also, sometimes bugs and hacks can exist for a relatively long time before they manifest themselves. Finding when such first occurred and then backing up from there can be damn near impossible. Two, any changes to the core can have unforeseen consequences somewhere in the site. Three, if the core breaks the whole site is down. 2] I use essentially this approach. But, don't use mod_rewrite. It is an unnecessary complication. Remember in the PHP world the initial php page "owns" the session. So, the current working dir is where the php file is. I like the fact that all pages are called by a URL name e.g.; www.foo.com/bar/filex.php and I save the pages data in a sub directory or DB just for it. e.g., www.foo.com/bar/data/dataFile.db. All of my application types e.g., simple html pages, sign up registries, etc. each have their own config and functions file, etc. in a separate dir/ Each page can have a custom css, images, etc. in it's dir and for special situations, I can write a php that performs some special functions and then calls the common application script. If the page becomes obsolete, I simply delete the dir and subdir. When I update a application type core code, e.g., Signups, I don't need to worry about affecting regular html page types. Here is one of my typical "calling files "www.foo.com/Seminars/Running_Economy.php": Can't get any simpler. 3} Unless the site is small and has few pages and applications, it is almost impossible to maintain. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] -----json and php----help
hi dears, I have a json file. I want to access some fileds of this json file only and can add some fields to it also... I couldn't find any thing in www, json api ! is there any function to get specific data from json file or add function that can add something in somewhere in this json file or create new json file from this file with my format? Thanks alot, Shahrzad Khorrami
Re: [PHP] xpath help
On 5/9/10, Peter Lind wrote: > On 9 May 2010 10:31, Gary wrote: >> If I have a document containing, say: >> ... >> >> How do I get at "bar2"? I tried everything, based on an xpath from >> Firebug (Firefox plugin), but kept getting NULL. >> > > try //table//font - that should give you all the font elements in > table elements. Given your layout, you're then looking for > $list->item(3) I found out what my problem was. Something, somewhere - the plugin, Firefox itself, something - decided to "help me" by inserting TBODY elements into the xpath which just plain did not exist in the original HTML. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] PHP Application Structre
_ From: Ashley Sheridan [mailto:a...@ashleysheridan.co.uk] Sent: 10 May 2010 01:58 PM To: a...@dotcontent.net Cc: 'Alex Major'; 'php-general General List' Subject: RE: [PHP] PHP Application Structre On Mon, 2010-05-10 at 13:15 +0200, Arno Kuhl wrote: -Original Message- From: Alex Major [mailto:p...@allydm.co.uk] Sent: 10 May 2010 12:39 PM >From what I've seen and used, there seem to be three distinct ways of going about it. 1) Using a 'core' class which has a request handler in it. All pages in the site are accessed through that one page, e.g. http://www.somesite.com/index.php?page=ViewUser http://www.somesite.com/index.php?page=ViewProduct This is one that I've personally used most after becoming familiar with a bulletin board system several years ago. It means that pages are easily created as all the template/session/database handling is done by the central class. 2) Using SE friendly URL's like: http://www.somesite.com/products/22012/cool-game/ http://www.somesite.com/products/22013/other-game/ This approach seems to be becoming more common on the sites I frequent, however by accounts I've read it seems to be more intensive on apache as it requires a mod-rewrite function. 3) Using different PHP files for each page: http://www.somesite.com/viewproduct.php?product= http://www.somesite.com/viewuser.php?user=... This would appear to be the least developer friendly option? Alex. = The second option doesn't really belong here, because you could go for option 1 or option 3, and then decide whether to hide your implementation behind a mod-rewrite. Option 2 would rather be part of a separate question "what is the cost/benefit of using mod-rewrite". Cheers Arno Personally, I go with option 3 (as Arno said, option 2 isn't really an alternative option, it's something you can use with either 1 or 3) Consider a basic website with a small shopping cart and a blog. It would seem crazy to have all the logic needed for the blog and the cart being pulled in by PHP everytime you just needed to display a contact page. Far easier to keep everything a bit more modular. That way, if you need to update something, you update only a small part of the site rather than some huge core file. But, if your needs are even more simple, say it's just a very small brochure website you have, then running everything through a single index.php might not be such a bad idea. Thanks, Ash http://www.ashleysheridan.co.uk == There are many approaches to this, and I think your final design will largely be determined by what you want to do, and your own skill and experience. If you want to initialise your application, check input and load all your base api functions before calling the specific script (function) to handle the query, then maybe you can consider using a single entry point for your application. It can simplify your design and maintenance, and there are ways to ensure that access to your scripts have been initialised via the single entry point. Careful design can allow you to add new modules/scripts/whatever without having to update your single entry point each time (look at some open-source apps for examples). It also allows you to move your entire application to some place outside the document root and leave only the entry script open to the public, which can add a bit of extra security to your application. Personally I use two entry-points, one for admin and one for everything else. Then besides graphics, flash and javascript, everything else is put someplace outside the document root. The reason I settled on that approach was because the admin script can handle all the slow heavy security-checking stuff and loading additional admin api's, while the general script can be small, fast and lightweight, but won't allow any access to the admin functions. Neither script needs to be updated when adding to or changing the main application. Cheers Arno
Re: [PHP] PHP Application Structre
On 10 May 2010 13:58, Ashley Sheridan wrote: > On Mon, 2010-05-10 at 13:15 +0200, Arno Kuhl wrote: > >> -Original Message- >> From: Alex Major [mailto:p...@allydm.co.uk] >> Sent: 10 May 2010 12:39 PM >> >> From what I've seen and used, there seem to be three distinct ways of going >> about it. >> >> 1) Using a 'core' class which has a request handler in it. All pages in >> the site are accessed through that one page, e.g. >> http://www.somesite.com/index.php?page=ViewUser >> http://www.somesite.com/index.php?page=ViewProduct >> This is one that I've personally used most after becoming familiar with a >> bulletin board system several years ago. It means that pages are easily >> created as all the template/session/database handling is done by the central >> class. >> >> 2) Using SE friendly URL's like: >> http://www.somesite.com/products/22012/cool-game/ >> http://www.somesite.com/products/22013/other-game/ >> This approach seems to be becoming more common on the sites I frequent, >> however by accounts I've read it seems to be more intensive on apache as it >> requires a mod-rewrite function. >> >> 3) Using different PHP files for each page: >> http://www.somesite.com/viewproduct.php?product= >> http://www.somesite.com/viewuser.php?user=... >> This would appear to be the least developer friendly option? >> >> Alex. >> >> = >> >> The second option doesn't really belong here, because you could go for >> option 1 or option 3, and then decide whether to hide your implementation >> behind a mod-rewrite. Option 2 would rather be part of a separate question >> "what is the cost/benefit of using mod-rewrite". >> >> Cheers >> Arno >> >> >> > > > Personally, I go with option 3 (as Arno said, option 2 isn't really an > alternative option, it's something you can use with either 1 or 3) > > Consider a basic website with a small shopping cart and a blog. It would > seem crazy to have all the logic needed for the blog and the cart being > pulled in by PHP everytime you just needed to display a contact page. > Far easier to keep everything a bit more modular. That way, if you need > to update something, you update only a small part of the site rather > than some huge core file. > > But, if your needs are even more simple, say it's just a very small > brochure website you have, then running everything through a single > index.php might not be such a bad idea. > > Thanks, > Ash > http://www.ashleysheridan.co.uk > Option 1 with option 2 as a sidedish. Option 3 is a nightmare in my experience - a proper MVC approach is much better to work, maintain and assure the security of. Regards Peter -- WWW: http://plphp.dk / http://plind.dk LinkedIn: http://www.linkedin.com/in/plind Flickr: http://www.flickr.com/photos/fake51 BeWelcome: Fake51 Couchsurfing: Fake51 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: PHP Encoder like IonCube
On Mon, 2010-05-10 at 17:51 +0600, shiplu wrote: > Hello Ashley, > My application will not be accessible through Internet. Users will > use it through internal network. And internet is strictly prohibited > there. Thats the reason why i'm lookin for such solution. > > On 5/10/10, Ashley Sheridan wrote: > > On Mon, 2010-05-10 at 12:42 +0600, shiplu wrote: > > > >> On Mon, May 10, 2010 at 6:28 AM, donald sullivan > >> wrote: > >> > bcompiler is available, but with the correct tools data can still be > >> > extracted. > >> > http://php.net/manual/en/book.bcompiler.php > >> > > >> Its not a problem if data can still be extracted. But I guess exact > >> data can not be extracted. > >> If thats the case its okay. Sometimes an obfuscated code is enough to > >> protect it. > >> > >> As far I remember I heard somewhere it can be achieved by e-accelerator > >> somehow. > >> How is it possible? > >> > >> > >> Shiplu Mokadd.im > >> My talks, http://talk.cmyweb.net > >> Follow me, http://twitter.com/shiplu > >> SUST Programmers, http://groups.google.com/group/p2psust > >> Innovation distinguishes bet ... ... (ask Steve Jobs the rest) > >> > > > > > > I have to ask, why do you want to do that? Wouldn't it be easier to > > offer your application as a system that only you host. That way, the > > end-user never gets to see your PHP code. > > > > Thanks, > > Ash > > http://www.ashleysheridan.co.uk > > > > > > > Maybe you need a binary compiler then? This would limit your system to one type of OS though. For example, if you compiled it for 64-bit Windows, then you couldn't use it on a 32-bit server. Essentially you'd need to compile different versions for each architecture that you want to support. Would you compile it for Mac and Linux too (not forgetting the 32/64-bit issue there too) If a binary compile is what you're looking for then there was a thread a while back about the compiler that Facebook released which might be of some use? Ps, please try not to top post on the list. Thanks, Ash http://www.ashleysheridan.co.uk
RE: [PHP] PHP Application Structre
On Mon, 2010-05-10 at 13:15 +0200, Arno Kuhl wrote: > -Original Message- > From: Alex Major [mailto:p...@allydm.co.uk] > Sent: 10 May 2010 12:39 PM > > From what I've seen and used, there seem to be three distinct ways of going > about it. > > 1) Using a 'core' class which has a request handler in it. All pages in > the site are accessed through that one page, e.g. > http://www.somesite.com/index.php?page=ViewUser > http://www.somesite.com/index.php?page=ViewProduct > This is one that I've personally used most after becoming familiar with a > bulletin board system several years ago. It means that pages are easily > created as all the template/session/database handling is done by the central > class. > > 2) Using SE friendly URL's like: > http://www.somesite.com/products/22012/cool-game/ > http://www.somesite.com/products/22013/other-game/ > This approach seems to be becoming more common on the sites I frequent, > however by accounts I've read it seems to be more intensive on apache as it > requires a mod-rewrite function. > > 3) Using different PHP files for each page: > http://www.somesite.com/viewproduct.php?product= > http://www.somesite.com/viewuser.php?user=... > This would appear to be the least developer friendly option? > > Alex. > > = > > The second option doesn't really belong here, because you could go for > option 1 or option 3, and then decide whether to hide your implementation > behind a mod-rewrite. Option 2 would rather be part of a separate question > "what is the cost/benefit of using mod-rewrite". > > Cheers > Arno > > > Personally, I go with option 3 (as Arno said, option 2 isn't really an alternative option, it's something you can use with either 1 or 3) Consider a basic website with a small shopping cart and a blog. It would seem crazy to have all the logic needed for the blog and the cart being pulled in by PHP everytime you just needed to display a contact page. Far easier to keep everything a bit more modular. That way, if you need to update something, you update only a small part of the site rather than some huge core file. But, if your needs are even more simple, say it's just a very small brochure website you have, then running everything through a single index.php might not be such a bad idea. Thanks, Ash http://www.ashleysheridan.co.uk
Re: [PHP] PHP Encoder like IonCube
On May 10, 2010, at 7:36 AM, Peter Lind wrote: On 10 May 2010 13:25, Ashley Sheridan wrote: On Mon, 2010-05-10 at 12:42 +0600, shiplu wrote: On Mon, May 10, 2010 at 6:28 AM, donald sullivan wrote: bcompiler is available, but with the correct tools data can still be extracted. http://php.net/manual/en/book.bcompiler.php Its not a problem if data can still be extracted. But I guess exact data can not be extracted. If thats the case its okay. Sometimes an obfuscated code is enough to protect it. As far I remember I heard somewhere it can be achieved by e- accelerator somehow. How is it possible? Shiplu Mokadd.im My talks, http://talk.cmyweb.net Follow me, http://twitter.com/shiplu SUST Programmers, http://groups.google.com/group/p2psust Innovation distinguishes bet ... ... (ask Steve Jobs the rest) I have to ask, why do you want to do that? Wouldn't it be easier to offer your application as a system that only you host. That way, the end-user never gets to see your PHP code. Not to mention: if it runs, it can be broken. Regards Peter -- WWW: http://plphp.dk / http://plind.dk LinkedIn: http://www.linkedin.com/in/plind Flickr: http://www.flickr.com/photos/fake51 BeWelcome: Fake51 Couchsurfing: Fake51 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php Not to mention that is what contracts are for. Bastien Sent from my iPod -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: PHP Encoder like IonCube
Hello Ashley, My application will not be accessible through Internet. Users will use it through internal network. And internet is strictly prohibited there. Thats the reason why i'm lookin for such solution. On 5/10/10, Ashley Sheridan wrote: > On Mon, 2010-05-10 at 12:42 +0600, shiplu wrote: > >> On Mon, May 10, 2010 at 6:28 AM, donald sullivan >> wrote: >> > bcompiler is available, but with the correct tools data can still be >> > extracted. >> > http://php.net/manual/en/book.bcompiler.php >> > >> Its not a problem if data can still be extracted. But I guess exact >> data can not be extracted. >> If thats the case its okay. Sometimes an obfuscated code is enough to >> protect it. >> >> As far I remember I heard somewhere it can be achieved by e-accelerator >> somehow. >> How is it possible? >> >> >> Shiplu Mokadd.im >> My talks, http://talk.cmyweb.net >> Follow me, http://twitter.com/shiplu >> SUST Programmers, http://groups.google.com/group/p2psust >> Innovation distinguishes bet ... ... (ask Steve Jobs the rest) >> > > > I have to ask, why do you want to do that? Wouldn't it be easier to > offer your application as a system that only you host. That way, the > end-user never gets to see your PHP code. > > Thanks, > Ash > http://www.ashleysheridan.co.uk > > > -- Sent from my mobile device Shiplu Mokadd.im My talks, http://talk.cmyweb.net Follow me, http://twitter.com/shiplu SUST Programmers, http://groups.google.com/group/p2psust Innovation distinguishes bet ... ... (ask Steve Jobs the rest) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PHP Encoder like IonCube
On 10 May 2010 13:25, Ashley Sheridan wrote: > On Mon, 2010-05-10 at 12:42 +0600, shiplu wrote: > >> On Mon, May 10, 2010 at 6:28 AM, donald sullivan wrote: >> > bcompiler is available, but with the correct tools data can still be >> > extracted. >> > http://php.net/manual/en/book.bcompiler.php >> > >> Its not a problem if data can still be extracted. But I guess exact >> data can not be extracted. >> If thats the case its okay. Sometimes an obfuscated code is enough to >> protect it. >> >> As far I remember I heard somewhere it can be achieved by e-accelerator >> somehow. >> How is it possible? >> >> >> Shiplu Mokadd.im >> My talks, http://talk.cmyweb.net >> Follow me, http://twitter.com/shiplu >> SUST Programmers, http://groups.google.com/group/p2psust >> Innovation distinguishes bet ... ... (ask Steve Jobs the rest) >> > > > I have to ask, why do you want to do that? Wouldn't it be easier to > offer your application as a system that only you host. That way, the > end-user never gets to see your PHP code. > Not to mention: if it runs, it can be broken. Regards Peter -- WWW: http://plphp.dk / http://plind.dk LinkedIn: http://www.linkedin.com/in/plind Flickr: http://www.flickr.com/photos/fake51 BeWelcome: Fake51 Couchsurfing: Fake51 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PHP Encoder like IonCube
On Mon, 2010-05-10 at 12:42 +0600, shiplu wrote: > On Mon, May 10, 2010 at 6:28 AM, donald sullivan wrote: > > bcompiler is available, but with the correct tools data can still be > > extracted. > > http://php.net/manual/en/book.bcompiler.php > > > Its not a problem if data can still be extracted. But I guess exact > data can not be extracted. > If thats the case its okay. Sometimes an obfuscated code is enough to > protect it. > > As far I remember I heard somewhere it can be achieved by e-accelerator > somehow. > How is it possible? > > > Shiplu Mokadd.im > My talks, http://talk.cmyweb.net > Follow me, http://twitter.com/shiplu > SUST Programmers, http://groups.google.com/group/p2psust > Innovation distinguishes bet ... ... (ask Steve Jobs the rest) > I have to ask, why do you want to do that? Wouldn't it be easier to offer your application as a system that only you host. That way, the end-user never gets to see your PHP code. Thanks, Ash http://www.ashleysheridan.co.uk
RE: [PHP] PHP Application Structre
-Original Message- From: Alex Major [mailto:p...@allydm.co.uk] Sent: 10 May 2010 12:39 PM >From what I've seen and used, there seem to be three distinct ways of going about it. 1) Using a 'core' class which has a request handler in it. All pages in the site are accessed through that one page, e.g. http://www.somesite.com/index.php?page=ViewUser http://www.somesite.com/index.php?page=ViewProduct This is one that I've personally used most after becoming familiar with a bulletin board system several years ago. It means that pages are easily created as all the template/session/database handling is done by the central class. 2) Using SE friendly URL's like: http://www.somesite.com/products/22012/cool-game/ http://www.somesite.com/products/22013/other-game/ This approach seems to be becoming more common on the sites I frequent, however by accounts I've read it seems to be more intensive on apache as it requires a mod-rewrite function. 3) Using different PHP files for each page: http://www.somesite.com/viewproduct.php?product= http://www.somesite.com/viewuser.php?user=... This would appear to be the least developer friendly option? Alex. = The second option doesn't really belong here, because you could go for option 1 or option 3, and then decide whether to hide your implementation behind a mod-rewrite. Option 2 would rather be part of a separate question "what is the cost/benefit of using mod-rewrite". Cheers Arno -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] PHP Application Structre
Greetings all, This question basically surrounds how you structure your PHP applications, whether it changes depending on what you're doing and which you'd favour. I have a feeling it'll come down to a question of personal taste, but on the off-chance there's a best practice I'll ask anyways. >From what I've seen and used, there seem to be three distinct ways of going about it. 1) Using a 'core' class which has a request handler in it. All pages in the site are accessed through that one page, e.g. http://www.somesite.com/index.php?page=ViewUser http://www.somesite.com/index.php?page=ViewProduct This is one that I've personally used most after becoming familiar with a bulletin board system several years ago. It means that pages are easily created as all the template/session/database handling is done by the central class. 2) Using SE friendly URL's like: http://www.somesite.com/products/22012/cool-game/ http://www.somesite.com/products/22013/other-game/ This approach seems to be becoming more common on the sites I frequent, however by accounts I've read it seems to be more intensive on apache as it requires a mod-rewrite function. 3) Using different PHP files for each page: http://www.somesite.com/viewproduct.php?product= http://www.somesite.com/viewuser.php?user=... This would appear to be the least developer friendly option? Hopefully someone can shed some insight into which is the recommended approach and why. I've been building bigger and bigger sites so having a solid foundation is becoming more and more important. Thanks for any help/feedback, I hope I've been clear. Alex.
