> [PS: can't this frakking list do plaintext???]

Yeh - just go the web site and change your prefs

> >> using DA and the 'raw functions' intermittently inside a single
> >> project seems inconsequential to say the least.
> >
> > Not sure what your observation here is
>
> mixing the use of data abstraction layer and ibase_* directly

I now you are referring to this but
"seems inconsequential to say the least."
Doesn’t make sense.
You're saying that it is of no consequence (no matter) but I think you are
inferring you have a problem with it.
I don't have aproblem with it since my abstraction layer interaction is
always on read-only.

>
> ...
>
> >> you generally output HTML before running logic/doing queries/etc?
> >> that is yuck imho.
> >
> > I see no problem with it. I use page buffering sometimes in
> the same
> > why I use try exception blocks, so I can catch exceptions
> and redirect
> > or place html in response.
>
> > "yuck" sounds like a personal thing anyway.. :-)
>
> probably - but if your hammering on about performance
> (millisecond this and that) then I'd say using output buffers
> to 'fix' such things is the wrong solution.

Buffering is a way to respond or cater for something - not fix something
which is broken.
When I export a csv file as an attachment I use buffering too - it won't
work otherwise.
My performance comments are based around the major part of the page
delivery. The performance win is already there, no amount of choice over
string concatenation, line breaking etc is going to make any real
difference. That's my point.

> >>
> >> > <?php
> >> > include "version.php";
> >> > include_once "ezfirebird/ez_sql.php";
> >> > include_once "ez_resultsmcs.php";
> >> > include "metatags.php";
> >> > ?>
> >> > <title>Account Browser</title>
> >> > <script language="JavaScript">
> >>
> >> this is more correct, also there should be html comments
> (or better
> >> yet an HTML comments CDATA declaration) to hide the JS
> from old/shite
> >> browsers:
> >
> > In this instance it's a coporate environment - no such
> browsers exist.
> > But if you've looked at recent stats of browser use, there are not
> > many "shite" browsers around anymore anyway.
>
> I see no extra cost in writing valid (x)HTML regardless of
> the environment with the added bonus of being more future proof.

Future proofing is separate topic IMO. I have websites still running on code
I wrote over ten years ago. They still work as designed even though the
façade has changed several times. And it looks like my ASP code will
continue to work very nicely for another ten years. How much of a future do
you want my clients to have before they need me again?

>
> >
> >>
> >> <script type="text/javascript">
> >> /* <![CDATA[ */
> >>
> >> function bla() {}
> >>
> >> /* ]]> */
> >> </script>
> > ....
> >> > <?php
> >> > // Submission Actions
> >> > ----------------------------------------------------------
> >> > if (($_POST['toggledns']=="ok")&&($_POST['accountid']!=null)) {
> >> > $toggleid = $db->get_var("SELECT O_UPDATE FROM
> >> > TGL_DNS(".$_POST['accountid'].",'T')");
> >> > $_GET['BRSR']=$_POST['BRSR'];
> >> > $_GET['f']=$_POST['f'];
> >> > $_GET['alpha']=$_POST['alpha'];
> >> > }
> >> > // Data extraction
> >> > ----------------------------------------------------------
> >> > ---
> >> > $db_table_name ="ACCOUNT";
> >> > $db_table_fields ="ID, ACCOUNT, DESCRIPTION, "; $db_table_fields
> >> > .="(SELECT COUNT(*) FROM CONTACT WHERE
> >> > CONTACT.FK_ACCOUNT=ACCOUNT.ID) AS CONTS, "; $db_table_fields
> >> > .="(SELECT ADDRESS1 FROM ADDRESS WHERE
> >>
> >> ...
> >>
> >> > $db_table_where ="WHERE FK_SECCODE=".$_COOKIE['FK_SECCODE'];
> >> > $alphacode = "";
> >>
> >> all the above can be done in a single string which would
> make it more
> >> readable.
> >
> > I think this is very much personal taste as to what's more
> readable.
> > When you start manipulating where and order by clauses according to
> > input variables, one string isn’t going to do it anyway.
>
> my own example verifies that. it's the endless concatenation
> I was referring to.

Endless?
I'm afraid I'm as defensive about this as you are harsh in your comments...
:-)

>
> > Your example is one string but it's line broken to make it
> readable -
> > what's the real difference?
>
> it's spread over many lines on purpose to make it readable
> but there are no quotes and semicolons all the way through. I
> agree though that comfort level is a matter of personal taste
> and what you are used to using.

I have no problem reading semi-colons - I work in Delphi too!!!

