<cftable>, time to upgrade to HTML 4?

[Henry Ho]

As much as I want to use cftable to output a query, I'll have to
convert back to use cfloop when the client wants odd / even coloring.
CSS3 might help, but still, can <cftable> be improved? If so, how?

Maybe stop generating deprecated HTML attributes for a start? No more
align="left" please?

Just brainstorming, thought?


Henry

[Matthew Woodward]

On Mon, Jun 21, 2010 at 12:24 PM, Henry Ho <henry...@gmail.com> wrote:

Just brainstorming, thought?

To take things up to an even more abstract (and probably obtuse) level, personally I'd like to see ALL of this kind of stuff be as "pluggable" as possible. Meaning take anything that's HTML, JavaScript, CSS, etc. related and package it up so it can be updated independently of other things, or easily customized as needed.

In some ways this is a moot point for the open source engines since they can update as needed and people can grab the nightly if they want the latest, but if someone wants to run a later engine but earlier versions of the "front end" type stuff, or vice-versa, it would be nice if they had the flexibility to do that.
--
Matthew Woodward
ma...@mattwoodward.com
http://blog.mattwoodward.com
identi.ca / Twitter: @mpwoodward

Please do not send me proprietary file formats such as Word, PowerPoint, etc. as attachments.
http://www.gnu.org/philosophy/no-word-attachments.html

[Mark Jones]

> To take things up to an even more abstract (and probably obtuse) level,
> personally I'd like to see ALL of this kind of stuff be as "pluggable" as
> possible.

A+++ Would agree again.

[Alan Williamson (aw2.0 ltd)]

I completely agree that this is a tag, as is CFSELECT, CFINPUT, CFTABLE
that could all be pluggable. But how would you like to see that
manifest itself? How do you see the plugin working?

[Mark Jones]

On Tue, Jun 22, 2010 at 5:37 AM, Alan Williamson (aw2.0 ltd)
<al...@aw20.co.uk> wrote:
> I completely agree that this is a tag, as is CFSELECT, CFINPUT, CFTABLE that
> could all be pluggable. But how would you like to see that manifest itself?

I'm a terrible person to answer that, since I avoid *all* of the
UI-helpers and would continue to do so even if they were "pluggable".
I don't think I've ever used an off-the shelf UI solution (including
javascript menu libraries, etc) that didn't bite me at some point when
a change that was outside of that helper's capabilities became
necessary. My preference here is that the UI stuff be somehow
*presented* differently from the core language / logic part, so that
people don't automatically equate CFML with "the language that uses
those ugly widgets" just like I equate .NET with "the language that
absolutely positions random DIVs on the page willy-willy".

If you ask me, the CFFORM functionality would be much better served by
a library of some kind. Forms are a perfect example of something that
*seems* simple to abstract out, but becomes insanely complicated when
you need to cover all of the bases.

At the same time "just write the code yourself" is a horrible stance
to take as well.