Want to use OOP on my website

[Debbie Dawson]

Hi, I have been programming for many years but never really learned object-oriented programming (OOP) beyond text-book examples.

I have LOTS of questions.

My end goal is to understand OOA/OOD well enough to code a modest website that uses solid OO practices, and maybe even some Design Patterns.

Right now I would like to build a simple website that allows users to register and then log-in.

Question:
- For a beginner like me, can I hard-code the HTML pages, and then just have Classes/Objects to take care of the business logic?

(Or to do an OOP website, does the OOP even create the webpages dynamically?)

I have lots more to ask, but maybe that is a question to break the ice?!

Sincerely,


Debbie

[Ernest Friedman-Hill]

Hi Debbie,

Welcome to JavaRanch!

Java web sites are ultimately built on servlets. We have a forum dedicated to the topic (see our front page). When you create a servlet, you extend a class and add your own code -- so that's OOP right there. It's hard to do much of anything in Java without at least some object-oriented practices.

Servlets can and do create web pages dynamically. Completely static HTML pages are pretty rare these days. Almost no-one uses raw servlets to do everything, though: there are many different frameworks built on top on the servlet APIs, and people ususually use one. You can take your pick: Struts and Stripes and GWT and Spring and JSF and you name it, including one called FrontMan maintained by our own Bear Bibeault, a sheriff here at the Ranch. Frameworks at every level, from simple to complex, easy to difficult, are available. These frameworks are generally all about implementing interfaces and extending classes -- i.e., they're all based on creating classes to fit into inheritance hierarchies: more OOP.

But you have to crawl before you can walk. One place to start learning about servlets is Ben Souther's page.

[Debbie Dawson]

Ernest Friedman-Hill wrote:Hi Debbie,

Welcome to JavaRanch!

Thanks!

Java web sites are ultimately built on servlets. We have a forum dedicated to the topic (see our front page). When you create a servlet, you extend a class and add your own code -- so that's OOP right there. It's hard to do much of anything in Java without at least some object-oriented practices.

