What is/is not considered to be good OO programming

[Tony Marston]

Re: What is/is not considered to be good OO programming

Matty <matt+nntp@askm enoquestions.co .uk> wrote in message news:<cGPAb.184 72$lm1.155203@w ards.force9.net >...[color=blue]
> Matty wrote:
>
>[color=green]
> > Wow, it's come back to life again!
> >
> > Asbestos manufacturers everywhere must be looking forwards
> > to this one!
> >
> > ;p
> >
> > Matt[/color]
>
> FWIW, I still think it's better to have 12 different instances,
> rather than 12 different classes <duck />...[/color]

According to the principles of OO you are not supposed to instantiate
an abstract class then feed it the implementation details, you are
supposed to put the implementation details in a subclass. If I were to
use the keyword 'abstract' in the class definition (as PHP 5 will
allow) you will find it impossible to instantiate an abstract class
directly, in which case you MUST use a subclass.

So, if I have 12 database tables each with a totally different set of
implementation details, then (according to the above-mentioned
principle) I must create 12 subclasses. I am right and you are wrong,
so score 1-0 to me :)
[color=blue]
> Not read it all yet,
> just a quick search! I'll have a good read through tomorrow, but
> I do think there aren't sufficient differences between tables in a
> database to justify having a separate class to handle each table,
> when a separate instance of a suitably generic class would handle it
> OK.
>
> I am definitely a TMTOWTDI kind of person, though, and I do agree
> that fundamentally, if the software works, then it's good.
>
> Matt[/color]

If it works then it is not wrong. But if method A is easier to
implement than method B, then (all other things being equal) method A
is better.

Tony Marston

http://www.tonymarston.net/

[Tony Marston]

Re: What is/is not considered to be good OO programming

Matty <matt+nntp@askm enoquestions.co .uk> wrote in message news:<YNPAb.184 78$lm1.155161@w ards.force9.net >...[color=blue][color=green][color=darkred]
> >> "Tony Marston" <tony@marston-home.demon.co.u k> wrote in message
> >> news:7588a50f.0 312050544.1dad5 b57@posting.goo gle.com...[/color]
> >
> > <snip>
> >[color=darkred]
> >>>
> >>> http://www.tonymarston.net/php-mysql...tml#2003-12-05
> >>>[/color][/color]
>
> (Yet Another Follow Up...)
>
> Can't help wondering what the object composition argument was, and how
> on earth you could do it in a logical manner.
>
> A table "has a" page of records?
>
> A page of records "has a" table (what would it do if it didn't?)
>
> Personally, yeah, I think composition isn't the way to do it...
>
> /me thinks How about a table "has a" table perhaps???
>
>
> ;p
>
> Matt[/color]

A table has 4 legs and a set of drawers. Now, if I were to drop the
drawers and spread the legs..... :)


Tony Marston

http://www.tonymarston.net/

[Matty]

Re: What is/is not considered to be good OO programming

Tony Marston wrote:
[color=blue][color=green]
>>
>> FWIW, I still think it's better to have 12 different instances,
>> rather than 12 different classes <duck />...[/color]
>
> According to the principles of OO you are not supposed to instantiate
> an abstract class then feed it the implementation details, you are
> supposed to put the implementation details in a subclass. If I were to
> use the keyword 'abstract' in the class definition (as PHP 5 will
> allow) you will find it impossible to instantiate an abstract class
> directly, in which case you MUST use a subclass.[/color]

Depends on what you're doing with the "Table" class - if it's just a
question of iterating through the records, then one generic table class
would cover the vast majority of applications, without subclassing.

$parts = new Table ('partslist', 'partid', array('partid'= >'Part ID number',
'pdesc'=>'Descr iption', 'stockcount'=>' Number in stock'));

$customers = new Table ('customers', 'custid', arrya('custid'= >'Customer #',
'tel'=>'Contact Phone', 'sic'=>'SIC Industry Code'));

should work fine.

The other comment I'd make on this, is that "abstract" != "abstractio n".

Just because describing a table as

tablename
primarykey
fieldlist

is an abstraction, doesn't mean you need an abstract class for this - a "concrete"
class is fine for this model.

Personally, if I were writing a DB class lib, I'd have something along the lines of

Dataset
Table is-a Dataset
Query is-a Table, has-a SQL query

