Professional Applications Devolpment

[Nikolas Hagelstein]

Hi,

First of all:
i spend a lot of time on thinking and researching about how to
make developing webapplications with php a more structured/systematic
thing. I even fancied to switch over to jsp since i heard all those
stiltedness rumors about it's professionalism/stability etc.

Anyway my current attitude is that fullfilling the following needs
would make application depvelopment via PHP a really
fast/professional/structured thing:

- An MVC -architecture framework (e.g MOJAVI)
- template parser (for View part)
- severall helper toolkits/frameworks
(DB abstraction layer/Form validation etc.)
- disciplined/skilled Devloper ;)

These are of course not really new findings and
as we all know there are a lot of different implementions/combinations
of the above named out on the web.

So what i want to know is:
- what is your prefered software/framework to fullfill the above
needs.?
- For what purposal do you use them ?
- what are the advantages/disadvantages ?

Wouldn't it be nice to have something like the
"PHP professional webapplication development guidline" ?
containing:
- toolkits/frameworks
- techniques
- tutorials etc.

I think this is really worth thinking and talking about.

Cheers,
NIkolas

[petermichaux]

I am going to be very interested in this thread!

I have been trying to develop a good application framework for a new
web application: a sourceforge project called OSCommerce-XSL which is
intended to be a professional version of osCommerce. The goal is to
use PHP to query an SQL database. The PHP produces XML for XSL to
transform into XHTML. This transformation occurs server side. Optional
Javascript validation of form inputs. Mandatory PHP validation of form
inputs.

So far I have divided the application into the following tiers
View: XSL layer to produce XHTML from XML
Controller: PHP takes URI requests. Validates form input. Produces the
outgoing XML and passes it to the View layer once at the very end.
Model-business layer: a purely PHP layer. No XML related function. No
SQL or PEAR.
Model-data layer: This layer exists to separate the SQL from the rest
of the application

About DB abstraction. With all the SQL dialects this really possible
when queries get complicated? I use PEAR DB but if someone wanted to
change from MySQL they might have to edit many of my SQL statements for
the new dialect.

Form Validation. Which tool kits are available and good? Currently I am
using a PHP class pattern I designed for each form that can validate
input and produce output. I am reasonably happy with what I have
designed but I'm sure it could be better.

Templating. I've tried Smarty but the XML/XSL combination seems much
more powerful. With XML/XSL I like that the application flow is through
the PHP control layer with only conversion using the View layer at the
very end when serving the page to the client. With Smarty the
application flows through the various template files and calls the PHP
as needed.

I haven't seen the MOJAVI project before and will spend some time on
their website.

If you are looking for a sample application to discuss I would gladly
volunteer mine since I am at the right stage of development to do this
kind of discussion.

Peter

[Nikolas Hagelstein]

Hi Peter

Controller: PHP takes URI requests. Validates form input. Produces the
outgoing XML and passes it to the View layer once at the very end. Is your controller approach capable of managing things like "actions
chains" etc?

Could you provide brief information on the excakt logic flow of your
approach?
Something like a diagram would be nice ;)
With all the SQL dialects this really possible when queries get complicated? I agree ....100% abstraction would affect flexibility...s o the way is
to find a
compromise between abstraction/flexibility...s ame to the form thing.
Templating I've tried Smarty

Me too ...but i don't like it for serveral reasons..

Just to clarify things i do not indend to point out "THE ULTIMATIVE"
frameworkt/templateparser - whatever combination.
But if it exists i would be glad to hear about it ;)

The goal is to give an overview what combinations are passable and what
are their
main/optimal purposals.

e.g.:
use mojavi + smarty...becaus e...
if you got much DB stuff i did good experience on
STUDS + PEAR:DB because....but beware because it lacks of ....

If we could carry together a few scenarios that would be a great
guideline
for those who are looking for an entry to a more professional way of
php development.

Regards,
Nikolas

[Carl]

pe**********@ya hoo.com wrote:

I am going to be very interested in this thread!

I have been trying to develop a good application framework for a new
web application: a sourceforge project called OSCommerce-XSL which is
intended to be a professional version of osCommerce. The goal is to
use PHP to query an SQL database. The PHP produces XML for XSL to
transform into XHTML. This transformation occurs server side. Optional
Javascript validation of form inputs. Mandatory PHP validation of form
inputs.

Having recently started the planning stage of a project very similar to
yours, I am also quite interested in this subject. More in the
consolidation aspect of it than in the 'guideline' aspect.
So far I have divided the application into the following tiers
View: XSL layer to produce XHTML from XML
Controller: PHP takes URI requests. Validates form input. Produces the
outgoing XML and passes it to the View layer once at the very end.
Model-business layer: a purely PHP layer. No XML related function. No
SQL or PEAR.
Model-data layer: This layer exists to separate the SQL from the rest
of the application

About DB abstraction. With all the SQL dialects this really possible
when queries get complicated? I use PEAR DB but if someone wanted to
change from MySQL they might have to edit many of my SQL statements for
the new dialect.