Let me stop you there (and please don't stone me!!!)

My main goal coming here is to learn practical, real-world object-oriented design and programming. (Since this is a Java site, presumably there are people here that are pretty sharp with OOP?!)

I am actually going to build my website using PHP, but I still prefer to be here with the "Java gang" because I think I can get more sophisticated advice here on OOA/OOD/OOP.

Hope you guys will still help me?!

Servlets can and do create web pages dynamically. Completely static HTML pages are pretty rare these days.

Here was my thinking... (Remember that I am a newbie to OOP)

I can program a simple Registration Page using HTML that has a Form with Username, Password, First Name and a "Register" button.

When the user clicks "Register", then that is where my OO code would kick in.

I was going to have a class called "Registration" and it would contain all the Properties and Methods needed to register a user.

Almost no-one uses raw servlets to do everything, though: there are many different frameworks built on top on the servlet APIs, and people ususually use one. You can take your pick: Struts and Stripes and GWT and Spring and JSF and you name it, including one called FrontMan maintained by our own Bear Bibeault, a sheriff here at the Ranch. Frameworks at every level, from simple to complex, easy to difficult, are available. These frameworks are generally all about implementing interfaces and extending classes -- i.e., they're all based on creating classes to fit into inheritance hierarchies: more OOP.

Again, not to start a battle, but I'm pretty set on avoiding frameworks for now.

I think it will just overwhelm me.

I would rather learn how to hook up a class to a web-form - like I described above - and then as I get more comfortable how all of this works I can then consider taking bigger steps at automating things and possibly adopt a framework.

(It is better to learn how to ride a tricycle with expertise than to smash your skull on a Harley that you aren't ready for yet?!)

But you have to crawl before you can walk. One place to start learning about servlets is Ben Souther's page.

Well, since I am using PHP, that probably won't help.

But if you guys can help me take baby steps here, I'm sure I can apply most of what you'd do in Java and apply it to PHP. After all, OOP is OOP.



Debbie

[David Newton]

Right off the bat, I'll tell you that PHP is *not* a great place to learn OOP. And JiG isn't the right forum for general OO questions; you want OO, Patterns, UML and Refactoring, which is kind of a catch-all for all things OO. I'll move this post there.

My advice, if you're dead-set on using PHP, is to just start coding something in PHP, and see what happens: it's the easiest, most reliable way to learn. If you code yourself into a corner, back away slowly and figure out what went wrong, when it went wrong, and what makes you think it's wrong.

At *that* point you could post a question in OO, or in Other Languages, regarding specifics. There are *so* many ways to go about coding what you're doing that giving practical advice at this stage is tricky. I will say that the idea to have a Registration class that has all the properties and methods needed to register a user sounds a lot like what people would call a "service" class, but it depends on what you really mean by "all the properties and methods"...

I mean, a "user" is a separate entity--it would have its own set of user-specific properties. "Registration" is a concept involving a user, but is not a user. So if I were going about it, I'd have a class that snarfs the data from the web page, sends it to the registration service, which in turn creates a user and persists them somehow.

I tend to focus on "separation of concerns": each component should know as little as possible about the components around it. This makes things flexible. I prefer small over large, composable over fixed.

[Debbie Dawson]

David,

David Newton wrote:Right off the bat, I'll tell you that PHP is *not* a great place to learn OOP.

Why do you say that?

You do design, then implementation.

A good OOD should basically transcend how it is implemented?!

And JiG isn't the right forum for general OO questions; you want OO, Patterns, UML and Refactoring, which is kind of a catch-all for all things OO. I'll move this post there.

Oh, okay. As long as I can get some help! :)

My advice, if you're dead-set on using PHP,

Java has A LOT of implications (and costs) that PHP doesn't have.

Why do you make it sound so dirty? (Other than this *IS* a website for Java!!!) :rolling:

...is to just start coding something in PHP, and see what happens: it's the easiest, most reliable way to learn. If you code yourself into a corner, back away slowly and figure out what went wrong, when it went wrong, and what makes you think it's wrong.

Why code anything without a plan?

I'm not following how PHP upsets my plans of creating a decent design BEFORE I dive into code.

At *that* point you could post a question in OO, or in Other Languages, regarding specifics. There are *so* many ways to go about coding what you're doing that giving practical advice at this stage is tricky.

True, but I'm not asking anyone to do the design for me.

My goal was/is to come up with a "design game-plan" and then ask questions on here to see what people think.

For instance, I have a strategy for how to build the registration portion, but am uncertain about some design considerations as well as general OOP questions.

I will say that the idea to have a Registration class that has all the properties and methods needed to register a user sounds a lot like what people would call a "service" class, but it depends on what you really mean by "all the properties and methods"...

See, this is where I am hoping all of the gurus here can help me out?!

I create a simple design, post it here, get some questions, clarify my thinking, get some help, and then go code it and see how it works!

I mean, a "user" is a separate entity--it would have its own set of user-specific properties.

Can I explain my design/thinking at a higher level?

(I never know how to post stuff like this because I don't want to create a "God post" with a million things, and yet to get started you kinda have to do that!)

I can elaborate (or post) my back-end table design if that helps. I can also explain some ideas I have on beginning classes (e.g. User, Registration, etc.) if that helps?!

"Registration" is a concept involving a user, but is not a user.

I guess I am getting a "green light" to explain more...

*backing up*

One key thing I want to avoid that seems to be common in Procedural Programming is dumping tons of unrelated code into on giant bucket!! (OOP is *supposed* to encourage you to abstract complex problems into smaller and smaller and more re-usable pieces so that you can take a complex problem and break it down into manageable pieces.)

I just finished reading the book "Head First: Design Patterns" - which by the way revolves around Java - and while it was a big chunk to bite off for a beginner, two patterns that I saw some use in for my website was the "Strategy Patterns" and the "State Pattern".

It also stressed another key concept that I want to avoid... That classes have to be physical, tangible "nouns" and nothing else, and that all "verbs" are methods?!

In that book - and other things I've seen and read - it seems that the more *advanced* OO programmer understands you want to abstract out behaviors and processes as classes also. So, in the Head First book they took what most junior OOP'ers would label as "verbs" (and thus want to make "methods") and instead treated then as "things" which could be seen as "classes").

I think "Registration" would make a good class because it is a thing. ("Registering" may be a verb, but "registration" is a noun anyways!!)

** Sorry if this is too much for one thread!! **

So I was thinking of having a "Member" class and a "Registration" class for starters.

The "Registration" class would have properties like...

- email*
- password*
- firstName*
- lastName
- city
- state
- zip
- country
- acceptTerms*

*required

and it could have methods like...

- requiredFieldsComplete()
- isEmailUnique()
- isEmailValid()
- isPasswordValid()
- sendActivationEmail()
- activateAccount()

Of course that is just my first best guess having never written OOP before?! :confused:

(I also have some ideas about the "State Pattern" but will save those for later!!)

So if I were going about it, I'd have a class that snarfs the data from the web page,

Okay, I think we are getting closer...

** Again, sorry if this is too much for one thread!! **

So that was part of my OP.

Would it be okay to write an HTML webpage that has my HTML Registration Form and when the User clicks "Register" send it to my "Registration" class?

Or are you saying that I need another class to "snarf up the data"?? :mrgreen:

sends it to the registration service, which in turn creates a user and persists them somehow.

I think the "Registration" class I described above would do that part. And it would "persist" as you say because one of the methods (e.g. activateAccount() ) would write the "activated" User into the back-end "Member" table in my database...

I tend to focus on "separation of concerns": each component should know as little as possible about the components around it. This makes things flexible.

I agree 100%, and that is why I am trying to "plan" (i.e. OOA & OOD) before I "hack" (i.e. OOP without OOA & OOD)!!! :D

I prefer small over large, composable over fixed.

I agree again.

Okay, I'll shut up and what to *hopefully* hear back from you and all that I said!!

Sincerely,



Debbie

[David Newton]

Debbie Dawson wrote:A good OOD should basically transcend how it is implemented?!

OO*D*, sure. But not all OOPLs are created equal, and PHP does a disservice to OOPLs in general.

I don't *care* what you use, but out of all the choices available, PHP would be *really* low on my list.

Why code anything without a plan?

That's not what I said--I said just start. But the questions you're asking are too high-level to provide much specific help.

as well as general OOP questions.

Then ask them!

It also stressed another key concept that I want to avoid... That classes have to be physical, tangible "nouns" and nothing else, and that all "verbs" are methods?!

Why would you want to avoid that?

I think "Registration" would make a good class because it is a thing.

Perhaps, but I wouldn't call it "Registration". It's not *a* registration. *A* registration has things like the associated user, the date registered, what extras were registered for, etc. It's a registration service. It allows one to register.

The "Registration" class would have properties like... email, password, firstName, lastName, city, state, zip, country

How are those not part of the member/user class?

- isEmailUnique()
- isEmailValid()
- isPasswordValid()

Why would those be part of a registration? Are they not general-purpose methods that might be used elsewhere in the system? Or in a completely different system? These are not (necessarily) specific to registration.

Would it be okay to write an HTML webpage that has my HTML Registration Form and when the User clicks "Register" send it to my "Registration" class?

Sure, with the caveat that I'm not convinced I like the registration class. But like I said--why not just start? Analysis paralysis. You're not at the point in OOP where over-thinking is going to help.

[Petar Thomas]

Why code anything without a plan?

It stays.




(Code is a plan)

[Debbie Dawson]

David,

Geesh, you sounded angry.

David Newton wrote:

Debbie Dawson wrote:A good OOD should basically transcend how it is implemented?!

OO*D*, sure. But not all OOPLs are created equal, and PHP does a disservice to OOPLs in general.

Clearly you aren't a PHP fan.

All I know is that PHP makes much more financial and coding sense for someone in my shoes, and it clearly can produce enterprise-level websites.

When I become rich and an OO expert, then I can re-engineer my site using the latest and greatest Java.

I don't *care* what you use, but out of all the choices available, PHP would be *really* low on my list.

So how do you really feel? :wink:

Why code anything without a plan?

That's not what I said--I said just start. But the questions you're asking are too high-level to provide much specific help.

Okay, but I think my questions were pretty concise.

as well as general OOP questions.

Then ask them!

I have been...

It also stressed another key concept that I want to avoid... That classes have to be physical, tangible "nouns" and nothing else, and that all "verbs" are methods?!

Why would you want to avoid that?

Because not all good Classes need be concrete, physical things... In fact, I would say they also don't always have to be "nouns"...

I think "Registration" would make a good class because it is a thing.

Perhaps, but I wouldn't call it "Registration". It's not *a* registration.

Not sure where you live, but what is the thingy you have that the county or state gives you with your car? (*hint* A Registration)

*A* registration has things like the associated user, the date registered, what extras were registered for, etc. It's a registration service. It allows one to register.

Semantics, but that is fine.

The "Registration" class would have properties like... email, password, firstName, lastName, city, state, zip, country

How are those not part of the member/user class?

Who said they aren't?!

A "Member" would indeed have those same Properties, but...

1.) Would also likely have many more that transcend the "Registration" class
2.) Would not have the same Methods
3.) Is a concrete thing and completely separate from "Registration".

