php^servlet^ASP mkt share — php’s market share among top 100 sites — shows java (presumably 99% servlet-based) is the #1 choice for heavy traffic sites but across all sites, php has 80% market share. is another major player.


migrate between jsp & php

Hi LS,
Ideas for the migration, if migration is on your mind.
Inside or outside the database,
* squeeze as much business rules into DB as possible. Unique constraints, referential integrity (triggers), check constraints, input validation constraints for insert/update/delete, not-null constraints, stored proc, triggers, user-defined functions …
* Without an enormous effort, you can move every single SQL out of java/php/asp source and into some (xml) “query-listing” file. Every SQL sent to the DB will be taken from this listing. Performance penalty can be managed with some kind of simple caching, which I think can be quite effective.

* Many if not most jsp projects encourage a DAO pattern, sometimes quite elaborate or sophisticated. PHP supports DAO patten in PEAR::DB, albeit lightly. It helps your migration. However, small PHP sites may not warrant the extra effort

* Avoid Object-Relational-Mapping tools such as Hibernate or iBatis, since PHP isn’t comfortable with ORM yet.

With regard to so-called “presentation layer” or page templates
* smarty and JSP-EL/JSTL are highly recommended. They are simple and straight-forward. With them you can create templates free of business logic. The only “programming” remnants left in the template are simple variables, and the simplest loops and if-then-else — all easy stuff to migrate between jsp and php.
* squeeze as much business logic into javascript as possible. Over the years, more and more functionalities have become transferrable from server-side to javascript
* Not sure if AJAX is necessary for your site. AJAX requires you to create special server-side components. The browser-side ajax function communicates with the server-side components. Server-side components are coded in php or java or asp.
Lastly, we finally turn our attention to the jsp/php files. Even with the DB/presentation layer hacks, some, perhaps the bulk, of the functionality may remain in your java/php source code. You need to think of server-side software design ideas that are transferrable between jsp/php/asp. Many things to consider. Here are A few trivial items.
* avoid servlet/jsp forward. I don’t think php supports it.
* PHP guys tend to put a few related functionalities into one php file, motivated by maintainability, readability and other reasons, whereas jsp/servlet tends to separate them into individual jsp files (even separate javabean/servlet classes). The java approach is viable in PHP too, and helps migration.
* If you need automated testing, consider black-box test tools. These are transferrable and agnostic to the server-side language, be it jsp or asp or whatever

php oo match`java@@

The claim: php is 70% as competent as java, in terms of OO features to model and design a system. I think it’s below 70%.

* polymophism, dynamic bind` @@
* strongly typed — fundamental to OO system design
* A java return type can be declared as an interface/abstract type, so clients can safely use an expected service of the interface
* inner class for OO design
* more access modifiers
* Constructor chain reaction up to Object@@
* overload@@
* custom classloader
* factory, singleton and other patterns
* java proxy to implement AOP
* distributed components — RMI, corba… important for some enterprise systems.

each object’s wait set

— surprises
custom exception@@ yes

smarty vs View # mvc in j2ee

smarty is an extremely well-defined, simple and above all, concrete, implementation of many abstract concepts. Suprisingly, I used and studied struts many times more than smarty but I understand smarty better.

We can use smarty as a starting point or reference point to understand views in struts MVC.

In fact, jsp Expression Language and JSTL also mirror smarty.

* request object = a huge nested php object passed into smarty template
* afward = a logical name (no such thing in smarty) for a “physical” view
* forward request to a view =
* controller as request router =

pdo == php data obj

similar to DBI/DBD — one vendor-independent component + one vendor-specific component

how PDO compares to other popular abstraction layers out there, for example, PEAR DB or ADODB. pdo is lighter than either of those, both in terms of API and in terms of performance.

mysql stored procedure is ok with pdo but not pear::db

Many folks resort to a data abstraction layer, such as Pear::DB or DBX. Using a data abstraction layer is a good thing, but its main goal is to make the RDBMS transparent, allowing you to change database vendors fairly easily.

php iview questions 20 Jul


Thanks. They did ask about xml, object-oriented php …

q: any object-oriented php framework you used, such as zend framework

q: what’s the object-oriented MVC architecture?

q: how object-oriented is the data access layer?

This xml question was tough, because they decided to drill down right to the limits of the interviewee’s understanding of a past project.
q: in your project, how did xml help flash-php integration.

—– Original Message —–

> Hi, how was your php interview? Guess you must have done it well. Did you meet any unexpected tough questions?


Evolution-wise, I think the closest thing before ror is “object-oriented MVC with smarty and PEAR::DB”, just like bracketology, which offers a unique entry point to the confusing world of ror.

In Rails, if you have, for example, a BlogController and it has a method called list, Rails will automatically use the list.rhtml file inside of a folder called blog in your views folder. Not only that, but Rails will automatically pass on any instance variables you were using in the controller so that the view has access to them.

Now, when I am doing something similar in my own PHP apps, I have to manually instantiate the template object, manually pass references to any variables I know the view will be interested in and then manually tell it what template file to use. While all that manual code is pretty simple and easy to write, on even medium-sized apps it starts to take a toll on the leaness of the codebase.

I think he’s referring to something similar to smarty. Looks like this “convention over config” slogan is one aspect of the evolution from smarty -> ruby-on-rails

Other ror innovations over php?

php AR q&&a

query cache ] pdo?
session expiry?
persistent db connection?
db cache?
connect to a db cluster?
cluster between 2 php servers? with session failover?
php web server, static web server, proxy
multi-threading issues?

Q: Remember the NBC invisible dual-host cluster with different date? How do you duplicate the sessions? Or you don’t because each session is needed only in one host due to session-based load routing?

types of php var scope#q

“private” keyword? probably not a scope modifier but an access modifier? Scope refers to visibility.

“static” keyword within functions? visibility unaffected

( Maybe it’s easiest to list all of them as a whole. )

“global” keyword?


default scope of var in function?

default scope of var outside function?


PHP imitating java@@

hard to remember a long list. i think it’s good to “study” or focus on 2 items each week

–promotion items
garbage collector

–the rest
serialize and unserialize(!)
output buffer
copying a var by ref ^ by value (clone)
return by ref
pass by ref
new (without parenthesis)? yes
finalize()? yes. known as __destruct()
constructor? yes but no automatic chain
static (i.e. class-level) attributes and method? yes
final method? yes
private/public/protected attributes AND methods? yes
getter/setter? yes.
extends? yes
interface? yes
abstract method? yes
abstract class? yes
method/attribute overriding? yes
implements iface1, iface 2? yes
object serialization? yes

php packages4people build`a simple site

Mambo, moodle, phpnuke, drupal are some of the well-known php “content management” packages. I once used mambo and moodle. Exellent quality and usability.

These open-source packages can help a lay person put together a website quickly. Compared to a from-scratch approach, a package offers, among other things,
* nicer web pages
* perhaps faster development, if the package supports your requirement
* fewer bugs, better tested

There are drawbacks.

* Your custom database logic may be harder to implement.

* I feel you would have a hard time understanding the source code — dozens of source files, containing thousands and thousands of lines — before you can “hack” the code.
* you may realize you only need 1% of the source code to implement your requirement. It would have been far more manageable if you could throw away the other 99%. Not easy.

If you have time to search, see if you can find some bare-bones php “content management” mini-packages. If you find one, let me know.