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@yahoo.com]

Re: Professional Applications Devolpment

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]

Re: Professional Applications Devolpment

Hi Peter[color=blue]
> Controller: PHP takes URI requests. Validates form input. Produces the
>outgoing XML and passes it to the View layer once at the very end.[/color]
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 ;)
[color=blue]
>With all the SQL dialects this really possible when queries get complicated?[/color]
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.
[color=blue]
>Templating I've tried Smarty[/color]
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]

Re: Professional Applications Devolpment

petermichaux@ya hoo.com wrote:[color=blue]
> 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.
>[/color]

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.
[color=blue]
> 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.
>[/color]

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.
[color=blue]
> 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.[/color]

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.
[color=blue]
> 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.[/color]

Agreed!
[color=blue]
>
> 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
>[/color]

[NC]

Re: Professional Applications Devolpment

Nikolas Hagelstein wrote:[color=blue]
>
> i spend a lot of time on thinking and researching about how to
> make developing webapplications with php a more structured/systematic
> thing.[/color]

Why stop at development? Or, rather, why start in development?
Structure and system should be first introduced in sales and
implementation. ..
[color=blue]
> 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 ;)[/color]

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...
[color=blue]
> Wouldn't it be nice to have something like the
> "PHP professional webapplication development guidline" ?
> containing:
> - toolkits/frameworks
> - techniques
> - tutorials etc.[/color]

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

Cheers,
NC

[Carl]

Re: Professional Applications Devolpment

NC wrote:[color=blue]
> Nikolas Hagelstein wrote:
>[color=green]
>>i spend a lot of time on thinking and researching about how to
>>make developing webapplications with php a more structured/systematic
>>thing.[/color]
>
>
> Why stop at development? Or, rather, why start in development?
> Structure and system should be first introduced in sales and
> implementation. ..
>[/color]

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 .
[color=blue]
>[color=green]
>>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 ;)[/color]
>
>
> 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).[/color]

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!).
[color=blue]
>
> 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...
>
>[color=green]
>>Wouldn't it be nice to have something like the
>>"PHP professional webapplication development guidline" ?
>>containing:
>>- toolkits/frameworks
>>- techniques
>>- tutorials etc.[/color]
>
>
> I think it's called PEAR; it includes code repository (complete
> with dependency checks and defect tracking) and coding guidelines...
>[/color]

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'.
[color=blue]
> Cheers,
> NC
>[/color]

Cheers,
Carl.

[petermichaux@yahoo.com]

Re: Professional Applications Devolpment

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/

[color=blue]
> 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.[/color]

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.
[color=blue]
> Could you provide brief information on the excakt logic flow of your[/color]
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@yahoo.com]

Re: Professional Applications Devolpment

Carl,
[color=blue]
> 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.[/color]

How similar? If it is eCommerce then perhaps we could work together?
What do you mean by consolidation vs. guideline?
[color=blue]
>
> 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.[/color]

Say what? What is i18n?
[color=blue]
> 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.[/color]

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@yahoo.com]

Re: Professional Applications Devolpment

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]

Re: Professional Applications Devolpment

petermichaux@ya hoo.com wrote:[color=blue]
> Carl,
>
>[color=green]
>>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.[/color]
>
>
> How similar? If it is eCommerce then perhaps we could work together?
> What do you mean by consolidation vs. guideline?
>[/color]

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.
[color=blue]
>[color=green]
>>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.[/color]
>
>
> Say what? What is i18n?
>[/color]

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.
[color=blue]
>[color=green]
>>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.[/color]
>
>
> 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
>[/color]

[NC]

Re: Professional Applications Devolpment

Carl wrote:[color=blue]
> NC wrote:[color=green]
> > Nikolas Hagelstein wrote:
> >[color=darkred]
> > > i spend a lot of time on thinking and researching about
> > > how to make developing webapplications with php a more
> > > structured/systematic thing.[/color]
> >
> > Why stop at development? Or, rather, why start in development?
> > Structure and system should be first introduced in sales and
> > implementation. ..[/color]
>
> 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.[/color]

I guess I wasn't clear... When I say "developmen t", "sales",
or "implementation ", I mean not development/deployment stages,
but groups of people within an organization who perform these
functions.

Most software organizations out there already have at least
one product, so whatever happens to development from now on is
a long-term issue of little immediate importance. The shorter
term issue, with much more urgency to it, is how to maximize
return on investment that has already been made in developing
the product. This is why I think that structure and system
should be first introduced in sales [team] and implementation
[team], because in great many cases it is already too late to
introduce them in the development [team].
[color=blue]
> Structure and system _should_ be 'introduced' (at the minimum)
> well before implementation .[/color]

In a perfect world, yes. In the real world, it is often too late
for that; the product has already been released or is getting
close to it. So quite often your best bet is to introduce best
practices on the "business side" (sales team, implementation team,
support team, etc.) first and then implant them into development
of the next major release or perhaps even the next product.
[color=blue][color=green]
> > 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).[/color]
>
> Again, you lost me.[/color]
....[color=blue]
> 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[/color]