I imagine I would have a "Member" class and a "Registration" class. The latter creates a new "Member" record, but I'm not sure when/where/how the "Member" object is spawned.

It is my strong belief that "Registration" is too complex to just lump 1,000 lines of code together and class it a Method!

While I didn't digest everything in my "Head First: Design Patterns" book, it made sense how they broke out and abstracted things to a fairly granular level. That is the power of good OOP as far as I can see. (Eliminate "God classes", and break things down enough so they are flexible and re-usable.)

- isEmailUnique()
- isEmailValid()
- isPasswordValid()

Why would those be part of a registration? Are they not general-purpose methods that might be used elsewhere in the system? Or in a completely different system? These are not (necessarily) specific to registration.

Valid point.

Likewise, they are not specific to a "Member" so they shouldn't be lumped into that class.

I think you could reasonably leave them in the "Registration" class because they all pertain to registration and it is not my goal to abstract every last thing.

Maybe as a compromise, I could create a "UniquenessValidator" (terrible with "noun" sounding names so feel free to make sugegstions!!!) class that takes an input argument, validates its uniqueness, and spits out a "pass/fail" message?!

Then that "Uniquenessvalidator" could extend (??) the "Registration" class? :confused: (Help me out here...)

Would it be okay to write an HTML webpage that has my HTML Registration Form and when the User clicks "Register" send it to my "Registration" class?

