Re: future(PHP) != J2EE && future(PHP) == in(J2EE) (was: Function caching...)

Hi Jacob! On Sat, 09 Dec 2000, Jacob Verhoeks wrote: > On Saturday 09 December 2000 06:32, Ron Chmara wrote: > > Ulf Wendel wrote: > > > Jacob Verhoeks wrote: > > > > I'm developing a large web application. > > > > The code is very large now (2mb). > > > > Across, what, 30 pages? 50 pages? > > (er.... PHP isn't about writing one application, on one page. It's > > about writing different components which are tied on different page > > calls. If you're loading 2mb of PHP for every page, that's a design > > problem. 2MB of PHP across many pages of a massive accounting > > package, that I can see....) > > we don't have pages, we use a rewrite rule to redirect everything to one > index.php which then loads and parses a template based on the uri. May I throw my .2c in here? Thanks :) I read alot of this thread and I'll be short. What I read looks damn pretty much alike J2EE specs. on what its technologies provide. Here is an useful link : http://java.sun.com/j2ee/j2sdkee/techdocs/guides/ejb/html/DevGuideTOC.html The J2EE platforms offers *all* the functionalities Kristian asked for in PHP and tons of other. It comes with the nicest OO design I ever sow. All you need is there. You can use it. Now, PHP can run in a servlet context, right? What stop ppl like Kristian, Ulf and the others who asked for such great functionalities from enabling PHP scripting in JSP pages? From that point you can use all the power of J2EE w/o knowing Java (as a senior programmer would be requested to). Remeber JavaScript? It's one of the simplest and easier to use on client side pages (unless some JS gods make some voodoo DHTML using it, making you think it's obsure when you look @ their code). You can write JSP pages in JS (yes, server side), how cool! Why doesn't it happen the same with PHP? Why invent another Application Server Architecture when the top technicians from Sun,IBM, Oracle, Microsoft and other top companies worked on J2EE technologies specifications. You can hook into it. --- sorry for the length, cut here eventually --- some of Kris points this approach would address: * benefits from multitreading web containers (talking about scalability) * java.lang.SecurityManager is far better than safe_mode * on database connections - it has connection pooling, plus standard architecture for heterogeneous data sources (EISs) through J2EE connectors. WTF are these? (http://java.sun.com/j2ee/connector/) "The J2EE Connector architecture defines a standard architecture for connecting the J2EE platform to heterogeneous EISs. Examples of EISs include ERP, mainframe transaction processing, database systems, and legacy applications not written in the Java programming language." * Enterprise Java Beans address persistence (http://java.sun.com/products/ejb /faq.html). You have session and entity beans which covers most of the needs, who can have per page/connection/session/application context. * "large networks"? RMI/IIOP, there you go.Don't mind about it, think in term of distributed computing, distributed load. * XML/XSLT Intergration. Nothing more to add. * running in the same context of the same process? No more in the same process context, but in the same (not necesarely) web container, sharing resources and the like. And you had separated already the tasks of providing the content (PHP in Servlet context) from serving it (Apache or whatever happens to be the web server). So my question is, why don't we *exploit* the good work of Sam Ruby? :) -- teodor