Well, it appears that my definition of design also differs from
yours. :) Seriously, though, we seem to be concerned about
different aspects of design. To you, design appears to be mostly
about software architecture; I tend to focus on usability and
relevance to the end user's needs. Obviously, each approach has
its drawbacks. If you follow my suggestions to the extreme, you
may find yourself trying to address a need that cannot be addressed
with present-day technology (or perhaps, should be addressed by
means other than technology, such as training or organizational
changes). If I follow your suggestions to the extreme, I may end
up with a beautifully designed, but totally irrelevant to the
user's needs (and thus unsellable), piece of software... The
question is, which of the two diseases (pampering the user or
ignoring him) tends to strike more often?
[color=blue]
> Regarding your comment that there exists a design issue is
> "ultimately rooted in marketing" has me perplexed.[/color]

Why? In your very next sentence, you agree with me:
[color=blue]
> The issue with design is implementing the feature set
> determined by marketing,[/color]

This is exactly what I meant. Marketing suggests WHAT
should be implemented, designers decide HOW it should be
implemented. Somewhere in-between, there probably should
be a manager type who decides WHETHER and WHEN (given time
and cost considerations) a particular feature should be
implemented...
[color=blue][color=green]
> > I think it's called PEAR; it includes code repository
> > (complete with dependency checks and defect tracking)
> > and coding guidelines...[/color]
>
> PEAR is indeed one possible answer to the OP's question,[/color]

Ah, we are not so different after all... :)
[color=blue]
> though I think it is far from a complete solution.[/color]

But then, is any solution ever complete? :) Again, what
I like about PEAR is that it (1) offers coding guidelines,
(2) stores cataloged and (usually) documented code, and
(3) has a defect tracking system. Thus, I believe that
PEAR can be viewed as a working prototype for a company-
wide code management system...

Cheers,
NC

[tedhenry10@hotmail.com]

Re: Professional Applications Devolpment

NC,

Uhhhhhh. Your throwing arm must be pretty strong from playing in left
field for so many years . . . I am totally perplexed.

[NC]

Re: Professional Applications Devolpment

petermichaux@ya hoo.com wrote:[color=blue]
> NC,
>
> I'm not sure if you are thinking along the same lines as
> Nikolas' proposal.[/color]

I am definitely thinking along the lines very different from
Nikolas' proposal. :)
[color=blue]
> 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?[/color]

Exactly. So we can use whichever architecture we want, it
won't change much, since most of the functionality is already
implemented in the components.
[color=blue]
> I'm not sure why you disagree with Nikolas' proposal.[/color]

Because in my opinion it confuses goals with means. The
goal as I see it is to deliver usable software on time and
within a budget. Reusing code can help with time and
budget. So the company's code base must be well-documented
and be accessible through a searchable central repository.
This, in my opinion, is the important part. Whether this
code base adheres to MVC or any other development pattern
is (again, in my opinion) unimportant.
[color=blue]
> As you say, the buyer only cares about the feature set,
> cost and responsive implementation. The last two are
> products of the architecture.[/color]

Not really...

Cost is determined primarily by how much time developers
spent on the project, how well they were paid for that
time, and how expensive the third-party components were.
If the code base is centralized, well-documented, and
searchable, developers can save time by reusing code,
regardless of code's and developers' adherence to any
particular development paradigm. If, conversely, the code
base is dispersed, poorly documented, and not searchable,
developers would rather rewrite than reuse...

Responsiveness of implementation, in turn, is determined
by the quality of documentation and the quality of the
implementation staff training.
[color=blue]
> I think Nikolas' proposal is very valid because after the
> sales pitch is successful the developers have to sit down
> and type something.[/color]

You are obviously thinking in terms of custom development.
But custom development is not the only business model in
software. More often, you have a pre-packaged product that
requires extensive integration with other systems the client
already has in place. So you can only start pitching AFTER
you have the product. And the success of your sales pitch
in this situation is determined by how well you understand
the customer's legacy systems and how well your product can
integrate with those systems. The real work in this case
begins after closing the sale and has nothing to do with
development; an implementaion team is dispatched to the
customer's site to do installation, configuration, database
hookups, data conversions, etc. The bulk of revenue in this
case comes from implementation services, not from licensing;
development is just a fixed cost that needs to be spread over
as many implementations as possible...

Cheers,
NC

[petermichaux@yahoo.com]

Re: Professional Applications Devolpment

Hi NC,
[color=blue][color=green]
> > I think Nikolas' proposal is very valid because after the
> > sales pitch is successful the developers have to sit down
> > and type something.[/color]
>
> You are obviously thinking in terms of custom development.
> But custom development is not the only business model in
> software. More often, you have a pre-packaged product that
> requires extensive integration with other systems the client
> already has in place.[/color]

OK, now I better understand what you are writing about.

To you it is a pre-packaged product. To the developers of this product
it is a custom product that has an architecture. Every application is
custom according to someone. I think that is what this thread is about.
Developing a new product with an architecture that is easy to deal with
when installing/integrating/modifying.

[petermichaux@yahoo.com]

Re: Professional Applications Devolpment

> So we can use whichever architecture we want, it[color=blue]
> won't change much, since most of the functionality is already
> implemented in the components.[/color]

But we still have to decide which architecture we want to use. There
must be pros and cons to different architectures. For example hacking
together an application with html/css/php/sql/javascript/xml/xsl mixed
together in every file would be a poor architecture for a big
application. Probably MVC would be better.