Sure, with the caveat that I'm not convinced I like the registration class. But like I said--why not just start? Analysis paralysis. You're not at the point in OOP where over-thinking is going to help.

Yes, but I need to get a reasonable baring. This will be my *first-ever* class and bit of OOP code. (I don't think I've hit "analysis-paralysis" in just one thread...) :-P


Debbie

[Petar Thomas]

But why don't you just write that class what you invented, and try it?

[Petar Thomas]

Ha, ha, ha.... Until You type it, it's a design.

This part confuesed me:

I think the "Registration" class I described above would do that part. And it would "persist" as you say because one of the methods (e.g. activateAccount() ) would write the "activated" User into the back-end "Member" table in my database...

The "Registration" class would have properties like...

- email*
- password*
- firstName*
- lastName
- city
- state
- zip
- country
- acceptTerms*

*required

and it could have methods like...

- requiredFieldsComplete()
- isEmailUnique()
- isEmailValid()
- isPasswordValid()
- sendActivationEmail()
- activateAccount()

Of course that is just my first best guess having never written OOP before?!

Hey, maybe it would be good that You just study some examples from which You could "snarf up the principles"?

I think "Registration" would make a good class because it is a thing

But it is also a proces, so it is normal not to deny that.

In that book - and other things I've seen and read - it seems that the more *advanced* OO programmer understands you want to abstract out behaviors and processes as classes also. So, in the Head First book they took what most junior OOP'ers would label as "verbs" (and thus want to make "methods") and instead treated then as "things" which could be seen as "classes").

Becaouse objects send messages. (and recive)

I just finished reading the book "Head First: Design Patterns" - which by the way revolves around Java - and while it was a big chunk to bite off for a beginner, two patterns that I saw some use in for my website was the "Strategy Patterns" and the "State Pattern".

I think that might be a good idea.

One key thing I want to avoid that seems to be common in Procedural Programming is dumping tons of unrelated code into on giant bucket!!

Your "Registration" class is a bucket.

See, this is where I am hoping all of the gurus here can help me out?!

All the gurus. Man, You missed that occasion where there was 60 millions of them in one place.

For instance, I have a strategy for how to build the registration portion, but am uncertain about some design considerations as well as general OOP questions.

If You would just a litlle bit adopt iteretions....

I'm not following how PHP upsets my plans of creating a decent design BEFORE I dive into code.

So... You are a PHP guru?

Why do you make it sound so dirty? (Other than this *IS* a website for Java!!!)

Why do You make it sound so dirty?

