ColdFusion, CSS, And Underlying Java Methods (Your Thoughts)
Posted October 9, 2007 at 11:15 AM
I was just reading over on Dave Ferguson's blog that he used custom CSS to change the modal mask color of the elements rendered using ColdFusion 8's new CFWindow tag. This brought up a very interesting thought in my mind - is this something that anyone should attempt to do?
Here's my thinking: the rendered XHTML and CSS are part of ColdFusion 8's underlying and undocumented implementation of the new layout and AJAX features. To me, this is right on par with the Java functions that are also undocumented yet available on all ColdFusion objects. There's nothing here to say that the next HotFix or the next ColdFusion upgrade won't completely change the way the XHTML or the CSS is written (and therefore break any overriding CSS rules you have).
Now, the slight difference here is that if the CSS changes in an update, the site won't break functionally, whereas if the underlying Java implementation changes, a site may very well stop working (if it references those formerly available Java methods). While this might sound like a large difference, I say "slight" since both of them would require a developer to manually fix code (and at that point, the difference in update time is probably only minutes vs. hours - not a huge deal in my mind if it's part of a system upgrade).
That being said, I am NOT saying that Dave is wrong or that you should ignore the available, underlying implementation; to the very contrary: I am one who believes that harnessing the power of underlying features is a good thing (and is really only just one more thing to consider when upgrading a system). I am just wondering what people's thoughts are on this - sometimes it is easier to formulate opinions when the example is more tangible (CSS vs. Java).
All in all, I assume that the people who oppose calling underlying Java methods will also oppose adding your own CSS overrides, but I am curious.
Post Comment | Ask Ben | Permalink | Print Page
Reader Comments
I can't see the problem with doing either.
All either means is that you have to double check everything before applying the update to the live server, but everyone does that anyway, right :-)
I'm too lazy to look it up right now, but I could've sworn I read in the docs that it's appropriate to modify the css as described. Of course, maybe I just saw that on some blog or other unofficial source of information somewhere.
It's certainly common to do so in EXT. Matter of fact, EXT gives you hooks for doing just that. That said, it's certainly a use at your own risk kind of thing.
@Marc,
You might be right; I don't know all that much about the way the CF8 interface stuff is done. I just assumed that it was undocumented (perhaps I have made an Ass out of me :)).
I don't know Ben: I tried finding in the docs the stuff i thought I had seen, but I couldn't find it anywhere. I did see that you can pass through styles to the various widgets, but I didn't dig enough to see if all they're doing is modifying the x-???-??? classes or if they're just passing those styles straight through to the divs.
I do believe, though, that one should use caution when modifying the classes and that one should understand things might not work as expected. Just the other day, I was working with EXT and its ColumnLayout. I needed some margins, so I just trumped the x-panel (or whatever it was) class and added margins. lo and behold, the right panel done went and dropped off the screen. So... whoops!
All he is doing is overriding a style ( x-dlg-mask ) in his external css file - it's not like he's hacking a jar file or something to do it...?
@Todd,
I didn't mean to say that what was going on was an extreme measure or even a harmful one (in fact, it was quite minimal on the grand scale of things). All I wanted to do was get people's thoughts on modifying the underlying implementation.
I use the underlying Java methods on the ColdFusion String object all the time and sometimes I get some heat for it. I wanted to see what people thought if the spot light was shifting to something that was perceived as less invasive or harmful, to see if their feelings about it changed.
I hacked my own css at work recently. I thought it was cool. :) I had a global id style for an accordion widget and I didn't want to change it so I added a class with some style overrides for that particular instance. Worked pretty well. :)
Overriding the default styles are allowed within CF8. As was noted above the Ext library allows for a lot of customization. CF gives you access to the underlying Ext objects for windows (Ext Basic Dialogs). What I would not do is customize the window implementation by extending the javascript. The version of Ext utilized by CF is still 1.0 and I assume that they will continue the update since Ext is an awesome library and some of the 2.0 features are different. You can also create and assign custom plugins and configuration to the FCKEditor implementation.
@Donnie,
If:
Overriding the default styles are allowed within CF8
... then I was just not fully aware of the CF8 specification (not surprising as I have not really done anything with the Layout related features of CF8 yet). I suppose that that makes the post here an invalid point.
There is a tag called cfajaximport that has an attribute called scriptsrc where you can provide your own path to all the JavaScript, CSS, and image files needed for the CF8 AJAX features.
Why is this so important? So this way you can have multiple applications each with their own copy of those files and you don't have to overwrite anything within the CFIDE where it would affect other applications globally. With that tag you can now safely customize any of the CSS files. Thats why they are there for! Go crazy editing them. :)
just as an aside: were one so inclined to try importing the new ext2 (still in alpha)....you're in for a rude awakening. they seem hell bent on keeping that framework tight, and when they need to change something for the betterment of the framework, it doesn't look like they're focusing too much on backward compatibility. Which I think is great, by the way. They are posting an "upgrade path", and that's helpful. But it does mean that drop-in JS replacements are going to be more difficult for EXT. It'll be interesting to watch how adobe handles this for CF9, since they've been very cognizant about not breaking people's code. Most likely it'd only affect people who did stuff like mygrid.getGrid() and then modified the underlying widget and not the people who went straight up CFGRID, for example.
