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.

–thread-related
each object’s wait set
monitor

— 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

http://www.onlamp.com/pub/a/php/2004/08/05/dataobjects.html

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

JL,

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?