IMO, the database abstraction _code_ should be handled in a fashion
similar to i18n, meaning that just as you would present text to a client
depending on the currently defined language context, the text(code)
presented to the DB should depend on the selected database context.
Form Validation. Which tool kits are available and good? Currently I am
using a PHP class pattern I designed for each form that can validate
input and produce output. I am reasonably happy with what I have
designed but I'm sure it could be better.
What exactly do you mean by a 'PHP class pattern'? Are you using one
'class' to handle all of your forms, or applying a pattern to each of
your forms.
Templating. I've tried Smarty but the XML/XSL combination seems much
more powerful. With XML/XSL I like that the application flow is through
the PHP control layer with only conversion using the View layer at the
very end when serving the page to the client. With Smarty the
application flows through the various template files and calls the PHP
as needed.
Agreed!

I haven't seen the MOJAVI project before and will spend some time on
their website.

If you are looking for a sample application to discuss I would gladly
volunteer mine since I am at the right stage of development to do this
kind of discussion.

Peter

[NC]

Nikolas Hagelstein wrote:

i spend a lot of time on thinking and researching about how to
make developing webapplications with php a more structured/systematic
thing.
Why stop at development? Or, rather, why start in development?
Structure and system should be first introduced in sales and
implementation. ..
Anyway my current attitude is that fullfilling the following
needs would make application depvelopment via PHP a really
fast/professional/structured thing:

- An MVC -architecture framework (e.g MOJAVI)
- template parser (for View part)
- severall helper toolkits/frameworks
(DB abstraction layer/Form validation etc.)
- disciplined/skilled Devloper ;)
I respectfully disgree. No matter how professional your
development is, your success will NOT be determined by the
quality of development. Whether or not your product uses MVC
(or another fashionable development technique) is of no
consequence to the buyer. The buyer wants to see the relevant
feature set (which is a design issue, ultimately rooted in
marketing), reasonable cost of ownership (which a purely
marketing issue), knowledgeable sales people and responsive
implementation people (which are human resources issues).

On the development side, what you really need is a combination
of coding AND DOCUMENTING guidelines with a code repository and
a defect tracking system. Over time, this will ensure you have
a large base of potentially reusable and reasonably bug-free code.
Whether you want to introduce guidelines that require the use of
MVC or, say, forbid the use of OOP altogether, is a matter of
secondary importance...
Wouldn't it be nice to have something like the
"PHP professional webapplication development guidline" ?
containing:
- toolkits/frameworks
- techniques
- tutorials etc.

I think it's called PEAR; it includes code repository (complete
with dependency checks and defect tracking) and coding guidelines...

Cheers,
NC

[Carl]

NC wrote:

Nikolas Hagelstein wrote:

i spend a lot of time on thinking and researching about how to
make developing webapplications with php a more structured/systematic
thing.

Why stop at development? Or, rather, why start in development?
Structure and system should be first introduced in sales and
implementation. ..

In not really sure that I understand what you are trying to argue here,
but I would argue that 'Sales' is not necessarily a factor that needs to
be considered in the context of this discussion, and implementation is
only one part of the development process. Structure and system _should_
be 'introduced' (at the minimum) well before implementation .

Anyway my current attitude is that fullfilling the following
needs would make application depvelopment via PHP a really
fast/professional/structured thing:

- An MVC -architecture framework (e.g MOJAVI)
- template parser (for View part)
- severall helper toolkits/frameworks
(DB abstraction layer/Form validation etc.)
- disciplined/skilled Devloper ;)

I respectfully disgree. No matter how professional your
development is, your success will NOT be determined by the
quality of development. Whether or not your product uses MVC
(or another fashionable development technique) is of no
consequence to the buyer. The buyer wants to see the relevant
feature set (which is a design issue, ultimately rooted in
marketing), reasonable cost of ownership (which a purely
marketing issue), knowledgeable sales people and responsive
implementation people (which are human resources issues).

Again, you lost me. My first response here would be to see my comment
above on 'Sales' and apply it to every mention of 'buyer' in this
paragraph.
Although you may /sometimes/ be correct in that 'success will NOT be
determined by the quality of development', you definition of success and
mine clearly differ. Proper design markedly increases _your_ ability to
work with, repair, modify and reuse code in the future, and these
abilities are propagated to the user, or 'buyer' in your terms. If the
end user happens to be a developer, or would like to have the software
modified, these attributes are invaluable, and often overlooked and
underestimated in marketing. I would say having these options makes a
project/product more successful.

Regarding your comment that there exists a design issue is "ultimately
rooted in marketing" has me perplexed. The issue with design is
implementing the feature set determined by marketing, and how this
implementation is done should be under the complete control of the
designers (i.e. NOT MARKETING!).