etc, etc
with Dataset being abstract, but that's just my take on it.
[color=blue]
>
> So, if I have 12 database tables each with a totally different set of
> implementation details, then (according to the above-mentioned
> principle) I must create 12 subclasses. I am right and you are wrong,
> so score 1-0 to me :)[/color]

Yes and no, I would say. Yes, 12 tables requiring totally different handling
code would require 12 different classes. But the original tutorial, as I
remember it, showed 12 analogous tables (treated as a list of fields, etc)
that could all be handled by the same class as different instances, easily.

1-1 perhaps ;p
[color=blue]
>
> If it works then it is not wrong. But if method A is easier to
> implement than method B, then (all other things being equal) method A
> is better.
>[/color]

Couldn't agree more. I just think that your original base class was nearly there
for something that would handle any table, just given a list of fields to use!

Wonder how many months the total lifetime of this thread can be...

Matt

[Doug Hutcheson]

Re: What is/is not considered to be good OO programming

"Tony Marston" <tony@marston-home.demon.co.u k> wrote in message
news:7588a50f.0 312080453.bba84 f8@posting.goog le.com...[color=blue]
> "Doug Hutcheson" <doug.nospam.hu tcheson@nrm.qld .gov.au> wrote in message[/color]
news:<B%NAb.104 2$hX1.34374@new s.optus.net.au> ...[color=blue][color=green]
> > "Tony Marston" <tony@marston-home.demon.co.u k> wrote in message
> > news:7588a50f.0 312050544.1dad5 b57@posting.goo gle.com...[color=darkred]
> > > "Philipp Lenssen" <info@outer-court.com> wrote in message[/color]
> > news:<bqn8cf$23 206g$1@ID-203055.news.uni-berlin.de>...[color=darkred]
> > > > André Næss wrote:
> > > >
> > > > > Tony Marston:
> > > > >[/color]
> >[color=darkred]
> > > > > >
> > > > > > I have condensed the arguments into a single article which can[/color][/color][/color]
be[color=blue][color=green][color=darkred]
> > > > > > viewed at
> > > > > > http://www.tonymarston.net/php-mysql/good-bad-oop.html
> > > > > >[/color]
> >[color=darkred]
> > > > >
> > > > > I just think it's funny that you still don't understand object
> > > > > composition. In your article you write: "How do you share code in[/color][/color][/color]
OO[color=blue][color=green][color=darkred]
> > > > > systems? Through inheritance.", not even mentioning object
> > > > > composition. Object composition was also the crux of my argument,
> > > > > i.e.: where you see only inheritance, I see inheritance and
> > > > > composition. From this we can only deduce that you in fact did not
> > > > > properly understand my argument. That doesn't make the discussion[/color][/color][/color]
any[color=blue][color=green][color=darkred]
> > > > > easier.
> > > > >
> > > >
> > > > I was thinking the same. I saw the article, looked for[/color][/color][/color]
"compositio n",[color=blue][color=green][color=darkred]
> > > > couldn't find it, and went away.
> > >
> > > Just for you I have added a section on object composition. I hope you[/color][/color][/color]
like[color=blue][color=green]
> > it.[color=darkred]
> > >
> > > http://www.tonymarston.net/php-mysql...tml#2003-12-05
> > >
> > > Kiss, kiss
> > >
> > > Tony Marston
> > > http://www.tonymarston.net/[/color]
> >
> > Tony,
> > A trifle defensive <grin>, but wholly correct. As another 25+[/color][/color]
programmer, I[color=blue][color=green]
> > can state without too much fear of contradiction that the customer pays[/color][/color]
me[color=blue][color=green]
> > to solve his problem, not to write code which meets the approval of the
> > paradigm police.
> > More power to you, you rabid radical you!
> > Cheers,
> > Doug Hutcheson[/color]
>
> People tend to describe me more as revolting than rebelling. Is there
> a difference? :)
>
> Tony Marston
> http://www.tonymarston.net/[/color]

"Rebellent" , perhaps?
<g,d&r>
"8-)

[Doug Hutcheson]

Re: What is/is not considered to be good OO programming