Java has A LOT of implications (and costs) that PHP doesn't have.

: )

You do design, then implementation.

Is that a question?

Then that "Uniquenessvalidator" could extend (??) the "Registration" class? (Help me out here...)

The what? You want that "Uniquenessvalidator" IS-A "Registration"? (Why not? But if You are interestded in this, why don't You make ten different designs, or twenty?)

It is my strong belief that "Registration" is too complex to just lump 1,000 lines of code together and class it a Method!

It is not like that. It's more like... if .. one line of communication between more objects... is something similar to a function()..

and a "Registration" class. The latter creates a new "Member"

Ding-ding. Alarm. So that means that "the car registration" creates a Driver - or the drivers license?

A "Member" would indeed have those same Properties, but...

1.) Would also likely have many more that transcend the "Registration" class
2.) Would not have the same Methods
3.) Is a concrete thing and completely separate from "Registration".

Maybe it can not be ...aa... how to say?

Semantics, but that is fine.

Hit of the week.

Not sure where you live, but what is the thingy you have that the county or state gives you with your car?

: )

Because not all good Classes need be concrete, physical things... In fact, I would say they also don't always have to be "nouns"...

: ))

So how do you really feel?

: )

When I become rich and an OO expert, then I can re-engineer my site using the latest and greatest Java.

That is soo no OO...

Clearly you aren't a PHP fan.

All I know is that PHP makes much more financial and coding sense for someone in my shoes, and it clearly can produce enterprise-level websites.

Clearly you aren't a PHP guru.

David,

Geesh, you sounded angry.

That's really not true....

It is just your "analysis-paralyisis" what is speaking out of you that you are not aware of..

[David Newton]

Debbie Dawson wrote:Geesh, you sounded angry.

Your interpretation.

Okay, but I think my questions were pretty concise.

Concise != specific.

*A* registration has things like the associated user, the date registered, what extras were registered for, etc. It's a registration service. It allows one to register.

Semantics, but that is fine.

You're in for a tough haul if you think semantics in programming are unimportant.

A "Member" would indeed have those same Properties, but...

So you'd duplicate them?

It is my strong belief that "Registration" is too complex to just lump 1,000 lines of code together and class it a Method!

Who said anything about doing that?!

(I don't think I've hit "analysis-paralysis" in just one thread...)

There's already been more discussion about how you're going to do this than there will be code--you're talking about *maybe* a few hundred lines of PHP, and the HTML. Which is why I think you should start coding, see what works and what doesn't, get feedback on something concrete, and go from there.

Programming is an iterative process. And while *some* design goals are necessary up-front, when you're just starting out learning a new way of doing things and it's small enough that nothing's really at stake, why not just get started? You could have been done already and showing us something concrete to discuss.

Even for something this trivial, there are many, many ways it could be implemented, some good, some bad, some great, some horrible. Really--start. Pick a high-level way of doing it and go. Refactor mercilessly and eventually the design will emerge. Chip away at the stone until the form within is revealed.

[Debbie Dawson]

David Newton wrote:You're in for a tough haul if you think semantics in programming are unimportant.

Um, the context was...

Debbie: Because not all good Classes need be concrete, physical things... In fact, I would say they also don't always have to be "nouns"...
I think "Registration" would make a good class because it is a thing.

David: Perhaps, but I wouldn't call it "Registration". It's not *a* registration.

Debbie: Not sure where you live, but what is the thingy you have that the county or state gives you with your car? (*hint* A Registration)

David: *A* registration has things like the associated user, the date registered, what extras were registered for, etc. It's a registration service. It allows one to register.

Debbie: Semantics, but that is fine.

Debbie: A "Member" would indeed have those same Properties, but...

David: So you'd duplicate them?

Debbie: The "Registration" class is supposed to use the data for one thing and the "User" class is the embodiment of something different as well as using the data for different purposes (e.g. logging in, sending messages, etc.)


Debbie: I don't think I've hit "analysis-paralysis" in just one thread...

David: There's already been more discussion about how you're going to do this than there will be code--you're talking about *maybe* a few hundred lines of PHP, and the HTML. Which is why I think you should start coding, see what works and what doesn't, get feedback on something concrete, and go from there.

Programming is an iterative process. And while *some* design goals are necessary up-front, when you're just starting out learning a new way of doing things and it's small enough that nothing's really at stake, why not just get started? You could have been done already and showing us something concrete to discuss.