>
> I prefer :
>
> $sql = "SELECT foo
> FROM foobar";
>
> to:
>
> $sql = "SELECT foo";
> $sql .= "FROM foobar";
>
> the single string is also a millisecond or so faster ;-)

Sure - I'll time it and get back to you :-)
Key word here is "prefer"

> >>
> >> defining functions halfway down a script rather than at the
> >> top/bottom or preferably in a seperate file is maintainable?
> >
> > Absolutely! Since these are functions used by the layout
> class, they
> > use column number identifiers from the query above so the layout of
> > the query makes it easy to count the field/column
> positions. Remember,
> > there are over a hundred pages in this project with the exact same
> > layout - you can jump directly to the same part in the
> page... It's so
> > reliable.
>
> I would say it's broken by design if it's repeated in 100's
> of files. my simpleTable() function does pretty much the same
> thing ... all the display logic is blackboxed into a single
> function and reused in lots of places.

And so too is a file include - the footer html is one small chunk of html
used over and over.
A perfect example really...

$Page->showFooter();
and
<?php include "footer.htm";?>

Both these lines require one execution cycle each.
The first, however, requires execution of the class function, perhaps echo
statements etc.
The second, just delivers the static content into the webserver's response
object, no filtering or other execution required.
The second also allows this much coveted separation of design and logic
since the htm file itself is identified to the web designer (maybe someone
other than the code developer) that it is editable for design purposes only
and will have no impact on the coding execuion.

> >>
> >> I guess XHTML is not your thing ;-)
> >
> > Generally not and not in this project. Do I really need it?
> Will it do
> > this job 300 millseconds faster?
>
> will it do it any slower? no - it is more future proof,
> additionally using CSS instead of inline FONT tags and the
> like is more manageable and allows much greater visual output
> consistency at no extra cost.

Clearly, I use CSS. Many inline references are to classes.
I type quick though, and make no hesitation to spcific design decisions
since I design as well and noone else works on my code.

>
> >
> > I could live with your code too. It's not much different in my
> > opinion. You may disagree.
>
> I think I could live with your code - but looking at it I
> wouldn't want to, I'd argue that makes mine somewhat more
> approachable for someone who is not familiar with it, well
> 'argue' is a strong word, 'hope' is more appropriate.

Yes - I think you are right but my response to your code is exactly the same
as yours to mine. There's no way around that. I don’t like the way a lot of
other people code in Delphi either beciuase it's "just not the way I do it".

>
> I don't expect new maintainers of my code to like it but I do
> try to write stuff that thirdparties will be able to look at
> and quickly grok it without hurting their eyes ... I've
> probably failed in this respect more times than I have succeeded :-)
>
> ... before this becomes a pissing contest I'll concede that
> the differences are not that great :-)

Agreed absolutely. Both are not relying on a monolithic set of framework
classes - and that's what started this discussion.

>
> > E.g.
> > $Page->showFooter();
> > And
> > <?php include "footer.php";?>
>
> no real difference here - if we discount global scope
> pollution and the point at which the output is done.
> personally I try to follow a [semi-]fixed order of doing
> things in simple pages like these:
>
>
> 1. init app / include page specific funcs /etc
> (auto_prepend_file is often my friend) 2. grab/clean input
> variables 3. do some logic 4. grab data / do queries 5. output page
>
>
> > or even
> > <?php include "footer.htm";?>
> >
> > Any real benefits? Are there milliseconds invoiced here?
>
> what is with all these milliseconds? I wasn't arguing OO over
> procedural includes in this case although I do think that
> encapsulating stuff in functions/classes is generally
> preferable to an include, in the global scope, that generates
> output because you minimize the chance of variable pollution,
> conversely I don't like it, generally, when an included file
> relies on variables defined in the including file.

The thread started with the framework yeh or neh discussion. My initial
comment was - "no framework for me cause it's bloatware".

>
> although I'd take maintainability over performance any day of
> the week ... not to say I'd be content to deliver something
> that was slow as molasses but bigger iron is always cheaper
> than increased developer maintainance time.
>

I don't think my time is ever wasted here. I'm in no way embarrassed about
my maintenance performance.
I can re-write large sections of an application "in the blink of an eye" if
I need to. I think this argument is overplayed sometimes. Crumbs, you're not
even doing a compile, run, test, setup creation, deploy, test again etc
cycle. You edit and ftp the changes... What a dream!
There's a x10 factor associated with brand new client requirements' design
and implementation in my experience which has little to do with any inherent
"existing code maintainability" scenario.

> >
> > Alan

Anyway Alexandre, there you have a rich set of comments for you to base some
of your decisions one.
Alan