SitePoint Sponsor

User Tag List

Page 2 of 3 FirstFirst 123 LastLast
Results 26 to 50 of 64
  1. #26
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by mariuszn3 View Post
    I see the point (or not really yet ) - but wouldn't it be just benefit if we could share objects (the way we can share primitive data now) between script calls?
    Databases are quite good at handling concurrency issues. If multiple threads are to share the same memory, you need to make your application thread safe.

    That said, I question how much performance boost we're actually looking into. Databases cache results in memory, so they are effectively a form of shared memory.

  2. #27
    SitePoint Guru
    Join Date
    Feb 2006
    Location
    Pittsburgh, Los Angeles
    Posts
    706
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    The fact that everything dies at the end justifies the huge benifit that PHP has over a multitude of other languages
    And these benefits are?
    other technologies today are jealous of what PHP
    I didn't know technologies could be jealous.... The developers certainly aren't jealous, other developers mainly just crack jokes about PHP.
    Take a look at the resource hog that Java has become in recent years?
    I must've missed this, I have no trouble running Java apps on old P3 servers. The only resource you could be talking about is memory, but in fact PHP is just as memory hungry when the application is being worked. PHP's platform only uses less resources for small apps, hence why its so great for shared hosting.
    but the state must be transferred to the client.
    Eh? How does one transfer a session to a client?
    I question how much performance boost we're actually looking into. Databases cache results in memory, so they are effectively a form of shared memory.
    The database knows nothing about your application as a result its cache is far less useful. Also, there is still the overhead of actually connecting to the database in the first place. This overhead is even greater if the app and the database aren't on the server. Accessing things from a local cache is an many times faster, now whether this is important for your application is a different story.

  3. #28
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    > other developers mainly just crack jokes about PHP.

    They are cracking the jokes because they are envious of the success of PHP; It's a basic human need to make fun of something or someone they don't understand, nor have the interest to understand.

    At the end of the day though, can you name just one technology that has been as much a success as PHP? Honestly I mean?

    > I have no trouble running Java apps on old P3 servers.

    What sort of applications were you running, and could you run one of todays enterprise level applications on one of your Pentium 3s? I sort of know your answer already...

    > PHP's platform only uses less resources for small apps, hence why its so great for
    > shared hosting.

    Shared hosting has got nothing to do with it; In fact, if anything it just goes to show you just how performance oriented PHP is in regards to the limited resources that shared hosting are, by their nature, in relation to the amount of load on that given server.

    PHP from what I can remember on reading something on Zend uses about 40% less memory than typically what is required by the likes of Java; Unfortunately you'll just have to take my word on that as I don't recall the URL... But the differences were far from marginal to say the least, between Java and PHP; Again, that of course is dependent on a lot of other variables, etc.

    Maybe the results were shewed a bit, I don't know - I didn't perform the benchmark, but the feeling I have is that PHP performs better than what Java would perform on reduced technology, hardware wise that is.

    > And these benefits are?

    Have you not heard of the share nothing phrase?

    > This overhead is even greater if the app and the database aren't on the server.

    That isn't an issue as such to do with PHP though... It's a problem that is commonly shared with all technology using the Internet. Latency it's called I think?

  4. #29
    SitePoint Guru
    Join Date
    Feb 2006
    Location
    Pittsburgh, Los Angeles
    Posts
    706
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    At the end of the day though, can you name just one technology that has been as much a success as PHP? Honestly I mean?
    Lets get real here. Nobody denies that PHP has been sucessful in some sense, but PHP success is primarily with small web apps. Also I have no idea what metric you are using for "success". Sure if we are talking about small web apps PHP has been largely successful, but Perl + cgi was also very sucessful in this same domain. But if you are talking about backends then PHP is rarely used, PHPs "share nothing" architecture makes no sense in these contents.
    Have you not heard of the share nothing phrase?
    Ugh, sure I've heard that marketing buzz word. Now, what are the real advantages of PHP for large applications? How does not sharing data between requests benefit a large application? It doesn't benefit scabability, the application will be scalable if its distributable (which can easily be done with Java or .NET). On the other hand the advantages for small apps are clear.
    That isn't an issue as such to do with PHP though... It's a problem that is commonly shared with all technology using the Internet.
    Sure, but if you could persistent objects than you can boost performance by caching. And its not just a small boost, accessing a local in-process cache is dramatically faster than accessing a cached query from a database running on a remote server. Almost every language has a way of doing this (Perl with mod_perl, Python with mod_python, java out of the box etc), but not PHP.

  5. #30
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Snaily View Post
    Eh? How does one transfer a session to a client?
    You don't. Session is a method for storing state at the server.

    Quote Originally Posted by Snaily View Post
    The database knows nothing about your application as a result its cache is far less useful. Also, there is still the overhead of actually connecting to the database in the first place. This overhead is even greater if the app and the database aren't on the server. Accessing things from a local cache is an many times faster, now whether this is important for your application is a different story.
    Depending on your application, the database may in fact know quite a bit. If you have indices and foreign keys on your tables, it can cache rather intelligently.

    Quote Originally Posted by Snaily View Post
    Also, there is still the overhead of actually connecting to the database in the first place. This overhead is even greater if the app and the database aren't on the server.
    But that argument assumes that you can get away with not connecting at all. Is that realistic in an even moderately complex application? Oh, and I believe that you can use connection pooling if the db is non-local.

  6. #31
    SitePoint Guru
    Join Date
    Feb 2006
    Location
    Pittsburgh, Los Angeles
    Posts
    706
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    You don't. Session is a method for storing state at the server.
    You said "but the state must be transferred to the client", are you suggesting that one shouldn't use sessions? Maybe, I misread your initial comment.
    But that argument assumes that you can get away with not connecting at all.
    Right in PHP that doesn't happen much because you store so much junk in the DB, but that isn't necessary with other platforms. So in many cases you can get away with no database calls on cached data.
    Oh, and I believe that you can use connection pooling if the db is non-local.
    PHP doesn't allow connection pooling, rather you can only have persistent connections in PHP. This differs in fundamental ways from connection pools, it would work ok in apache 2 with threads....but PHP isn't thread friendly (or I should say many of the extensions commonly used aren't)

    Anyhow, its not just the issue of creating a connection. Its also the cost to grab the data, grabbing cached data (usually stored in a hash) from local memory is extremely fast where as even if the DB is intelligently caching your data you still have to grab the data over a socket, which in the case of a remote database can be fairly expensive. I'm not suggesting that having the ability to persist objects is always useful, but in many cases it can boost performance significantly. Additionally, having the ability to persist objects does not effect the platforms ability to scale. Personally I find the "in PHP you can scale your app by just adding hardware" view rather naive, most of the PHP apps I have seen would not scale out of a single server as they are currently implemented.

  7. #32
    SitePoint Enthusiast
    Join Date
    Feb 2006
    Posts
    68
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Even though PHP has a stateless architecture, you can cache things in memory, just take a look at Memcached.

  8. #33
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I don't believe though that you can cache a resource, and that is what the discussion is about in part at least? Which... Has lead to this arguement between the architecture of PHP and other technology.

    I can't really express myself in a way that fits words on how PHPs architecture, being stateless so to speak (nothing lives once script execution ends) is better than other technology that retains state, nor can I find facts at the moment either.

    But there are blogs out there that describe better than what I could, as to why PHP is scales better in a lot of regards.

  9. #34
    SitePoint Evangelist
    Join Date
    Jun 2003
    Location
    Melbourne, Australia
    Posts
    440
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Snaily, you've quite often bagged PHP to an extent that I get the impression that you wouldn't actually use it. So I'm prompted to ask why do you spend so much effort participating in this forum?

    That's a little harsh and I don't mean to be glib. You seem to understand a great deal about web architectures and your arguments may well be valid. What's frustrating to the uninformed like me is that such arguments tend to concentrate on very abstract explanations rather than concrete examples or use cases. This is a call to everyone: it would be great if you could provide an example that illustrated something like:
    With [PHP or Java], if you did this under these conditions, the following would happen...

    Er, Dr Livingston, I hesitate to say this ... I'd suggest that until you
    Quote Originally Posted by Dr Livingston View Post
    really [can] express [your]self in a way that [explains] how PHPs architecture, being stateless ... is better than other technology that retains state
    you might want to think twice about arguing with Snaily.
    Last edited by auricle; Apr 21, 2007 at 17:56. Reason: typographical error
    Zealotry is contingent upon 100 posts and addiction 200?

  10. #35
    SitePoint Addict
    Join Date
    Apr 2004
    Location
    Melbourne
    Posts
    362
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Having developed applications using both PHP and Java, I personally feel that for a web frontend PHP just works better than any of the Java technologies (JSP, JSF, Wicket, very small amount of Struts) that I've used. However, for the actual backends to websites, there are a lot of benefits to java's statefulness; technologies like Spring just fit that role so nicely.

    That said, I think something like Grails is slowly getting to the point of being something I could use instead of PHP on the frontend, with the benefit of being fully spring aware...

  11. #36
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Snaily View Post
    You said "but the state must be transferred to the client", are you suggesting that one shouldn't use sessions?
    Well, basically yes, although it was directed at stereofrogs comment.

    I think we may be talking about different things here though. We can distinguish between to types of state; There is the resource state, which is persistent data, such as the contents of an article etc. Then there is application state, which is information about a users previous interaction with the application, that has impact on subsequent requests.

    Resource state should naturally be stored at the server side, but because of how HTTP works, application state should as far as possible be managed by the client. Session is basically a mechanism for storing application state at the server. As such, it should be avoided, but some times usability just trumps purity.

    Theoretically speaking, a database and in-memory persistent objects could both be used to store either kind of state. If we take a look at how PHP applications are today, the distinction between resource and application state is nicely divided between databases on one side and either session or transferred state on the other.

    I think that if PHP had persistent objects, it would blur out the distinction between the two types of state, and they would encourage developers to put more application state at the server. By this, i don't mean to be condescending about PHP programmers; I believe that the language can promote certain solutions over others, and PHP's die-with-the-request model promotes stateless applications.

    So call me conservative, but I fear that persistent objects would be worse from an architectural viewpoint. Any performance gains would have to make up for that.

    Quote Originally Posted by Snaily View Post
    Right in PHP that doesn't happen much because you store so much junk in the DB, but that isn't necessary with other platforms. So in many cases you can get away with no database calls on cached data.
    I prefer to have my "junk" in a relational database, rather than in-memory objects.

  12. #37
    SitePoint Guru
    Join Date
    Feb 2006
    Location
    Pittsburgh, Los Angeles
    Posts
    706
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    So I'm prompted to ask why do you spend so much effort participating in this forum
    I assume you're talking about PAD and not Sitepoint in general, but really I don't post much in PAD. Also, I'm not really trying to bash PHP, its a great language for many jobs (and yes I don't use it that much). The only thing I'm trying to argue is that some of PHP limitations...aren't "features" and something good as Zend's marketing would suggest. Rather they are genuine limitations of the platform when its used for largish sites. Also, what sort of concrete examples did you want?
    As such, it should be avoided, but some times usability just trumps purity.
    "Some times", I don't know many interesting sites that don't require sessions (i.e., application state).
    and they would encourage developers to put more application state at the server.
    From my experience your typical PHP app uses the local file system all the time for application state, so if these limitations are suppose to encourage developers to write more stateless apps, it doesn't seem to be working. I think for good reason, most applications require state. So you have two cases: 1.) Your application is stateless, in which case horizontal scaling is trivial due to the statelessness of the application. But the application will remain stateless if it was implement in Java, .Net etc too. 2.) Your application has state, here horizontal scaling is not trivial for any platform. You are going to spend just as much time making your PHP application scale in this case than you are if you wrote it in Java or .NET. But here the "enterprise" platforms actually have an advantage because there are out-of-the-box solutions for session replication etc. So despite Zend's marketing its unclear what advantage PHP's architecture has outside of small applications.

    Also, this isn't a limitation of the language itself, rather mod_php. You could create a module that instead works like mod_perl or mod_python (I think there is one...but its not stable).
    I prefer to have my "junk" in a relational database, rather than in-memory objects.
    Why? Do you just like SQL? Its much easier just to hold it in memory.

  13. #38
    SitePoint Guru thr's Avatar
    Join Date
    Jun 2003
    Location
    Sweden
    Posts
    664
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Snaily
    "Some times", I don't know many interesting sites that don't require sessions (i.e., application state).
    I think kyber was talking about sessions as a technique rather then that "you have to use sessions somtimes".

    Quote Originally Posted by Snaily
    From my experience your typical PHP app uses the local file system all the time for application state, so if these limitations are suppose to encourage developers to write more stateless apps, it doesn't seem to be working. I think for good reason, most applications require state. So you have two cases: 1.) Your application is stateless, in which case horizontal scaling is trivial due to the statelessness of the application. But the application will remain stateless if it was implement in Java, .Net etc too. 2.) Your application has state, here horizontal scaling is not trivial for any platform. You are going to spend just as much time making your PHP application scale in this case than you are if you wrote it in Java or .NET. But here the "enterprise" platforms actually have an advantage because there are out-of-the-box solutions for session replication etc. So despite Zend's marketing its unclear what advantage PHP's architecture has outside of small applications.
    The Java argument I can take, but it just something that makes me dizzy when someone suggests .NET on Windows as an Enterprise architecture. Other then that, session replication isn't that hard to set up - and even if php takes a bit longer to setup for scaling the total time spend coding the application is alot less then the equivalent java app. Remember, processor cycles are cheap - programmers are not.

    Quote Originally Posted by Snaily
    Why? Do you just like SQL? Its much easier just to hold it in memory.
    Think you missunderstood kyber again actually.


    (If my response looks wierd in any way I just changed my main platform to Mac from *Nix/Win today and trying to get settled in, just found the IM-client, woho!)

  14. #39
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by thr View Post
    I think kyber was talking about sessions as a technique rather then that "you have to use sessions somtimes".
    Exactly.

    Quote Originally Posted by Snaily View Post
    From my experience your typical PHP app uses the local file system all the time for application state, so if these limitations are suppose to encourage developers to write more stateless apps, it doesn't seem to be working.
    I think it could be a lot worse. I can't even imagine the monstrosity that phpBB2 would be, if they had access to shared memory.

    Quote Originally Posted by Snaily View Post
    Why? Do you just like SQL? Its much easier just to hold it in memory.
    Yes, I like SQL. It's much easier to find data in a database, and it's much easier to manage concurrency in a database.

  15. #40
    SitePoint Guru
    Join Date
    Feb 2006
    Location
    Pittsburgh, Los Angeles
    Posts
    706
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    It's much easier to find data in a database, and it's much easier to manage concurrency in a database.
    Its not easier to find data in a database, you have to query it. If it was in memory you could have a reference to it (the type of "data" I'm talking about here is configuration information that is often stored in the DB when using PHP, that is the "junk"). Also if the data is immutable then there are no concurrency issues, but dealing with concurrency when using Java or .NET is a given.
    I can't even imagine the monstrosity that phpBB2 would be, if they had access to shared memory.
    It may be worse, I dont' know. But I don't think this is a strong line of reasoning, "Feature X can be abused so the language should not allow it". You should be making the same argument against persistent connections in PHP, they violate the "share nothing" architecture and can be abused. Giving PHP the ability to persist objects by default would kill the platform, but allowing it in the platform as an option would be nice and would give developers more options when their applications have performance problems. Something interesting is that if you look at threads regarding performance problems with PHP they solutions are always hardware related (what does your my.cnf look like? etc etc), then look at what people say when you have the same performance problems in other platforms. The solutions often start with software relates solutions. I interpret this as slowing that PHP's platform gives developers much less options when it comes to performance problems.
    Other then that, session replication isn't that hard to set up
    How do you do it in PHP? I suppose if you were storing sessions in the DB and were already replicating data there it would work. But this solution can really put strain on your DB. So if the sessions on the local computer, how can you have session replcation in PHP? Maybe there is a way, but I don't know what it is.
    total time spend coding the application is alot less then the equivalent java
    I really don't believe this, do you have a study that shows this? Certainly its true if we are talking about 3 page scripts, but for real applications? I think its just something that gets repeated but without justification. I've written applications in Java and PHP and certainly you have to write less code with PHP, but Java has absolutely amazing IDEs that save you tons of time when you re refactoring etc. So at least from my experience initial application development may be a bit faster in PHP, but application maintenance is faster in Java due to the IDEs available. In the end its pretty much a toss-up, did you have a different experience?
    app.
    Remember, processor cycles are cheap - programmers are not.
    This argument only holds water if we are talking about an applicatin on a single server. But as soon as your application can't live on a single server then its going to cost you in developer time (and more so as your application grows).
    So having more tools to solve performance problems can save you a lot of money by not having to add application servers.

  16. #41
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Umm...

    > This argument only holds water if we are talking about an applicatin on a single server.



    That is true is what I've found myself, but it's the only thing in this entire thread that I can agree with you, on. This, however I have to disagree with you on...

    > but allowing it in the platform as an option would be nice and would give developers
    > more options when their applications have performance problems.

    That I belive wouldn't particularly help with performance issues, more so in regards to PHP, even if it's just an option. The huge benifit of PHP is it's architecture, something which the language has picked up on and prospered on.

    It's due to this architecture, that the only real option to scale with PHP is from the hardware side of things; That is something I believe in firmly - software is only every capable of so much, so yes... Throw more hardware at it is my thoughts on it.

    Trying to gain 0.1% more performance enhancement from your horrendously under pressure application with a cache of persistable data is bordering on lunacy; You have got to remember that all data dies at some point in the applications life.

    You therefore have to maintain that cache, regardless of how it's persisted; That maintenance is a resource hog in of it's self; It's that resource hogging that at the moment, PHP doesn't have to deal with, thank you God!!

    Really...

  17. #42
    SitePoint Zealot
    Join Date
    Jul 2006
    Posts
    101
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Maybe I've got the wrong end of the stick here but I don't see the advantage of storing objects in memory. The amount of time it takes to load even a complex page is minute compared to the average time a user spends viewing it. Doesn't this mean a lot of wasted memory where information sits doing nothing but waiting for the user to click on the next page? Basically doesn't this just swap the hardware cost from buying more/better CPU's to more/better RAM?

  18. #43
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Snaily View Post
    If it was in memory you could have a reference to it.
    You still have to find it, before you have a reference to it. The HTTP request is just a stream of text. Normally, this will contain some sort of unique identifier of an object (Presumably embedded in the URL). Translating such an identifier to an object is what databases excel at.

    The only alternative to using the request to identify your object, is to maintain application state at the server ...

    Quote Originally Posted by Snaily View Post
    the type of "data" I'm talking about here is configuration information that is often stored in the DB when using PHP, that is the "junk" ... Also if the data is immutable then there are no concurrency issues ...
    I don't see why one would put static data in mutable storage in the first place. Configuration information is meta data. It's best expressed through code - not configuration files. And certainly not configuration files persisted in a database.

  19. #44
    SitePoint Guru
    Join Date
    Feb 2006
    Location
    Pittsburgh, Los Angeles
    Posts
    706
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    That I belive wouldn't particularly help with performance issues, more so in regards to PHP, even if it's just an option.
    You're free to think that, but I'm more interested in the reason why you think that. Its unclear why it helps so many other platforms, but wouldn't help PHP.
    Trying to gain 0.1% more performance enhancement from your horrendously under pressure application with a cache of persistable data is bordering on lunacy
    Yeah that is lunacy, fortunately the performance boost received from local caches is dramatically greater than 0.1%. For example, I work on a fairly busy e-com site written in Java. If you turn the cache off the server loads become high and response time decreases on average by about 40%. Turn it on the applications works great with mild server loads.
    That maintenance is a resource hog in of it's self; It's that resource hogging that at the moment, PHP doesn't have to deal with, thank you God!!
    I'm not sure if you are talking about the increase in memory usage if you are caching or development time. So, I'll response to both. 1.) PHP hogs different resources - CPU cycles and IO. These are harder to deal with then memory which is cheap to add. 2.) Adding caching to an application isn't hard. Usually you are already going to be using some sort of ORM solution (even if its just a simple DAO), from this your cache is simply a hash between the object and the key(s) you used to grab it in the first place. It can be as simple as:
    PHP Code:
    public class ProductDAO {
       
        private 
    $cache = array();

        public 
    getProduct($id) {
            
    $product $this->cache[$id];
            if(!isset(
    $product)) {
                 
    $product loadProduct($id);
                 
    $cache[$id] = $product;
            }
          return 
    $product;
       }

    It's best expressed through code - not configuration files. And certainly not configuration files persisted in a database.
    There are a view issues here. 1.) Expressing it through code is not fundamentally different then expressing it in config files. For PHP I think its truly a matter of preference, but in compiled languages config files are superior since they can be changed without re-compiling the source. 2.) For many apps configuration information needs to be mutable, so that end-users can change it. 3.) Putting configuration details in code doesn't change the fact that you have to load the configuration details on each request and often have to include configuration details that is not required by the request.
    is to maintain application state at the server ...
    Sure, which is done on the vaste majority of applications regardless.

  20. #45
    SitePoint Guru dagfinn's Avatar
    Join Date
    Jan 2004
    Location
    Oslo, Norway
    Posts
    894
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken View Post
    Resource state should naturally be stored at the server side, but because of how HTTP works, application state should as far as possible be managed by the client. Session is basically a mechanism for storing application state at the server. As such, it should be avoided, but some times usability just trumps purity.
    The problem, as I'm sure you're aware, is that even usability suffers since nowadays many users are running the same application in multiple tabs or windows. In the test management tool I'm currently using, if I have two test specifications open at the same time (because I want to compare the old one to the new one), the existing test spec may be destroyed if I save the wrong one. (What I do to avoid it is open one in Firefox and the other in Opera.) BTW, this is not a PHP app, but it's the same problem: lots of info is stored in session and the app just can't handle two current objects of the same kind.

    What I do is try to avoid using sessions except for authentication.
    Dagfinn Reiersøl
    PHP in Action / Blog / Twitter
    "Making the impossible possible, the possible easy,
    and the easy elegant"
    -- Moshe Feldenkrais

  21. #46
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Snaily View Post
    There are a view issues here. 1.) Expressing it through code is not fundamentally different then expressing it in config files. For PHP I think its truly a matter of preference, but in compiled languages config files are superior since they can be changed without re-compiling the source.
    Exactly. And PHP is not a compiled language. What makes sense in Java, doesn't necesarilly extend to PHP.


    Quote Originally Posted by Snaily View Post
    2.) For many apps configuration information needs to be mutable, so that end-users can change it.
    In that case, it belongs in the model layer, and then it's not immutable.

    Quote Originally Posted by Snaily View Post
    3.) Putting configuration details in code doesn't change the fact that you have to load the configuration details on each request and often have to include configuration details that is not required by the request.
    If loading up code becomes a problem, you can apply an opcode cache.

    Quote Originally Posted by Snaily View Post
    Sure, which is done on the vaste majority of applications regardless.
    Those applications have a serious problem. I'm not arguing that you're right though.

    Quote Originally Posted by dagfinn View Post
    What I do is try to avoid using sessions except for authentication.
    Yes, but how would you implement PRG?

  22. #47
    SitePoint Addict
    Join Date
    Sep 2006
    Posts
    368
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Also I have no idea what metric you are using for "success".
    to add some oil to the fire

    http://www.google.com/trends?q=php%2...o=all&date=all

  23. #48
    SitePoint Enthusiast
    Join Date
    Oct 2005
    Posts
    66
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Talking

    Quote Originally Posted by Dr Livingston View Post
    At the end of the day though, can you name just one technology that has been as much a success as PHP? Honestly I mean?
    Can you name just one PHP e-commerce that has been as much a success as OSCommerce ?

    Stefano

  24. #49
    SitePoint Guru dagfinn's Avatar
    Join Date
    Jan 2004
    Location
    Oslo, Norway
    Posts
    894
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken View Post
    Yes, but how would you implement PRG?
    This looks like an interesting question, but I don't understand what you mean. What relationship between PRG and sessions are you implying?
    Dagfinn Reiersøl
    PHP in Action / Blog / Twitter
    "Making the impossible possible, the possible easy,
    and the easy elegant"
    -- Moshe Feldenkrais

  25. #50
    SitePoint Evangelist
    Join Date
    Mar 2006
    Location
    Sweden
    Posts
    451
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by dagfinn View Post
    This looks like an interesting question, but I don't understand what you mean. What relationship between PRG and sessions are you implying?
    It's quite nifty to store the form data in sessions and redisplay it after the redirect in the correct form fields.


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •