Followed several tutorials and have added custom classes in the formats section of the tinyMCE. The classes used are being appended and not replaced as I had intended. Is there a way to have them overwrite the existing style if there is one instead of adding to the class tag?
My use case is this: The user select a piece of text and select a class from the formats dropdown I have added. They dont like the color of the link and decide to change it by going back up to the formats tab and selecting a different value. Behind the scenes, TinyMCe replaces the class. I realize I could use the styles key in the json array, but that would produce inline-styles, which I'd like to avoid.
Thanks!
Maybe use exact: true for your style?
https://www.tiny.cloud/docs/configure/content-formatting/#exact
fixed the issue by using inline css rather than using the classes
Related
I have a partstack I want to reuse in a different fragment. It looks like I can import the part stack in one fragment, so I did this.
Then under my Part Sash Container, I add a PlaceHolder element and select this imported Part in the "reference" section.
On both plugins, I have org.eclipse.e4.workbench.model extended.
And yet, nothing shows up.
I also tried to simplify it by just importing one Part. This also does not work.
I know I can create the entire structure and assign new IDs and reference the class files directly, but I don't think that is the correct way to accomplish this. What am I missing?
You put the element you want to share in the 'Shared Elements' section of the 'Trimmed Window' definition.
You then put 'Placeholder' entries in all the Perspectives that want to use the shared element.
Whenever a part of a language label needs to be somehow highlighted, what is considered as best practice here?
I'm usually trying to avoid html tags in language labels as far as possible by splitting label into a parts and wrapping into corresponding tags in Fluid.
In worst case label is wrapped with CDATA:
<trans-unit id="my.label">
<source><![CDATA[Here comes a <strong>bold text</strong> and then <em>italic</em> and now <span class="fancy">fancy styled</span> stop]]></source>
</trans-unit>
But this mixes content and presentation, which can bring pain afterwards, when CSS is refactored and some classes are renamed.
Another solution, coming into my mind, is to move all the texts, that may contain html tags, out of XLF to either plugin's FlexForm RTE field or some configuration record with RTE fields. But it also looks rather like hack.
How do you solve such an issue usually?
For me there are some possible options, depending on the kind of text.
1.) Avoid HTML as much as possible
2.) If this HTML is wrapped around any arguments, move the HTML out and use it as argument for the <f:translate /> ViewHelper.
3.) Sometimes it is hard to use arguments as the translation is just different and I then use different partials/sections for the different languages and don't use any language file.
4.) I use the CDATA approach.
An addition to Georg Ringer's answer (whose point 1 is definitely the way to go, if at all possible):
5.) Use what XLIFF offers. XLIFF 1.2 has elements to mark tags inside translatable content - to be precise, it has too many such elements. One possible representation of your example would be
<trans-unit id="my.label">
<source>Here comes a <bpt id="1"><strong></bpt>bold text<ept id="1"></strong></ept> and then <bpt id="2"><em></bpt>italic<ept id="2"></em></ept> and now <bpt id="3"><span class="fancy"></bpt>fancy styled<ept id="3"><span></ept> stop</source>
</trans-unit>
This looks messy in code, but it has the advantage that an XLIFF aware translation editor will present this to your translators in a way that is easy for them to work with, like this:
.
The translator will be able to move these tags if the text order needs to be changed in the target language, and they can delete these purple tags in whole if they don't make sense in the target language: for example some complex Chinese characters look awful in bold face. They will not be able to delete parts of tags either.
One possible solution could be the use of parameters in the translation strings. Those parameters could be filled with translated strings which are wrapped in tags (by TS or fluid). This might result in a very complex translation handling as the strings are broken down to multiple strings (which might partially loose context).
Another solution could be the use of markers (like ###B### for <b>and ###_B### for </b>) for the tags which are replaced at the end (and which could vary for different devices). This also is complex and needs a good configuration and invents something like a further markup.
What would be the best approach to implement a form with a variable number of text fields? I'm thinking something like this:
textField1 (removeButton)
textField2 (removeButton)
textField3 (removeButton)
addNewTextFieldButton
I would like this to bind to a list of strings.
I achieved this with an editable grid with a single column and buttons to add/delete rows.
This component is very well integrated with GWT Editor framework so you can bind your grid to a list of objects using a ListStoreEditor
The best approach would be to use the GWT Editor framework. GXT's fields are very well integrated with the Editor framework.
Here is a very rough example of how you might approach this problem.
You would start by creating one Editor for the thing you are wanting to bind to. In your case, I think a composite which contains a TextField (which is bound to the string) and a button. The button won't actually bind to anything, but you will provide a way for something which uses this class to register a SelectHandler against it. Let's call this editor SubEditor.
Once you create a UI component which is designed to bind to one string, you will next create a ListEditor<String, SubEditor> which will bind to a List<String> which will compose a view, consisting of one SubEditor per each String in the bound list.
You don't really need to create the SubEditor, as you could construct something as simple as what you want within your ListEditor's EditorSource class (read through the tutorials on ListEditors).
Again, I want to emphasize the this is a ROUGH example on how to get started. I hope there is enough information here for you to fill in the pieces.
The following SO question has helped me out a lot:
Using GWT Editors with a complex usecase
I want to make a table of data in a UiBinder. I need programmatic access so I can add data at runtime, but I'd like my designer to have access to header names, column styles, etc, in the ui.xml file.
Is there a solution that meets these needs? A Grid perfectly satisfies my programmatic access, but I don't see a way to specify rows or cells in a Grid from the ui.xml.
I'd let the designers change the style via CSS files: Either include those in your host page, or use CssResource in a ClientBundle.
The header names etc. can be provided e. g. by properties files via GWT's internationalization Constants (even if you only want to support one language).
If you want to go one step further, and let the designer specify, which columns to show, and in which order, then it might be a good idea to create your own widget. Maybe the CricketScores example serves as a good starting point on how to use an XML attribute to specify the columns from your ui.xml.
I want to highlight some parts of the reports i'm generating for display.
I don't want to change the report definition. I want to highlight the output at runtime.
But the JRViewer i'm using doesn't really have much of an API.
And manipulating the JasperPrint object with setForecolor/setBackcolor before displaying it, didn't seem to change the output.
Any ideas? Or do i have to overload/reimplement the viewer? Wouldn't be much of a problem since it's open source, but i'd like to prevent reinventing the wheel.
Looks like i have to answer my questions myself... again.
I overloaded the JRViewer class (actually copied the code of JRViewer because none of the interesting panels were accessible) and added some highlighting methods to do the following:
Template based JasperPrint data uses - like the name suggests - templates. Meaning the text objects don't have a style of their own, they use their template's style.
That is the reason why setForecolor didn't do anything - the JRTemplatePrintElement implementation is plain empty.
But if i would set the highlight on the text template i would end up with a full column of highlighted texts, since they share the template instance.
Instead i create a new template as a copy of the original with highlighting and use that in the highlighted print elements. Btw, those jasper elements could really use a clone() method.
Feels like a hack, but i don't see a better way.
UPDATE:
However this has a nasty sideeffect for file based (virtualized) reports.
These apparently save any changes you make to the elements while you walk the pages.
If however the viewer in the meantime causes the virtualizer to discard the elements you reference (for example by flipping pages), your further changes won't be saved...
So that made me reconsider and now i'm just drawing my highlighting on top of the Graphics object painted by Jasper's PageRenderer.
Much simpler and cleaner. Only highlighting the background won't work this way.