Yes, you can customize the dialogs based on the dialogDefinition event (look at the "Using the JavaScript API to customize dialogs" example) and setting there the .default property for each element that you want to adjust.
I'm in a similar boat, and the fix I had puzzled out for previous versions of CKE isn't quite cutting it now.
What I'd done is take the file in plugins/image/dialogs/image.js, line 10, where where the id "txtBorder" is defined, changed it's default from a blank to 1.
Now, that still works, to start - if I have the editor open, click the image icon to add a new image, the "border" field shows a 1 by default, as desired. Browse the server, find an image, drop it in. I also use the code from the output_html sample to sniff out certain values in styles and spit them out as standalone attributes - the output_html file has code for doing that with width and height, and those bits are easily hacked to deal with border-width as well. (Though I do comment out the "replace" bits, because I do want both the styles and attributes in there, due to the fact that content created in our system is often used for email marketing, and different email browsers/webmail solutions out in the world use these bits differently.)
My current issue has to do with when you edit the properties of a previously-placed image.
What I'm finding - and this is with the demo on the ckeditor.com site as well - if you have an image placed, that you have set a border value of 0, and you edit the properties of that image - the border field is blank. A zero is a legit value here. Regardless, if you then save the image properties, the demo version does seem to retain the 0px value for border-width in the source code.
But with the txtBorder element having the default changd to 0 (or to be specific, '0' - the single-quotes are present to start with, and required - leaving them out doesn't work) in the image.js plugin file, this is not the case - if you then pop open the image prefs popup on an image with the border set to 0, and the border field blank, and then save - the border-width and border-style values vanish entirely.
I've done some experiments, pulling in a fresh image.js file from an untouched download of CKE 3.5 and using that - and it works the same as the demo on the CKE website. And going into *that* file and adding that '0' for the txtBorder default reintroduces the issue again.
I'm going to stare at this code some more and see if I can't figure out why the presence of that default of '0' causes this pesky issue, but if anyone else has some input, by all means.
After some more tinkering... the issue seems to be with what occurs between two runs of the "setup" function in the JS code defining the txtBorder bit.
I dug out the image.js file from the _source/plugins/image folder and started using that, as it's formatted in a human-eyeball friendly way, plus the variables are spelled out. After throwing some alerts into strategic spots, what I've found is that when opening up the image properties dialog on an existing image - regardless of the border value - the "setup" function gets run through twice.
However, in the case where the border width is 0 - in between the two runs of "setup", the border value changes from 0 to a blank. And it's that second run of "setup" that says "oh now the border is blank - and that doesn't match the default value (as I have txtBorder's default set to '0') - let's strip all the border info out".
With txtBorder's default still set to a null field, and the border value set at 0, and popping the image prop dialog, "setup" runs through twice as usual, but doesn't null out the border value, and hence, leaves the related style values alone.
At this point I'm unsure as to what's going on *between* the two runs of that "setup" function and why, in that process, the code feels the need to nuke my current value if its set the same as the default, and the default is set to 0. (I also just tried setting the default to another value, 3, and running the same thing - and the 3 value stuck fine. So I assume it's an issue with 0, some sort of true/false bit.)
Well, got a fix now. The culprit was the this.setValue(var) in that area. I'm not sure where the code for that function resides, but putting a check around it - if (value != 0) { this.setValue(value); } (or, in the code in the plugins folder, sub "E" for "value"), that gets around the zeroing-of-zero issue. Works great so far.
I imagine this is an isolated issue - how many other areas are there where a zero is a legit value? Table borders I suppose, which kind of gets back to the original poster's issue. I'll have to poke to see if the table properties dialog, in conjuction with setting the table border default to 0, does the same thing...
Re: default values in popup dialogs (img, table, etc)
Re: default values in popup dialogs (img, table, etc)
This seems to be what i need:
But how can i get the Content-IDs (eg 'url')
Is there any documentation of the content of the different dialogs?
I searched the Javascript API documentation a while, but couldn't find anything.
thanks,
Quicks
Re: default values in popup dialogs (img, table, etc)
Re: default values in popup dialogs (img, table, etc)
What I'd done is take the file in plugins/image/dialogs/image.js, line 10, where where the id "txtBorder" is defined, changed it's default from a blank to 1.
Now, that still works, to start - if I have the editor open, click the image icon to add a new image, the "border" field shows a 1 by default, as desired. Browse the server, find an image, drop it in. I also use the code from the output_html sample to sniff out certain values in styles and spit them out as standalone attributes - the output_html file has code for doing that with width and height, and those bits are easily hacked to deal with border-width as well. (Though I do comment out the "replace" bits, because I do want both the styles and attributes in there, due to the fact that content created in our system is often used for email marketing, and different email browsers/webmail solutions out in the world use these bits differently.)
My current issue has to do with when you edit the properties of a previously-placed image.
What I'm finding - and this is with the demo on the ckeditor.com site as well - if you have an image placed, that you have set a border value of 0, and you edit the properties of that image - the border field is blank. A zero is a legit value here. Regardless, if you then save the image properties, the demo version does seem to retain the 0px value for border-width in the source code.
But with the txtBorder element having the default changd to 0 (or to be specific, '0' - the single-quotes are present to start with, and required - leaving them out doesn't work) in the image.js plugin file, this is not the case - if you then pop open the image prefs popup on an image with the border set to 0, and the border field blank, and then save - the border-width and border-style values vanish entirely.
I've done some experiments, pulling in a fresh image.js file from an untouched download of CKE 3.5 and using that - and it works the same as the demo on the CKE website. And going into *that* file and adding that '0' for the txtBorder default reintroduces the issue again.
I'm going to stare at this code some more and see if I can't figure out why the presence of that default of '0' causes this pesky issue, but if anyone else has some input, by all means.
Re: default values in popup dialogs (img, table, etc)
I dug out the image.js file from the _source/plugins/image folder and started using that, as it's formatted in a human-eyeball friendly way, plus the variables are spelled out. After throwing some alerts into strategic spots, what I've found is that when opening up the image properties dialog on an existing image - regardless of the border value - the "setup" function gets run through twice.
However, in the case where the border width is 0 - in between the two runs of "setup", the border value changes from 0 to a blank. And it's that second run of "setup" that says "oh now the border is blank - and that doesn't match the default value (as I have txtBorder's default set to '0') - let's strip all the border info out".
With txtBorder's default still set to a null field, and the border value set at 0, and popping the image prop dialog, "setup" runs through twice as usual, but doesn't null out the border value, and hence, leaves the related style values alone.
At this point I'm unsure as to what's going on *between* the two runs of that "setup" function and why, in that process, the code feels the need to nuke my current value if its set the same as the default, and the default is set to 0. (I also just tried setting the default to another value, 3, and running the same thing - and the 3 value stuck fine. So I assume it's an issue with 0, some sort of true/false bit.)
Re: default values in popup dialogs (img, table, etc)
I imagine this is an isolated issue - how many other areas are there where a zero is a legit value? Table borders I suppose, which kind of gets back to the original poster's issue. I'll have to poke to see if the table properties dialog, in conjuction with setting the table border default to 0, does the same thing...