On the development side, what you really need is a combination
of coding AND DOCUMENTING guidelines with a code repository and
a defect tracking system. Over time, this will ensure you have
a large base of potentially reusable and reasonably bug-free code.
Whether you want to introduce guidelines that require the use of
MVC or, say, forbid the use of OOP altogether, is a matter of
secondary importance...

Wouldn't it be nice to have something like the
"PHP professional webapplication development guidline" ?
containing:
- toolkits/frameworks
- techniques
- tutorials etc.

I think it's called PEAR; it includes code repository (complete
with dependency checks and defect tracking) and coding guidelines...

PEAR is indeed one possible answer to the OP's question, though I think
it is far from a complete solution. On an even more abstract level, we
could also say that the solution is PHP itself, or how about 'some
program written in some language that solves the problem'.
Cheers,
NC

Cheers,
Carl.

[petermichaux]

Nikolas,

First, I'm not a professional web app developer. I'm relatively new to
php. But I am very interested in your proposed discussion.

Since database abstraction still seems to be a problem perhaps a good
solution is to use PEAR DB and then isolate all of the SQL so that it
is easy to work on. The phrasebook design pattern does this and seems
very elegant. Unfortunately I can't get the phrasebook example to work

https://sourceforge.net/projects/phpphrasebook/

If we could carry together a few scenarios that would be a great guideline for those who are looking for an entry to a more professional way of php development.
I thought a comparison like this must exist. Idealists arguing about
the pros and cons of various architectures. I searched for a book on
php application architecture but found nothing other than isolated
application examples. I got excited when I found the magazine
php|Architect but I didn't see any articles covering the entire
application architecture.
Could you provide brief information on the excakt logic flow of your

approach? Something like a diagram would be nice ;)

Maybe the best thing for us to do would be to have a small sample
application that we could study and play with and set up different
ways. Maybe I could strip out a bunch of things from my application as
an example and then draw a diagram.

Peter

[petermichaux]

Carl,

Having recently started the planning stage of a project very similar to
yours, I am also quite interested in this subject. More in the
consolidation aspect of it than in the 'guideline' aspect.
How similar? If it is eCommerce then perhaps we could work together?
What do you mean by consolidation vs. guideline?

IMO, the database abstraction _code_ should be handled in a fashion
similar to i18n, meaning that just as you would present text to a client
depending on the currently defined language context, the text(code)
presented to the DB should depend on the selected database context.
Say what? What is i18n?
What exactly do you mean by a 'PHP class pattern'? Are you using one
'class' to handle all of your forms, or applying a pattern to each of
your forms.

I am applying a pattern to each form. I think it is neat, tidy and
flexible. It is easy to develop seperately the parts of a new form from
a blank form template. The form handling is about the only part of my
application that I am really happy with. Perhaps if we decide to have a
sample application I can explain more after strip the bells and
whistles from my code.

-Peter

[petermichaux]

NC,

I'm not sure if you are thinking along the same lines as Nikolas'
proposal. He is talking about the overall application architecture.
Isn't PEAR only a set of components that can be connected by inserting
them into an application archeticture?

I'm not sure why you disagree with Nikolas' proposal. As you say, the
buyer only cares about the feature set, cost and responsive
implementation. The last two are products of the architecture. I think
Nikolas' proposal is very valid because after the sales pitch is
successful the developers have to sit down and type something. What
they type is determined by the architecture upon which they have
agreed. This discussion is about agreeing on the architechture.

-Peter

[Carl]

pe**********@ya hoo.com wrote:

Carl,

Having recently started the planning stage of a project very similar to
yours, I am also quite interested in this subject. More in the
consolidati on aspect of it than in the 'guideline' aspect.

How similar? If it is eCommerce then perhaps we could work together?
What do you mean by consolidation vs. guideline?

Actually, the final goal of my project is in fact an eCommerce
application. Ideally the minimalist 'framework' will be used to create
complete systems, including but not limited to eCommerce. I am still in
the pre-development planning stage, so I don't have any organized
examples to post at this time. The end result should facilitate creating
websites with management for modules that will provide the actual
functionality of the site.

IMO, the database abstraction _code_ should be handled in a fashion
similar to i18n, meaning that just as you would present text to a client
depending on the currently defined language context, the text(code)
presented to the DB should depend on the selected database context.

Say what? What is i18n?

i18n (internationali zation) is used to be able to provide formats based
on the location of the end user. Language translations, number
formating, etc. My suggestion was that similar methods should be used,
seeing that different databases speak different languages. The breadth
of i18n is clearly not required though, and usually a Dictionary or
Translator class will suffice, simply returning the correct words based
on the current database context.

,Carl.

What exactly do you mean by a 'PHP class pattern'? Are you using one
'class' to handle all of your forms, or applying a pattern to each of
your forms.

I am applying a pattern to each form. I think it is neat, tidy and
flexible. It is easy to develop seperately the parts of a new form from
a blank form template. The form handling is about the only part of my
application that I am really happy with. Perhaps if we decide to have a
sample application I can explain more after strip the bells and
whistles from my code.

-Peter