"Tony Marston" <tony@marston-home.demon.co.u k> wrote in message
news:7588a50f.0 312080510.fec1f 4e@posting.goog le.com...[color=blue]
> Matty <matt+nntp@askm enoquestions.co .uk> wrote in message[/color]
news:<YNPAb.184 78$lm1.155161@w ards.force9.net >...[color=blue][color=green][color=darkred]
> > >> "Tony Marston" <tony@marston-home.demon.co.u k> wrote in message
> > >> news:7588a50f.0 312050544.1dad5 b57@posting.goo gle.com...
> > >
> > > <snip>
> > >
> > >>>
> > >>> http://www.tonymarston.net/php-mysql...tml#2003-12-05
> > >>>[/color]
> >
> > (Yet Another Follow Up...)
> >
> > Can't help wondering what the object composition argument was, and how
> > on earth you could do it in a logical manner.
> >
> > A table "has a" page of records?
> >
> > A page of records "has a" table (what would it do if it didn't?)
> >
> > Personally, yeah, I think composition isn't the way to do it...
> >
> > /me thinks How about a table "has a" table perhaps???
> >
> >
> > ;p
> >
> > Matt[/color]
>
> A table has 4 legs and a set of drawers. Now, if I were to drop the
> drawers and spread the legs..... :)
>
>
> Tony Marston
> http://www.tonymarston.net/[/color]

Ah - a rebellent furniture fetish!
Strange fruit, Tony, strange fruit indeed.
"8-)

[Tony Marston]

Re: What is/is not considered to be good OO programming

Matty <matt+nntp@askm enoquestions.co .uk> wrote in message news:<_a6Bb.188 36$lm1.161440@w ards.force9.net >...[color=blue]
> Tony Marston wrote:
>[color=green][color=darkred]
> >>
> >> FWIW, I still think it's better to have 12 different instances,
> >> rather than 12 different classes <duck />...[/color]
> >
> > According to the principles of OO you are not supposed to instantiate
> > an abstract class then feed it the implementation details, you are
> > supposed to put the implementation details in a subclass. If I were to
> > use the keyword 'abstract' in the class definition (as PHP 5 will
> > allow) you will find it impossible to instantiate an abstract class
> > directly, in which case you MUST use a subclass.[/color]
>
> Depends on what you're doing with the "Table" class - if it's just a
> question of iterating through the records, then one generic table class
> would cover the vast majority of applications, without subclassing.
>
> $parts = new Table ('partslist', 'partid', array('partid'= >'Part ID number',
> 'pdesc'=>'Descr iption', 'stockcount'=>' Number in stock'));
>
> $customers = new Table ('customers', 'custid', arrya('custid'= >'Customer #',
> 'tel'=>'Contact Phone', 'sic'=>'SIC Industry Code'));
>
> should work fine.
>
> The other comment I'd make on this, is that "abstract" != "abstractio n".[/color]

My class is abstract because it cannot be used without implementation
details, and these details are different for each database table.
Rather than have the implementation details for each table held in
separate script which is then fed into an instance of the abstract
class I feel it is more efficient to hold these details in a subclass.
[color=blue]
> <snip>[/color]
[color=blue][color=green]
> >
> > So, if I have 12 database tables each with a totally different set of
> > implementation details, then (according to the above-mentioned
> > principle) I must create 12 subclasses. I am right and you are wrong,
> > so score 1-0 to me :)[/color]
>
> Yes and no, I would say. Yes, 12 tables requiring totally different handling
> code would require 12 different classes. But the original tutorial, as I
> remember it, showed 12 analogous tables (treated as a list of fields, etc)
> that could all be handled by the same class as different instances, easily.
>
> 1-1 perhaps ;p
>[color=green]
> >
> > If it works then it is not wrong. But if method A is easier to
> > implement than method B, then (all other things being equal) method A
> > is better.
> >[/color]
>
> Couldn't agree more. I just think that your original base class was nearly there
> for something that would handle any table, just given a list of fields to use![/color]

You have missed a subtle point. Each table class is not limited to
those actions required to communicate with a single table - it also
contains all the business rules for the entity that is associated with
that table. This may mean obtaining fields from other sources,
performing calculations, validating against other tables, whatever.
All this *extra* processing is inserted into abstract methods which
are defined as empty stubs in the abstract class.

Perhaps I should have called it an abstract *entity* class instead of
an abstract *table* class.
[color=blue]
>
> Wonder how many months the total lifetime of this thread can be...
>
> Matt[/color]

How long is a piece of string?

Tony Marston

http://www.tonymarston.net/

[André Næss]

Re: What is/is not considered to be good OO programming

Matty:
[color=blue]
> Wonder how many months the total lifetime of this thread can be...[/color]

Well it's gonna last quite a while if you decide to go through everything
all over again, which is what you've started doing. May I suggest that you
just read the thread and save yourself the trouble? :)

