late 2005 'best practices' for object-oriented design?

PHP programming forum. Ask questions or help people concerning PHP code. Don't understand a function? Need help implementing a class? Don't understand a class? Here is where to ask. Remember to do your homework!

Moderator: General Moderators

Post Reply
MikeCoughlin
Forum Newbie
Posts: 3
Joined: Sun Nov 28, 2004 4:36 pm
Location: Westerly, RI
Contact:

late 2005 'best practices' for object-oriented design?

Post by MikeCoughlin »

After reading prior thread debates on PHP best practices, I was surprised at how few current threads and articles I found (most were 2 - 3 years old). I even checked Amazon for current books ... and found little to answer my basic, current 'best practices' questions.

Over the past year, I've read 6 - 8 PHP and e-commerce books and, starting fresh (from scratch), I'd like to learn "the right way" (whatever that might be). So, with the advent of object-oriented PHP 5 and growing XML acceptance, I thought it might be useful to start a current thread - to clarify and define current thinking on the following questions.
  • 1. Are frames, tables and cascading style sheets (CSS) considered old techniques, which should be replaced by XML, XSL and XSLT, using PHP and/or XSLT (or whatever) to generate the final HTML?

    2. Should XML, usually, only be used when a local data source (e.g. from an RDBMS) is unavailable ... or when there's a need to integrate data from multiple, incompatible data sources (usually NOT local)?

    3. For dynamic (data-driven) output, should one bring data from a local RDBMS to a .XML file (for a .XML data source file)? Then, use a separate .XSL file to consolidate (page or module) styling? And, then, of course, maintain all processing code in, yet, a third .PHP file?

    4. What is the currently proper way to render final (HTML) results? ... pass what to what? ... what Requires/Includes what?
Thanks - in advance - for whatever guidance and experience(s) ...
Last edited by MikeCoughlin on Sat Oct 08, 2005 12:31 pm, edited 2 times in total.
User avatar
Skara
Forum Regular
Posts: 703
Joined: Sat Mar 12, 2005 7:13 pm
Location: US

Post by Skara »

1: holy hell no. If so, 99.9% of the internet is waaay off base. ^^; ..ok, so that's true anyway. You know what I mean, though. :P I mean yeah, maybe they're getting old, but they're not exactly old fashioned yet.

4: I don't really see how this makes a difference myself, but that's just me. Maybe someone else has an opinion.

I'm like this. While it's a good idea to be as "neat" as possible about how you code etc, the internet is really still a free-for-all mess of garbage for the most part, and always will be as long as it's around (IMHO). Whatever works for you seems to be the internet motto, even if some people say 'this is how it's supposed to be.'
It's great to do things better, but it's not like everyone's going to listen to what's best. ;)
[/rant] ^^;
timvw
DevNet Master
Posts: 4897
Joined: Mon Jan 19, 2004 11:11 pm
Location: Leuven, Belgium

Re: late 2005 'best practices' for object-oriented design?

Post by timvw »

MikeCoughlin wrote:and found little to answer my basic, current 'best practices' questions.
That is because 'my best practices' are subjective and opinions may vary. Certainly in phpland.
I think that a multitude of posts are the proof that most accept that opinions vary and we all go our own way.
MikeCoughlin wrote:Are frames, tables and cascading style sheets (CSS) considered old techniques, which should be replaced by XML, XSL and XSLT?
If you offer them an XHTML page (which is valid XML) you could provide them XSL to generate whatever they want from it. On the other hand, you still allow "regular" users to surf to your site. So you get best of both worlds.
MikeCoughlin wrote: Should XML, usually, only be used when a local data source (e.g. from an RDBMS) is unavailable ... or when there's a need to integrate data from multiple, incompatible data sources (usually NOT local)?
XML is a format usable for data interchange (low level). It has nothing to do with a RDBMS (which manages data based on a logical concept).
MikeCoughlin wrote: For dynamic (data-driven) output, should one bring data from a local RDBMS to a .XML file (for a .XML data source file)? Then, use a separate .XSL file to consolidate (page or module) styling? And, then, of course, maintain all processing code in, yet, a third .PHP file?
This is (imho) the most common way: A PHP file that generates XML. Thus it also queries databases, reads from XML files, ... Usually this XML is XHTML and can be used by a surfer immediately.

If there is also a need to for a different XML format there are two options:
(1) Copy the PHP file and generate the new format of XML
(2) Write an XSL file that generates the new XML from the XHTML.

In J2EE land i notice that with JSF there is a tendancy to choose for(1) and through a strategy pattern choose the appropriate renderer.


As i already wrote in the beginning: your milage my vary ;)
MikeCoughlin
Forum Newbie
Posts: 3
Joined: Sun Nov 28, 2004 4:36 pm
Location: Westerly, RI
Contact:

PHP 99:1 procedural vs. object-oriented?

Post by MikeCoughlin »

Well, I must admit to being disappointed that these (deliberately) broad thread questions did not spur greater, healthy debate ... and insights. However, in view of what I've observed over the past few months, I guess I should not be surprised.

I've installed nearly a dozen of the larger CMS projects seeking good object-oriented architecture (examples). The only one that currently had some object-oriented architecture to evaluate was AngelineCMS, a three-year Finnish effort. However, even AngelineCMS has no UML or Sequence (process) diagrams or documentation, other than PHPdocumentor for some of its core functionality (and none for its modules).

In asking the questions, I hadn't expected to hear that the majority of PHP development embraced modular architecture, yet; but, I thought that there might be, at least, some agreement on best practices and patterns ... perhaps as a statement of direction.

While the pragmatism of "whatever works for you" is admirable, has it *really* "worked"? Are the majority of large-scale, open-sourced (CMS) projects (like osCommerce, ZenCart, Mambo, PHPnuke et al) dieing (at least the pre-forked versions) due to unmanageability of intertwined logic and presentation code ... and lack of modularity? ... or simply due to maturity and lagging interest?

It's now about two years since PHP5 beta releases ... and precious few web hosting services offer PHP5. What does this slow adoption rate of modular object-oriented architecture tell me? Is the majority of PHP development going to continue using procedural designs (with precious little documentation)?

Hmmmm .... 8O
User avatar
feyd
Neighborhood Spidermoddy
Posts: 31559
Joined: Mon Mar 29, 2004 3:24 pm
Location: Bothell, Washington, USA

Post by feyd »

Web hosts use whatever their clients demand most for the most part. Since most people aren't all that up on OOP or do not have the time to create OOP implementations. There's also an issue of needing to run flawlessly on older versions of PHP. For instance, phpBB supports back to like PHP3 which had zero OOP ability. The older a project is, the more likely it will stay in procedural for quite some time until they don't support legacy systems anymore. PHP projects seem to have far longer lifetimes than a lot of other systems due to their reusability.

I can understand why you won't find UML diagrams included with a huge majority of projects since your average user wants to run it, not understand how it operates internally. As for documentation, I know far far too many coders (in various languages) that don't comment their code well and can rarely be relied upon to write a single legible sentence grammatically correct, let alone spelt right.
Post Reply