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

[Nikolas Hagelstein]

Peter,

[MOJAVI]
i tried at least 5 different MVC frameworks and most of them suffer
from the
attempt to port "JSPs struts" to PHP.
Mojavi does not and further more it's small an lightweight even if it's
project homepage
seems to be a little chaotic ;)

I wish this thread started about 3 months ago!

;)

bye,
Nikolas

[Nikolas Hagelstein]

>What kept you with PHP?
hmmm difficult to answer...
lets say: a mixture of laziness,habit and the will to find a solution
,)

I don't know anything about JSP or ASP

nor do i ....definitely not enought to answer this question completly
cheers,
Nikolas

[R. Rajesh Jeba Anbiah]

Nikolas Hagelstein wrote:
<snip>

Anyway my current attitude is that fullfilling the following needs
would make application depvelopment via PHP a really
fast/professional/structured thing:
Kudos, at last some healthy interesting discussion in c.l.php:-)
Everyone start researching will end up in yet another framework (tm);-)
- An MVC -architecture framework (e.g MOJAVI)
- template parser (for View part)
- severall helper toolkits/frameworks
(DB abstraction layer/Form validation etc.)
In my perspective, templates and MVC is making the project high
complex. Even, if you just want to echo some texts, you have to do this
and that..., IMHO. Another thing to consider the fact that PHP is
interpreted language; and I have seen many hard coded DB
abstractions--and finally end up with phpBB like simple abstraction
that doesn't affect much of performance. Also,
<news:11******* *************** @g44g2000cwa.go oglegroups.com> (
http://groups.google.com/group/comp....cb875afffebbe2 )

<snip> So what i want to know is:
- what is your prefered software/framework to fullfill the above
needs.?
My requirement was different and got end up with own framework,
coding standards (phpdoc) and as I said since PHP is interpreted,
abstractions are minimized; and as of now many codes are been automated
in another layer (with own codegen) so that the effective (PHP) code is
simple and fast.

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

This is very harder. There are lots and lots of frameworks and
guidelines; all because of the dissatisfaction over other.

--
<?php echo 'Just another PHP saint'; ?>
Email: rrjanbiah-at-Y!com Blog: http://rajeshanbiah.blogspot.com/

[Carl]

NC,

NC wrote:

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.
If the development stage is the responsibility of the development group,
and the same applies to the sales and implementation stages/groups,
then, for the sake of this discussion the terms are interchangeable and
your clarification is not necessary. My problem is not with your exact
definition of 'sales', but rather why you think its relevant to this
discussion at all.

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].
Again, your totally off topic here. Please read the OP. This discussion
is about "developing webapplications ", your observations on companies
with existing software are irrelevant, and your observations on ROI even
more so.

Additionally, i would like to ask why you would even have a sales team
if you have not developed (i.e. Development group/stage) a product?
Unless of course you are still thinking in terms of a company with an
existing product, which again, is not relevant to this discussion. You
may also want to consider that if you already have a product, the
development stage has clearly finished (you have a product, right?).

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.

OK, another misunderstandin g. Generally, application development
includes the initial development, and ongoing application maintenance.
You are talking about maintenance, not development (at least not in the
context of this discussion).
Your 'existing product' is a red herring, stop confusing the issue.

I respectfully disgree. No matter how professional your
developmen t 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
consequenc e 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
implementati on 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.

Wrong. You assume that my concern is "mostly about software
architecture". Software architecture means nothing when it is not used
to address a problem; or a requirement of the specifications if that
suites you better. We are trying to discuss software design, patterns,
etc. that can be used to solve common problems, nothing more.
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).
Yeah, tell the project architect, designer, marketing, or the end user
for that matter that you think that their request would be better
handled by better "training or organizational changes", and you will not
implement it. HA! I am begining to think you haven't tried this in the
RealWorld(tm) yet. Either that or your requirements were terribly out of
touch with reality. But again, this has nothing to do with the topic of
the OP.

HA, I'm still laughing...trai ning... ;)
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?
Another assumption. The need for compromise between good design and
usability is your own invention.
There is no reason you cannot use a well thought out design pattern,
reusable libraries, application frameworks, etc. to implement usability.

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 we are arguing apples an PEAR's here :)
Do not confuse the 'design' of the application (i.e. feature x, feature
y) with the design of the system (i.e. written in php, using db(x) for
storage, etc), aka the architecture, which is what this topic is about;
Implementing the feature x design (requirement) effectively through
application design (application architecture).

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

Cheer,
Carl.

[Dikkie Dik]

Nikolas Hagelstein wrote:
....

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 ?
Well, I wouldn't dream of working without a unit test framework. I have
written my own ( http://www.w-p.dds.nl/tinyunit.htm ), but there are
enough existing frameworks if you want.
As for database layers, I am writing my own as well. Started out as
individual classes, it is maturing to something that combines some nice
performance enhancements and data checking on the real database part and
some common inherited functionality on the lazy tablewrappers part.
I am building mostly multi-language sites now, and I have some standard
controls that work with my "feeding" of the language-dependent strings.

As I want my classes as simple as possible AND I want some specific
features, I don't work with any off-the-shelf code (yet).
Wouldn't it be nice to have something like the
"PHP professional webapplication development guidline" ?
A rough guideline, maybe. A lot depends on your personal taste. When I
visited the PEAR website and saw their coding standard, I decided to
stay away from it as far as possible.
containing:
- toolkits/frameworks
- techniques
- tutorials etc.
A bit outdated, but still valid: the lazy table wrappers are described
on http://www.w-p.dds.nl/article/wtrframe.htm
I think this is really worth thinking and talking about.

Cheers,
NIkolas

A nice tool I would want is a debugger. I downloaded a few of them, but
none of them work. Does anybody know a working one?

Best regards

[Colin McKinnon]

Dikkie Dik wrote:

Nikolas Hagelstein wrote:
...

- 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 ;)

