php-general Digest 10 May 2010 23:54:03 -0000 Issue 6737
Topics (messages 305033 through 305055):
Re: PHP Application Structre
305033 by: Arno Kuhl
305038 by: Ashley Sheridan
305040 by: Peter Lind
305041 by: Arno Kuhl
305044 by: Al
305045 by: Ashley Sheridan
305046 by: Paul M Foster
305047 by: Al
305048 by: Peter Lind
305049 by: richard gray
305054 by: David McGlone
Re: PHP Encoder like IonCube
305034 by: Ashley Sheridan
305035 by: Peter Lind
305036 by: shiplu
305037 by: Phpster
305039 by: Ashley Sheridan
Re: xpath help
305042 by: Gary .
-----json and php----help
305043 by: shahrzad khorrami
How to get input from socket client
305050 by: Ryan Sun
305051 by: Bob McConnell
PHP Image Host - Sending HTTP Headers Twice?
305052 by: APseudoUtopia
Re: simplexml choking on apparently valid XML - Solved
305053 by: Brian Dunning
regexp questions
305055 by: Spud. Ivan.
Administrivia:
To subscribe to the digest, e-mail:
php-general-digest-subscr...@lists.php.net
To unsubscribe from the digest, e-mail:
php-general-digest-unsubscr...@lists.php.net
To post to the list, e-mail:
php-gene...@lists.php.net
----------------------------------------------------------------------
--- Begin Message ---
-----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
--- End Message ---
--- Begin Message ---
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
--- End Message ---
--- Begin Message ---
On 10 May 2010 13:58, Ashley Sheridan <a...@ashleysheridan.co.uk> 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
--
<hype>
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
</hype>
--- End Message ---
--- Begin Message ---
_____
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
--- End Message ---
--- Begin Message ---
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":
<?php
require_once $_SERVER['DOCUMENT_ROOT'] . '/editPageSR/editPageSR.php'; //do not
change
?>
Can't get any simpler.
3} Unless the site is small and has few pages and applications, it is almost
impossible to maintain.
--- End Message ---
--- Begin Message ---
>
> 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
--- End Message ---
--- Begin Message ---
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
--- End Message ---
--- Begin Message ---
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.
--- End Message ---
--- Begin Message ---
On 10 May 2010 18:17, Ashley Sheridan <a...@ashleysheridan.co.uk> 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
--
<hype>
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
</hype>
--- End Message ---
--- Begin Message ---
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
--- End Message ---
--- Begin Message ---
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.
--- End Message ---
--- Begin Message ---
On Mon, 2010-05-10 at 12:42 +0600, shiplu wrote:
> On Mon, May 10, 2010 at 6:28 AM, donald sullivan <don...@nixspot.com> 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
--- End Message ---
--- Begin Message ---
On 10 May 2010 13:25, Ashley Sheridan <a...@ashleysheridan.co.uk> wrote:
> On Mon, 2010-05-10 at 12:42 +0600, shiplu wrote:
>
>> On Mon, May 10, 2010 at 6:28 AM, donald sullivan <don...@nixspot.com> 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
--
<hype>
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
</hype>
--- End Message ---
--- Begin Message ---
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 <a...@ashleysheridan.co.uk> wrote:
> On Mon, 2010-05-10 at 12:42 +0600, shiplu wrote:
>
>> On Mon, May 10, 2010 at 6:28 AM, donald sullivan <don...@nixspot.com>
>> 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)
--- End Message ---
--- Begin Message ---
On May 10, 2010, at 7:36 AM, Peter Lind <peter.e.l...@gmail.com> wrote:
On 10 May 2010 13:25, Ashley Sheridan <a...@ashleysheridan.co.uk>
wrote:
On Mon, 2010-05-10 at 12:42 +0600, shiplu wrote:
On Mon, May 10, 2010 at 6:28 AM, donald sullivan
<don...@nixspot.com> 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
--
<hype>
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
</hype>
--
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
--- End Message ---
--- Begin Message ---
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 <a...@ashleysheridan.co.uk> wrote:
> > On Mon, 2010-05-10 at 12:42 +0600, shiplu wrote:
> >
> >> On Mon, May 10, 2010 at 6:28 AM, donald sullivan <don...@nixspot.com>
> >> 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
--- End Message ---
--- Begin Message ---
On 5/9/10, Peter Lind wrote:
> On 9 May 2010 10:31, Gary wrote:
>> If I have a document containing, say:
>> <html>
...
>>
>> 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.
--- End Message ---
--- Begin Message ---
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
--- End Message ---
--- Begin Message ---
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
<?php
$socket = stream_socket_server("tcp://127.0.0.1:1037", $errno, $errstr);
if(!$socket)
{
echo "$errstr ($errno) \n";
}
else
{
while($conn = stream_socket_accept($socket))
{
echo "New connection \n";
fwrite($conn, "Hello World \n");
fwrite($conn, "Do you want to close server? Yes(Y)/No(N) \n");
if(!feof($conn))
{
$answer = fread($conn, 1);
if($answer == 'Y')
{
echo "User choose to close server. \n";
break;
}
elseif($answer == 'N')
{
echo "Service continue... \n";
}
else
{
echo "Unknown answer '$answer'. \n";
}
}
fclose($conn);
}
fclose($socket);
}
and the client
<?php
$socket = stream_socket_client('tcp://127.0.0.1:1037', $errno, $errstr);
if(!$socket)
{
echo "$errstr ($errno) \n";
}
else
{
$answer = "Y";// fgets(STDIN)
fwrite($socket, $answer);
while(!feof($socket))
{
echo fread($socket, 100);
}
}
everything works, but if I write after read in client
<?php
$socket = stream_socket_client('tcp://127.0.0.1:1037', $errno, $errstr);
if(!$socket)
{
echo "$errstr ($errno) \n";
}
else
{
while(!feof($socket))
{
echo fread($socket, 100);
}
$answer = "Y";// fgets(STDIN)
fwrite($socket, $answer);
}
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?
--- End Message ---
--- Begin Message ---
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
<snip>
> 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
--- End Message ---
--- Begin Message ---
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?
--- End Message ---
--- Begin Message ---
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.
--- End Message ---
--- Begin Message ---
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
--- End Message ---