André Næss

[Google Mike]

Re: What is/is not considered to be good OO programming

Oh what the hell. Here's my two cents...

I agree with Tony Marston, if I read him right after skimming this
thread. Brit programmers have common sense, unlike most of my American
compatriots I have to interact with in the workplace.

OOP is way overblown. If you use it right, it's great. If you use it
wrong, and many pseudo-senior devs I've seen use it unnecessarily, it
can do nothing but introduce unecessary complexity and even slow the
app down.

For that matter, the same argument can be made for using XSLT to
abstract your presentation layer. XSLT is overblown and introduces
nothing but delays, I find.

The same arguments going on here in PHP are being argued like mad on
the .NET platform too.

Take for example a simple web-based checkbook app for a series of
users. You login, see your checkbook, and can make entries to it.
Here's what a series of developers might think:

psuedo-senior dev 1: Let's make a User object, Checkbook object, Login
object, Logout object, and an Entry object! Let's do objects for
anything we can think of!

psuedo-senior dev 2: Let's make the business layer push out nothing
but XML, then use XSLT to style this output for the end user.

psuedo-senior dev 3: I think we should make the data layer emit
nothing but XML.

psuedo-senior dev 4: I think we should make everything in stored
procedures and make it receive and emit XML. The presentation code can
be written in PHP to read the XML and style it with XSLT.

No. Not me on any of this, even if it were something as complex as a
Near Earth Object Tracking System, and I've been programming since
1979 and am 36 years old. My title says "Senior Developer". My take on
objects, XML, and XSLT would be:

1. I'd use an associate array (better known as a hash table by us old
f*cks), not an object, for the checkbook entry record.

2. Thinking about code-reuse for future projects, I'd bundle my
frequently used functions in a web class, strings class, db class, and
a settings class. That way, when I call a function (er, "method") like
Redirect, I can understand where this method came from, and so can
others who read my code, because I would have it listed in my code as
$web->Redirect('page .php'). If Redirect breaks, you instantly know
it's in the "_web.php" page (if you saw my Requires statement).

3. If an object isn't necessary, I avoid it like the plague. Not by
inexperience, but by /experience/.

4. When I have to work in teams, we decide on a set of pages and a
very small set of objects that we're going to assign to each team
member, and then we iron these out individually for a bit with test
harnesses. Eventually, we start sharing and interacting with each
others stuff when these start to stabilize.

5. I like XML, but I dislike XSLT. XSLT is way, way too difficult of
an implementation of a superbly fantastic idea. I'll wait until
something better comes out to replace XSLT. For now, you'll see me
doing and <% {code} %> and <%= $var %> in my code, although I try as
much as possible to reduce interruptions in the HTML because of the
speed hit. That's why you see me doing most of my code in the top of
the page before the HTML tags.

6. I like XML, but I don't want to make every thing a particular OO
layer run through it, such as making the business layer receive XML
and emit XML. I mean, I'm always on tight project schedules. Many a
stakeholder (end user) on a project will be intolerant of excuses
like, "I'm having problems with the XML." They want me to get in
there, fix the code, and it works. Right now I use XML for storage and
retrieval from text files, or for sending stuff over sockets, or for
interacting with another vendor's stuff. But that's all I've seen a
need for it.

7. I love the encapsulation/abstraction of objects when it makes sense
to implement that. And if OOP is tied in with a GUI, such as a window
or widget, it's cool too, such as the ability to use someone else's
widgets and make my own, or the ability to instantiate a window and
then subclass it. But I always ask myself, is this overblown for this
kind of solution? I like the situation forcing me into using OOP,
rather than starting with it in the first place.

8. If I'm going to make a loadable C++ module for PHP, hell yeah, I'd
use objects to be consistent with how third-party or intrinsic APIs
work in anything from PHP to VB to Java to other languages. But for
business app use, I let the situation dictate the need for objects,
not me project that into the situation.

9. Some portal products that your business app might "snap-in" to
might dictate that you implement your stuff in XML/XSLT, so I think it
makes sense there, just as long as someone proves to me that the
solution is fast enough and scalable enough.

[Matty]

Re: What is/is not considered to be good OO programming

Tony Marston wrote:

[color=blue]
> You have missed a subtle point. Each table class is not limited to
> those actions required to communicate with a single table - it also
> contains all the business rules for the entity that is associated with
> that table. This may mean obtaining fields from other sources,
> performing calculations, validating against other tables, whatever.
> All this *extra* processing is inserted into abstract methods which
> are defined as empty stubs in the abstract class.
>
> Perhaps I should have called it an abstract *entity* class instead of
> an abstract *table* class.[/color]