Debbie: Perhaps, but I figured it better to draw things out before building them. Don't you do an ERD before you start writing SQL?

David Newton wrote:Even for something this trivial, there are many, many ways it could be implemented, some good, some bad, some great, some horrible. Really--start. Pick a high-level way of doing it and go. Refactor mercilessly and eventually the design will emerge. Chip away at the stone until the form within is revealed.

Okay.



Debbie

[David Newton]

Debbie Dawson wrote:Um, the context was...

Here's a hint: don't "um" the people that are taking the time to read through multi-screen postings to try to help.

Don't you do an ERD before you start writing SQL?

A rough sketch, sure. Most problems, however, are impossible to define completely before beginning implementation, unless you're NASA. For a problem sized this tiny, I might spend thirty minutes on a rough design, and if I have to, refactor/rework as things come up.

[Tim Holloway]

Wow. Quote explosions!

Just to be pedantic, I'm not sure that I would call Java an Object-Oriented Programming Language. It is, in fact, an Object Based Programming language. Unlike C++, where you can be as procedural as you want, everything in Java codes into objects. You can code "procedural" code in Java. Just really, really abuse static properties and procedures. And, unfortunately, I've seen some people go to really heroic lengths to do so, although my own experience is that even things I think should be static usually come back and bite me.

PHP was originally designed as a procedural language. It has been struggling really hard to become object-oriented lately, and for good reason. OOD/OOP just scales better, in my experience, and it's certainly a lot easier to code for database independence. Some people have even tried to make JavaScript OOP, poor creatures. However, while you can transcend the constraints of a given language, as a general rule, you'll have a happier life if you are working with a platform that's thinking along the same lines you are. It's less work, and there's fewer "oopses"!

[David Newton]

JavaScript is OOP, just without classes: there are various ways of implementing OO.

[Petar Thomas]

Debbie Dawson,

Communication between objects is replacing usual functions, and it is broken in it's functional and replacable pieces. I would think how to make an abstraction of that application. I would make it like this: I would make a small application that would cover all the use cases, but instead of database, I would have a class which would mimic a databes, which I would replace later for the real class that works with the real database, also I would have a class that plays a role of the View part , such that it just prints text out on the standard output, and I would have a class that would recive input from standard input that would mimic a data recived from the web page form. Also I would have a class that would just play that it sends a mail, which would actually just print something out on the standard output. But other than that, I would make othervise completelly functional program, and when I would finish that, then I would replace acting classes with the real classes, and that should be absolutelly painless if the design was good. The data classes would serve just for information travelling back and forth.

I would use Model-View-Controller design pattern , and probablly I would have at least two layers of abstraction for each.

For example, one class would deal with all the "low level" calls to the database. Controler would talk only with one other Model class that would only delegate its tasks to the class that does the real work with the database.

It is important to decide in which classes/objects there will be happening a particular moment of making choices and desisions, checks, and algorithms.

Also, I would make a State Diagrams in UML, than I would think how the classes from the Controler part of the application would represent states, maybe even one class for each state, not really, but for me it's good for thinking.

Also, I would think how to save the state of the registration process to the database, and for example, when a user comes to the welcome screen after user recived mail and clicked on the link, how application would "remember" in which state it was before, and how to continue. And also how to transition from registration state to the normal functioning of the application. This is litlle bit tangible, becaouse database also serves as a kind of an istruction pointer to the steps of the process.

Bye...

[Petar Thomas]

Hi Debbie Dawsan

I don't know PHP. I looked a litle bit on PHP manual, and I found that it is similar like Java. I saw that there are some keywords that are the same in Java. I also saw that there are some differences. I don't know how much you know PHP, probablly good, and also I appologize for my jokes from previous posts. I know Java just enough to understand a litlle bit of PHP as well. I think that today I don't have time to learn PHP. But, I planned to make a small web application next week, for my practise, and there I should have a registration as well. I will start on that small application today. What I can do, I can post some code here, how I will solve the user registration, but in Java, or in written language.

[Petar Thomas]

Hi

I just have figured out one more thing. There is not only the difference between PHP and Java programming language, but there is difference between the application servers that use PHP or Java.

I can not make an application server to rearchitecture it self around my web application, but I have to redesign my design both: to fit to the application server, and to fit to the programming language.