I'd like to know if it is possible to allow content in a nested widget which isn't allowed by the parent widget.
I tried to allow images in the nested widget (using "img[alt,!src];"). The parent doesn't allow images. I can place images in the inner widget but it's filtered afterwards (e.g. by switching to source code and back).
Unfortunately, as far as I remember this will not be possible. The whole content is first passed through the main filter, and then each of editables passes its content through its filter. Unfortunately, implementing widgets in CKEditor 4.3 (meaning - dozens of major relases since 3.0) we had many architecture limitations and this was one of them.
You can, however:
mark elements which should not be filtered with data-cke-filter="off" attributes, but this solution is pretty inconvenient, because all data-cke-* attributes are automatically removed when getting data from editor, so you would need to add it dynamically when loading data,
use editor.filter.addElementCallback() - with this you can disable filtering of a chosen subtrees. You will need to check context of the element that you're skipping, to allow these images only inside future widgets, but not outside them.
Related
I have a website that has a sidebar on it with way too many elements on it and I would like to write a browser add-on (available for as many modern browsers as possible) that lets users adjust the elements on the sidebar. Luckily I have access to the original React component that is used for the sidebar. I imagined the addon would work as follows:
A settings page allows users to design their own sidebar. For this, I believe I somehow must fetch the site content (which is probably React code) execute it (?), and find the node that I want to replace. Then I grab the elements on the sidebar to fill the default sidebar that the user can then configure to their own needs. Is executing the react code to get the elements the right approach here? If so, how would I do that?
When the user goes to the web page, a script is executed that will either find the dom element and replace it and update it each time the React Dom is updated (? not sure if that is even possible) or somehow locate the component in the React script and edit that. Again, not sure if that is even possible. An alternative would be to create an empty div and populate it with my custom component while setting the display property of the original component to none.
I would really appreciate it if somebody could let me know whether what I am trying to do is even possible, whether I am on the right track, and maybe can give me some hints on where to look for further information on how to achieve such a thing.
I am currently using the Views and Display Suite modules to create a page that works as an image gallery. You click on the menu button to take you to a page (the view) that has multiple links to nodes (individual galleries).
When you click these nodes, they take you into the separate page and show all images uploaded using the "event" content type that I made.
The event content type has one field (type: image) that uses a multiupload widget, allowing for multiple file uploads.
However, the images on the node are displayed within divs, so they all have their own rows basically. I would like to know if it was possible to put them all into grids, and if so; how? I tried using display suite, but I only have that one field to work with.
If you want to get a fully customized page and arrange the fields just like you want, use the theme suggestions.
For a node of type "event", as you said, it would be node--event.tpl.php. You can duplicate the code inside the base template node.tpl.php of your parent theme (or if you don't have one, of Bartik for example) to have a good starting material.
Just rearrange the div, the tags, the variables as your convenience, add some custom CSS to make your grid, and you should be done!
I hope it helps.
This seems simple enough but I can't quite think of how to actually do it...
In IBM Web Content Management (WCM) version 7 I have a Presentation Template (PT) which calls a Menu Component to display some content items.
I also have some (static) links on the sidebar which I want to basically just change the menu component that is being used, and that's it.
So for example...
In the PT:
[Component name="Main Page"]
When I click on a link, I want the exact same PT to be displayed except I want it to use:
[Component name="Next Page"]
Basically, Main Page and Next Page are showing the same content items, they just have different filters on them (so they appear to be different pages). The "Main Page" shows "everything" and then if you click on a link it's suppose to only show a subset of that.
I can't quite figure out how to connect the link to the PT to change it. I've thought about using JavaScript or JSP to simply rewrite the HTML, but even then I'm not sure how I set it up to say that: "if the link has been clicked, rewrite the HTML" because I'm not sure what to even point the link to, or pass through the link.
I thought about creating different content items with different PTs to link to, but there are about a dozen links (and therefore a dozen different Menu Components that I want to use), so I thought it might be better in the long run to just use 1 dynamic PT (in case the number of links grows).
It is only that one component that needs to be changed in order to display how I need for every link though.
Any ideas how to go about doing this?
So this is how I resolved this:
I created a component reference element in the content items called "menuComp" and then I set that to point to the appropriate Menu Component for each particular page.
In the presentation template, I removed the component reference and changed it to an [Element] tag which used key="menuComp".
I have a basic ASP.Net MVC 3 application which has a number of controllers and a number of actions (and subsequently views)
A common feature of the application is to show a pop-up dialog window for basic user input. One of the key features of this dialog process is a faded mask that gets shown behind the dialog box.
Each of these dialog window controls is in a separate Partial View page.
Now, some view pages may use multiple dialog boxes, and therefore include multiple partial views in them - which as is would mean multiple instances of the "mask" element.
What I am trying to find a solution for is to only need to create one instance of a "mask" element regardless of the number of dialog partial views I include, and then the script in each partial dialog will have access to this element (so basically it just needs to be on the page somewhere)
The only real idea I have come up with so far is to add the "mask" element to the master page (or in the original view page) and this will mean it only gets added once. The problem here is that it will be added even when it is not needed (albeit one small single element)
I can live with this, but I would like to know if there is a better way to handle these kinds of scenarios?
A quick idea that came to mind is some kind of master page inheritance hierarchy, So I may have a DialogMasterPage that inherits from the standard current master page. How does that sound for an approach?
Thanks
To do something like this, where each module can register their need for a certain thing in the master page, you can use HttpContext to store a flag of whether you need to write the mask div, and just set that property in each partial. At the end of the master page, if the flag is set, you can then write the mask div if its set to true.
Obviously to make this cleaner you could wrap it all in an HtmlHelper extension or something.
My initial thought is for you to use something like jQuery UI where it handles the masking for you or if you are using something custom you can load the content for the dialog via ajax then show it in the single dialog on the master page.
Anyone can explain briefly about the [Inspectable] metadata tag. I read and could not understand in live docs.
Please help me when we are going to use the [Inspectable] metadata tag?
Thanks,
ravi
The tag is used with properties to provide code hints for that property and to specify the possible list of values that property can take while using it in mxml. Unlike [Bindable] metadata, this tag doesn't have much effect on the working of the code (other than specifying a default value) - this is used mainly to give directions to Flex Builder regarding how to deal with a particular property.
[Inspectable] metadata tag
Defines an attribute exposed to component users in the attribute hints and Tag inspector of Flex Builder. Also limits allowable values of the property.
For example, the verticalScrollPolicy property of the mx.core.Container class has the following [Inspectable] tag with it.
[Inspectable(category="General", enumeration="off,on,auto", defaultValue="auto")]
public function get verticalScrollPolicy():String
{
return _verticalScrollPolicy;
}
This tells Flex Builder that this property should appear in the 'General' tab (it is 'Common' in my FB) of the Flex Builder's property inspector (open an mxml file, go to the Windows menu and select Flex Properties to open the property inspector - towards the upper side of inspector tab, near its title, you will find buttons to switch to standard view, category view, and alphabetical view). This property can take one of the three values off, on, auto and if none is specified it takes auto as its default value.
I've never used this tag and I believe you too won't be using it much unless you are writing a Flex API to be used by a bigger audience than your colleagues (or if you are a perfectionist).
This tag is useful for when you write your own custom components. While it does not interact with the actual code you write (unlike the [Bindable] tag, mentioned above), it does give the Flexbuilder environment a way of allowing the user to set properties of your component using the UI Designer.
Therefore, the tag is useful if you want to:
Write components that are to be used by other people (make only the publicly accessible properties Inspect'able)
You've written a custom component that is used multiple times in your UI (maybe an extended slider). You then write some Inspect'able getter/setter methods as the public API to your component, and then implement these getter/setter methods to do data validation and implement the internal logic of your component.
You can find more information and examples here. Some good info on writing custom components (using the code behind methodology, which I prefer) can be found here.
Note: When creating exposed properties using [Inspectable], they don't seem to show up in the Flexbuilder Flex-Properties panel (not in Standard view anyway, use Category view or Alphabetical view, instead)
Note: You can find an alternative method of adding public properties to your custom components using MXLM, like this.