Fair enough! Personally, I'd use a concrete table class, and subclass
the entities from there, but that's just how I'd do it.
[color=blue]
>[color=green]
>>
>> Wonder how many months the total lifetime of this thread can be...
>>
>> Matt[/color]
>
> How long is a piece of string?[/color]

Depends if it's Good String or Bad String.

Maybe String::Good could have an elasticity member var...

[Tony Marston]

Re: What is/is not considered to be good OO programming

André Næss <andrena.spamre allysucks@ifi.u io.no> wrote in message news:<br4hgi$cl l$1@maud.ifi.ui o.no>...[color=blue]
> Matty:
>[color=green]
> > Wonder how many months the total lifetime of this thread can be...[/color]
>
> Well it's gonna last quite a while if you decide to go through everything
> all over again, which is what you've started doing. May I suggest that you
> just read the thread and save yourself the trouble? :)
>
> André Næss[/color]

I refuse to kowtow to the paradigm police. All the while you keep
spouting rubbish I will keep on telling you that you are spouting
rubbish.

Tony Marston

http://www.tonymarston.net/

[Tony Marston]

Re: What is/is not considered to be good OO programming

googlemike@hotp op.com (Google Mike) wrote in message news:<25d8d6a8. 0312091001.27d1 e483@posting.go ogle.com>...[color=blue]
> Oh what the hell. Here's my two cents...
>
> I agree with Tony Marston, if I read him right after skimming this
> thread. Brit programmers have common sense, unlike most of my American
> compatriots I have to interact with in the workplace.
>
> OOP is way overblown. If you use it right, it's great. If you use it
> wrong, and many pseudo-senior devs I've seen use it unnecessarily, it
> can do nothing but introduce unecessary complexity and even slow the
> app down.
>
> For that matter, the same argument can be made for using XSLT to
> abstract your presentation layer. XSLT is overblown and introduces
> nothing but delays, I find.[/color]

Then your guys haven't learnt how to use XSL properly. It is a
scripting language just like PHP, and as such you can make use of
standard reusable modules. For example, in my sample application
(which you can try online at
http://www.tonymarston.net/sample/index.html) I have a family of 6
components for each entity/table – list, insert, update, enquire,
delete, search – for which I need only 2 (two) XSL stylesheets. Within
each of these stylesheets I make use of the <xsl:include> and
<xsl-call-template> functions to invoke common code. When I want to
paint a data field on a form all I use is the following:

<xsl:call-template name="datafield ">
<xsl:with-param name="item" select="tree_ty pe_desc"/>
</xsl:call-template>

This template/subroutine then decides how to paint the field
(display-only, single-line textbox, multi-line textbox, dropdown list,
radiogroup, checkbox, whatever) using information supplied either in
the XML file or as a parameter supplied at runtime to the XSL
transformation process.

I use similar template calls to build my action buttons, navigation
buttons, column headings, etc. They are documented at
http://www.tonymarston.net/xml-xsl/xml-and-xsl.html.

Using this technique, coupled with my own method of using
classes/objects which so many of you find objectionable, I can define
a database table and build the 6 components to maintain/display its
contents in 60 minutes. That is an average of 10 (ten) minutes per
component. How's about THEM apples!!

[color=blue]
> The same arguments going on here in PHP are being argued like mad on
> the .NET platform too.
>
> Take for example a simple web-based checkbook app for a series of
> users. You login, see your checkbook, and can make entries to it.
> Here's what a series of developers might think:
>
> psuedo-senior dev 1: Let's make a User object, Checkbook object, Login
> object, Logout object, and an Entry object! Let's do objects for
> anything we can think of!
>
> psuedo-senior dev 2: Let's make the business layer push out nothing
> but XML, then use XSLT to style this output for the end user.
>
> psuedo-senior dev 3: I think we should make the data layer emit
> nothing but XML.
>
> psuedo-senior dev 4: I think we should make everything in stored
> procedures and make it receive and emit XML. The presentation code can
> be written in PHP to read the XML and style it with XSLT.[/color]

The simplest way to deal with people like that is to lock them in a
room and see who can produces results the fastest. The winner gets to
keep his job. THAT tends to sort out the men from the monkeys.
[color=blue]
> No. Not me on any of this, even if it were something as complex as a
> Near Earth Object Tracking System, and I've been programming since
> 1979 and am 36 years old. My title says "Senior Developer". My take on
> objects, XML, and XSLT would be:
>
> 1. I'd use an associate array (better known as a hash table by us old
> f*cks), not an object, for the checkbook entry record.
>
> 2. Thinking about code-reuse for future projects, I'd bundle my
> frequently used functions in a web class, strings class, db class, and
> a settings class. That way, when I call a function (er, "method") like
> Redirect, I can understand where this method came from, and so can
> others who read my code, because I would have it listed in my code as
> $web->Redirect('page .php'). If Redirect breaks, you instantly know
> it's in the "_web.php" page (if you saw my Requires statement).
>
> 3. If an object isn't necessary, I avoid it like the plague. Not by
> inexperience, but by /experience/.[/color]