Well, I wouldn't dream of working without a unit test framework. I have
written my own ( http://www.w-p.dds.nl/tinyunit.htm ), but there are
enough existing frameworks if you want.
As for database layers, I am writing my own as well. Started out as
individual classes, it is maturing to something that combines some nice
performance enhancements and data checking on the real database part and
some common inherited functionality on the lazy tablewrappers part.
I am building mostly multi-language sites now, and I have some standard
controls that work with my "feeding" of the language-dependent strings.

Got to agree there. I would further and say the most fundamental thing thing
is a coding standard. A difficult thing to draw up until you're quite
familiar with a language - but the PEAR one is a good baseline.

A PHPDoc parser is essential too (I like PHPDocumentor).

Another useful PHP CASE is continious integration.

Regards frameworks - it's hard to write OO Webforms without falling into the
MVC pattern. When I reviewed what was available about a year ago and I
couldn't find anything which lent itself the task I was working on (low
volume, ERP type applications). So I wrote my own too!
(http://pfp-studio.sourceforge.net) although it approaches the problem
quite differently from a framework.

I must admit that Blue Shoes and Seagull both came quite close to what I
wanted.

Having written PfP Studio, I then found out that none of the template
systems I looked at would accomodate it easily (I wanted something a web
designer with NO coding experience could use) so I had to write one of
those too. Maybe this is why there are now so many template systems and
frameworks out there!

If you just want a slashdot type news site then your spoilt for choice among
the turn-key solutions already written! Sometimes customizing one of these
may be a better approach (I've had limited success with Mambo and
PostNuke).

Some components of a system go beyond what is available all but the most
complex of frameworks and may be better implemented elsewhere e.g.
authentication and navigation.

Db abstraction? I'd find it hard to justify anything more than ODBC or DBX.
And I find PEAR a bit rich for my diet.

A nice tool I would want is a debugger. I downloaded a few of them, but
none of them work. Does anybody know a working one?

I was quite impressed with Zend - although I don't really like the
post-Microsoft type IDEs (which I guess really started with Borland). These
days I prefer to embed instrumentation within my code which is handy when
its in production.

C.

[petermichaux]

Nikolas,

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 ...

I'm going to hold of on doing that until I read more about Agavi. I am
especially interested in the database connection methods, form
validation and controller.

[Nikolas Hagelstein]

Hi,

I'm going to hold of on doing that until I read more about Agavi. I am
especially interested in the database connection methods, form
validation and controller.

Ok, please keep me informed if you gather any new findings....
bye,
Nikolas

[Nikolas Hagelstein]

Hi

written my own ( http://www.w-p.dds.nl/tinyunit.htm ), but there are
enough existing frameworks if you want. Thank you i will have a look at it.
Yes right there are a lot of exsisting frameworks this is exactly why i
started
this thread ;)
As for database layers, I am writing my own as well. Started out as
individual classes, it is maturing to something that combines some nice
performance enhancements and data checking on the real database part and
some common inherited functionality on the lazy tablewrappers part.
I am building mostly multi-language sites now, and I have some standard
controls that work with my "feeding" of the language-dependent strings.

sounds interessting could you provide a more deeper view to it?
bye,
NIKOLAS

[Dikkie Dik]

Nikolas Hagelstein wrote:

As for database layers, I am writing my own as well. Started out as
individual classes, it is maturing to something that combines some nice
performanc e enhancements and data checking on the real database part and
some common inherited functionality on the lazy tablewrappers part.
I am building mostly multi-language sites now, and I have some standard
controls that work with my "feeding" of the language-dependent strings.

sounds interessting could you provide a more deeper view to it?
bye,
NIKOLAS

Most tables are represented by a lazy collection class. My "latest
trick" is to equip the collections with a ScheduleForLoad method. This
is used for objects I want to retrieve, but not right away. Whenever a
database action is necessary, the already scheduled objects are loaded
as well with a single SQL command. This is usually a HANDLER statement.
The table wrappers started out as single classes, but I am refactoring
them now to have a common superclass with abstract methods for object
creation. Yes, I'm using PHP5.
The table wrappers are held together by a backend object, that acts as
the root of the data layer. The backend object knows all table wrappers.
When I am finished generating a page, I only have to call the Dispose
method of the backend, as it propagates it throughout the whole backend
structure.
The frontend structure (the user interface) consists still of loose
classes and a controls collection, but it will be structure in the same
manner: a frontend object will hold the controls collection and can
generate new controls.
I am currenty dividing the controls in standard HTML controls and
"phrase-aware" controls that often extend from the HTML controls.
The multilanguage strings are "phrases": a sort of thoughts that are not
yet expressed in a language. They are in a table with only an ID field.
There is also a languages table, and a translations table with a
translation for each phrase and language.

Best regards