Opened 7 years ago

Closed 7 years ago

#1478 closed enhancement (fixed)

Many changes introduced today (tracking ticket).

Reported by: gogo Owned by: gogo
Priority: normal Milestone: 0.96
Component: Xinha Core Version: trunk
Severity: normal Keywords:


This is a tracking ticket for a number of changes which I am introducing today into Trunk from my private branch, these have been floating about for a while so time to get them through...

Creating Sub Classes

Addition of method Xinha.extend. This method provides a means for more "classical" sub classing within javascript. Short story,

    var Vehicle = function() { }
    Vehicle.prototype.horn = function() { alert('Toot'); }

    var Car = function() 
	{; // If you want to call it.
    Xinha.extend(Car, Vehicle);
    Car.prototype.horn = function() 
		alert('Toot');;  // If you want to call it.

remember the "call" method of javascript is .call(<on-this-object>, arg, arg, arg ..) and that you can also use the "apply" method to pass in arguments as an array which is .apply(<on this object>, [arg, arg, arg]), and that the arguments to your method are in the "arguments" array.

Dialog Modification

Split out the setting of the localizer from the translation of HTML in source:trunk/modules/Dialogs/XinhaDialog.js by introducing a new method Xinha.Dialog::setLocalizer(), Xinha.Dialog::translateHtml() remains compatible, the localizer is optional to it.

.htaccess Security

Further additions to the .htaccess files for the demo_images in ExtendedFileManager and ImageManager. I think we should give consideration to just deleting these folders totally, over the last year I've had a number of instances of people coming to me with these folders filled with various malware.

File-Picker on arbitrary fields outside Xinha (ExtendedFileManager)

Addition of a source:trunk/plugins/ExtendedFileManager/file-picker.js hijacking of the ExtendedFileManager in the same manner as the existing source:trunk/plugins/ImageManager/image-picker.js within ImageManager. I'm putting this n there incase somebody finds it useful, but it may need some work as I don't use it myself any more. I am likely to come up with a way to replace both ExtendedFileManager and ImageManager with the "Mootools FileManager", this is a very nice file manager with a similar dialog "look" to our new dialogs, and the very VERY important bonus of it being easy to upload multiple files at once with a progress indicator (using a hidden flash component to do the hard work).

ImageManager to use hspace and vspace attributes instead of margin.

The addition of a config option to ImageManager "UseHSpaceVSpace" which swaps out the "margin" settings for the hspace and vspace attributes. The reason for this apparent "old fashioned-ness" is that margin is less reliably honoured when the HTML is put into an email.

YouTube and Flickr added to the ImageManager

The addition of additional data sources (aka backends or choosers) to ImageManager, specifically "YouTube" and "Flickr".

When one or both is enabled the user can use a selector in the image manager popup to choose from images on the local server, or search for videos on YouTube, or images on Flickr.

YouTube is enabled by setting $IMConfig['YouTube'] = TRUE; when the user selects a video the large format video still is inserted into the Xinha area, with extra information on the query string.

Flickr is enabled by setting $IMConfig['Flickr']['Key'] = 'your flickr api key here';, when the user selects an image, the image is inserted into the Xinha area.

For videos especially there needs to be some extra processing to turn that into a video when the end user sees this HTML, this is done by the "smart-image.js" script in combination with the (included) swfobject. In short, on the page WHERE YOU USE THE HTML (not where you are running Xinha to edit it) you will put this

   <script type="text/javascript" src="/path/to/xinha/plugins/ImageManager/smart-image.js"></script>
   <body onload="SmartImages.replace_all();">

it will replace the still image with the video (provided javascript is on).

Smart-image will also add a little hover attribution to Flickr sourced images (ie, hover over the image an attribution link appears). If you are going to use the Flickr source, then you must make sure you are legally permitted to do so, for one, your site can not be commercial. I've provided you with the tools, just try not to shoot yourself.

New Dialog Types

Added a new Dialog type "DetachedDialog?". This "faked" dialog extends the Xinha.Dialog and is a "drop in" replacement for it, the difference is the DetachedDialog? is not associated to any instance of Xinha. No Xinha needs to be instantiated for a "plugin" to use a DetachedDialog?. Where this is useful is in leveraging off plugins to provide functionality outside of Xinha, see link-picker.js below (in Linker).

Also added a new Dialog type "DivDialog?". Similar to the DetachedDialog?, except the dialog HTML is written directly into an html element supplied to the dialog. The use of this is similar to the above, providing a means for getting a plugin "away" from Xinha to provide it's services for other things. This Dialog may need some work since it was written before the new Xinha.Dialog was created, in brief test it worked mostly. Worth keeping around as it's a pretty simple example of how a new Dialog type can be constructed by extending the existing one.

Added a "Link Picker" to leverage the Linker plugin for providing a "Browse" button next to normal input fields in order to select a link which is written into the field.

This is the initial usage of the DetachedDialog?, the basic usage of this is described in the comments in that file source:trunk/plugins/Linker/link-picker.js

Hid all dotfiles from the Linker scanner, the linker shouldn't be showing "hidden" files.

CSS fix to dTree in linker, just to make sure it's styles were not getting clobbered.

Stylist Duplicate Stylesheet Fix

Stop the Stylist from possibly adding a duplicate stylesheet into pageStyleSheets, this was creating a subtle problem in certain circumstances.

New Plugin: WysiwygWrap?

Added a new plugin WysiwygWrap, basically this wraps the content of your Xinha with some specific elements you tell it, when in Wysiwyg mode, and strips them out again when you go back to code (or submit). The idea is to make it so that, combined with an appropriate pageStyleSheet(s) you can more easily simulate in Xinha what it will "look like" when that HTML is "published" wherever it's getting published.

It takes a simple configuration of xinha.config.WysiwygWrap = { elements: [ list of the ancestor elements to insert, in order top down ] }

  xinha.config.WysiwygWrap = { elements: ['div#outer', 'div.inner'] }

will produce this in your Xinha Wysiwyg mode html

	<div id="outer">
		<div class="inner">
			** Original Xinha Content For Editing Here **

so your pageStyleSheet would just make nice CSS for those outer and inner to make the html in the Wysiwyg mode look closer to how it would look "on the site".

In practice, I'm not sure this works that well, it seemed a good idea at the time, but it can be a bit fragile.

Change History (3)

comment:1 Changed 7 years ago by gogo

Committed in changeset:1192

comment:2 Changed 7 years ago by gogo

  • Type changed from defect to enhancement

comment:3 Changed 7 years ago by gogo

  • Resolution set to fixed
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.