That goes for a whole host of different "thingies". I have seen
programmers try to use every "thingy" in the book just to prove they
know how to use it, which is not the same as using it effectively.
[color=blue]
> 4. When I have to work in teams, we decide on a set of pages and a
> very small set of objects that we're going to assign to each team
> member, and then we iron these out individually for a bit with test
> harnesses. Eventually, we start sharing and interacting with each
> others stuff when these start to stabilize.
>
> 5. I like XML, but I dislike XSLT. XSLT is way, way too difficult of
> an implementation of a superbly fantastic idea. I'll wait until
> something better comes out to replace XSLT.[/color]

I suggest you learn to use XSLT effectively because it is here to
stay. Version 2.0 is in the pipeline, and the recently-released
standard for XFORMS (see http://www.w3.org/MarkUp/Forms/) which will
do away with all that non-standard javascript, is based quite heavily
on XML and XSL.
[color=blue]
> For now, you'll see me
> doing and <% {code} %> and <%= $var %> in my code, although I try as
> much as possible to reduce interruptions in the HTML because of the
> speed hit. That's why you see me doing most of my code in the top of
> the page before the HTML tags.
>
> 6. I like XML, but I don't want to make every thing a particular OO
> layer run through it, such as making the business layer receive XML
> and emit XML.[/color]

My PHP development environment manages to mix a lot of different ideas
– procedural scripts, ‘included' scripts, objects, 3-tier architecture
(with separate presentation, business and data access layers), XML and
XSL transformations , and I like to think that I use each technique to
its best advantage. If an old fart like me can do it, then why can't
the rest of you?

Tony Marston

http://www.tonymarston.net/

[André Næss]

Re: What is/is not considered to be good OO programming

Tony Marston:
[color=blue][color=green]
>> For that matter, the same argument can be made for using XSLT to
>> abstract your presentation layer. XSLT is overblown and introduces
>> nothing but delays, I find.[/color]
>
> Then your guys haven't learnt how to use XSL properly. It is a
> scripting language just like PHP, and as such you can make use of
> standard reusable modules. For example, in my sample application
> (which you can try online at[/color]

It's not like PHP at all. It's functional, for one, and that's actually
great. But the implementation is terrible, the syntax is a chore, and you
constantly find yourself having to go outside the language because it's so
constrained.
[color=blue]
> http://www.tonymarston.net/sample/index.html) I have a family of 6
> components for each entity/table – list, insert, update, enquire,
> delete, search – for which I need only 2 (two) XSL stylesheets. Within
> each of these stylesheets I make use of the <xsl:include> and
> <xsl-call-template> functions to invoke common code. When I want to
> paint a data field on a form all I use is the following:
>
> <xsl:call-template name="datafield ">
> <xsl:with-param name="item" select="tree_ty pe_desc"/>
> </xsl:call-template>
>
> This template/subroutine then decides how to paint the field
> (display-only, single-line textbox, multi-line textbox, dropdown list,
> radiogroup, checkbox, whatever) using information supplied either in
> the XML file or as a parameter supplied at runtime to the XSL
> transformation process.[/color]

I've always found your love for XML and XSLT rather interesting considering
your other practices. How do you apply your beloved KISS principle in this
case? After all, what you propose is to do:

Data->Transformati on to XML (presumably in PHP->XML->Transformati on in
XSLT->Output

When you could do:
Data->Transformati on in PHP->Output

Not only is the former much more tedious to actually implement, it's also
slower, and more prone to bugs because the pipeline is longer, meaning more
code, meaning more chances of bugs.

I'm not saying this is the case for you, but for anyone who are starting
out, who don't have your collection of modules and components, wouldn't you
agree that the XML/XSLT solution looks much more complex?

In short, I understand that you like it. But you can't really say "Now that
I've built a huge library of boilerplate code I can write my apps really
fast", and expect us to take this as an argument in favour of XML/XSLT. It
is an argument in favour of writing reusable code, but from this it is not
clear that XML/XSLT actually makes it easier to do so. So I think you
should explain why:

A) XML/XSLT using two transformations is better than simply doing a single
transformation.
B) XML/XSLT makes it easier to write reusable components.
[color=blue]
> I suggest you learn to use XSLT effectively because it is here to
> stay. Version 2.0 is in the pipeline, and the recently-released
> standard for XFORMS (see http://www.w3.org/MarkUp/Forms/) which will
> do away with all that non-standard javascript, is based quite heavily
> on XML and XSL.[/color]

Well, I'd be surprised to see browser support for XFORMS get to an
acceptable level within the next 4 years :P As long as MS dominates they
have no incentive to improve their browser, and they will continue to
dominate :/

André Næss

[André Næss]

Re: What is/is not considered to be good OO programming

Tony Marston:
[color=blue][color=green][color=darkred]
>> > Wonder how many months the total lifetime of this thread can be...[/color]
>>
>> Well it's gonna last quite a while if you decide to go through everything
>> all over again, which is what you've started doing. May I suggest that
>> you just read the thread and save yourself the trouble? :)
>>
>> André Næss[/color]
>
> I refuse to kowtow to the paradigm police. All the while you keep
> spouting rubbish I will keep on telling you that you are spouting
> rubbish.[/color]

Uh? What did I do now? Are you saying that you *want* to repeat the entire
discussion? I merely pointed out that Matty started making the same claims
that others had made before him, and I see no point in that. But of course,
if you want to repeat the entire discussion once more with Matty, then you
are free to do so. It just seems rather pointless.

André Næss

[Tony Marston]

Re: What is/is not considered to be good OO programming

André Næss <andrena.spamre allysucks@ifi.u io.no> wrote in message news:<br7ekg$l4 a$1@maud.ifi.ui o.no>...[color=blue]
> Tony Marston:
>[color=green][color=darkred]
> >> For that matter, the same argument can be made for using XSLT to
> >> abstract your presentation layer. XSLT is overblown and introduces
> >> nothing but delays, I find.[/color]
> >
> > Then your guys haven't learnt how to use XSL properly. It is a
> > scripting language just like PHP, and as such you can make use of
> > standard reusable modules. For example, in my sample application
> > (which you can try online at[/color]
>
> It's not like PHP at all. It's functional, for one, and that's actually
> great. But the implementation is terrible, the syntax is a chore, and you
> constantly find yourself having to go outside the language because it's so
> constrained.[/color]

I don't have a problem with XSL. When I was building my library of
reusable code I sometimes found that my first approach failed, but by
attacking it from a different angle a solution would materialize. I
have found that anything I can do in PHP code to generate HTML I can
also do in XSL.
[color=blue]
> <snip>[/color]
[color=blue]
> I've always found your love for XML and XSLT rather interesting considering
> your other practices. How do you apply your beloved KISS principle in this
> case? After all, what you propose is to do:
>
> Data->Transformati on to XML (presumably in PHP->XML->Transformati on in
> XSLT->Output
>
> When you could do:
> Data->Transformati on in PHP->Output
>
> Not only is the former much more tedious to actually implement, it's also
> slower, and more prone to bugs because the pipeline is longer, meaning more
> code, meaning more chances of bugs.[/color]

On the contrary, I have found it easy to implement. All my objects in
the business layer return data in the form of associative arrays, and
I have written a single standard function which outputs this array to
an XML file. This is followed by another single standard function to
perform the actual transformation.

These two standard functions are called from within a standard set of
include files, so I don't have to bother recoding and retesting for
each new component.

My library of XSL templates also means less recoding and less
retesting because if a template works in one stylesheet it will work
in all stylesheets.

Other people use different template engines to turn their data into
HTML, but I have chosen to use XML/XSL because (a) it was built for
the job, (b) it does it very well, (c) it is a W3C standard, therefore
more HTML developers will be familiar with it than anything built
around PHP.
[color=blue]
> I'm not saying this is the case for you, but for anyone who are starting
> out, who don't have your collection of modules and components, wouldn't you
> agree that the XML/XSLT solution looks much more complex?[/color]

Anything can look complex to begin with, but my long experience has
taught me to take a complex problem and divide it into lots of simple
problems. Then, by solving each simple problem one at a time the
complex problem eventually just disappears.
[color=blue]
> In short, I understand that you like it. But you can't really say "Now that
> I've built a huge library of boilerplate code I can write my apps really
> fast", and expect us to take this as an argument in favour of XML/XSLT. It
> is an argument in favour of writing reusable code, but from this it is not
> clear that XML/XSLT actually makes it easier to do so.[/color]

The only way to succeed as a programmer in any language is to build up
a library of reusable components so that you can create working
components faster than the next guy. This takes time, practice and
skill, but is an investment that pays off in the end.

When I first starting teaching myself PHP I generated all HTML code
from within the PHP script, but I did not want to waste time
generating hand-crafted code for each individual page. As I was
already familiar with XML and XSL, and because access to these two
technologies was available in PHP, I chose to use these to generate my
HTML output rather than learn *another* templating language or waste
time writing one of my own. It may seem an odd mix, but it means that
I have totally separated my presentation logic from my business logic,
so I can make changes in one without mucking up the other.

It works for me, so I will continue using it. If you want to use a
different method then go ahead.
[color=blue]
> So I think you
> should explain why:
>
> A) XML/XSLT using two transformations is better than simply doing a single
> transformation.[/color]

I only use one XSL transformation per web page. It is true that I have
to transform my SQL data into XML, but this is done automatically
within standard modules so I don't have to think about it.
[color=blue]
> B) XML/XSLT makes it easier to write reusable components.[/color]

I am not saying that it is easier to write reusable components in XSL,
but I am saying that it is *just* as easy to write reusable components
in XSL as it is in PHP. You just have to know how. If you want to see
a working collection of reusable XSL components then download the
sample application from my website. Once you see how easy it is you
will be able to generate reusable components of your own.
[color=blue][color=green]
> > I suggest you learn to use XSLT effectively because it is here to
> > stay. Version 2.0 is in the pipeline, and the recently-released
> > standard for XFORMS (see http://www.w3.org/MarkUp/Forms/) which will
> > do away with all that non-standard javascript, is based quite heavily
> > on XML and XSL.[/color]
>
> Well, I'd be surprised to see browser support for XFORMS get to an
> acceptable level within the next 4 years :P As long as MS dominates they
> have no incentive to improve their browser, and they will continue to
> dominate :/
>
> André Næss[/color]

You can already download and install a free XForms plugin for IE6 SP1
- checkout http://www.formsplayer.com/ The demand for
XForms-compatible browsers is so great that if Microsoft don't get
their ass into gear then customers will switch to other browsers.

Tony Marston

http://www.tonymarston.net/

[R. Rajesh Jeba Anbiah]

Re: What is/is not considered to be good OO programming

tony@marston-home.demon.co.u k (Tony Marston) wrote in message news:<7588a50f. 0312100030.4d54 36a5@posting.go ogle.com>...[color=blue]
> André Næss <andrena.spamre allysucks@ifi.u io.no> wrote in message news:<br4hgi$cl l$1@maud.ifi.ui o.no>...[color=green]
> > Matty:
> >[color=darkred]
> > > Wonder how many months the total lifetime of this thread can be...[/color]
> >
> > Well it's gonna last quite a while if you decide to go through everything
> > all over again, which is what you've started doing. May I suggest that you
> > just read the thread and save yourself the trouble? :)
> >
> > André Næss[/color]
>
> I refuse to kowtow to the paradigm police. All the while you keep
> spouting rubbish I will keep on telling you that you are spouting
> rubbish.[/color]

A person starts a thread, asking comments about his OO tutorial.
Many real programmers here refuse to accept his code as good OO. He
then went to Zend (<http://www.zend.com/zend/tut/tutorial-wong4.php>)
and starts another thread there badly criticizing the author (Benson
Wong). Then, he again came back to comp.lang.php and starts the
"argument" which is not of course a "discussion ". Now, who is
rubbish??

I really appreciate André Næss for his patience. I don't think
anyone will respect a person who stupidly mess with a regular
contributor.

--
"There are two kinds of people, those who do the work and those who
take the credit. Try to be in the first group; there is less
competition there." -- Indira Gandhi
Email: rrjanbiah-at-Y!com