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

[NC]

Carl wrote:

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.

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].
Structure and system _should_ be 'introduced' (at the minimum)
well before implementation .
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.

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.

.... 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
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?
Regarding your comment that there exists a design issue is
"ultimately rooted in marketing" has me perplexed.
Why? In your very next sentence, you agree with me:
The issue with design is implementing the feature set
determined by marketing,
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...

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,

Ah, we are not so different after all... :)
though I think it is far from a complete solution.

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]

NC,

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

[NC]

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

NC,

I'm not sure if you are thinking along the same lines as
Nikolas' proposal.
I am definitely thinking along the lines very different from
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?
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.
I'm not sure why you disagree with Nikolas' proposal.
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.
As you say, the buyer only cares about the feature set,
cost and responsive implementation. The last two are
products of the architecture.
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.
I think Nikolas' proposal is very valid because after the
sales pitch is successful the developers have to sit down
and type something.

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]

Hi NC,

I think Nikolas' proposal is very valid because after the
sales pitch is successful the developers have to sit down
and type something.

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.

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]

> So we can use whichever architecture we want, it

won't change much, since most of the functionality is already
implemented in the components.

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.

[petermichaux]

> - An MVC -architecture framework (e.g MOJAVI)

From a day of poking around on the web, it looks like Mojavi is well

liked by many people. Many sites say it is the best MVC php
architecture around.

It looks like the Mojavi project organization was a little chaotic
earlier this year but now you would use Mojavi 2 for php4 apps or Agavi
0.9 for php5 apps. (The Agavi project is a fork of Mojavi 3 and when
Agavi 1.0 is released it will be the first stable release of Mojavi 3.)
Mojavi 4 is just starting.

Now I want to try to figure out how Agavi 0.9 works. It seems very
sophisticated with many design patterns and will take a while to
understand. Already I can see that user sessons and database
connections are handled differently than what I've used. There are many
third party products I haven't used (Phing, Propel, Creole). It looks
like I might end up starting writing my application again. Ugg. I wish
this thread started about 3 months ago! But if Mojavi is as great as
people say then this might be the last time I start over.

-Peter

[petermichaux]

> I even fancied to switch over to jsp since i heard all those

stiltedness rumors about it's professionalism/stability etc.

What kept you with PHP?

I don't know anything about JSP or ASP. Are they just different
languages to do the same things as PHP? Is JSP a compiled language?

-Peter

[Nikolas Hagelstein]

hi,

NC: i fully agree with you.
May be my comments where a little mistakable.
Lets assume the following (idealised) situation:
- there is the opportunity to start from scratch
- there is no existing product
- there is no existing codebase
- there is no model of software architecture

Now in that situation i am looking for a "toolkit"
(meanig a combination of software architecture model and helpertools
e.q.pear )
to develop usable,stable,f lexibel software "on time and
within a budget." ;)

Cheers,
NIkolas

[Nikolas Hagelstein]

Carl,

consolidatio n aspect of it than in the 'guideline' aspect.

consolidation of knowledge and ideas is of course a thing we
are all interested in.
cheers,
nikolas

[Nikolas Hagelstein]

Hi,

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. i agree...
I thought a comparison like this must exist. unfortunatly i seems as if it does not :<
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. good idea
Maybe I could strip out a bunch of things from my application as
an example and then draw a diagram.

Yes that would be great ...

bye,
Nikolas