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.
Related
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.
I'm new to the fedext-universe. By now, I've created a set of content elements, and they work fine.
There is one drawback though: One set of content elements has some fields in common, and these fields are rather complicated. Usually, I'd move their definition to a partial, but that isn't possible in flux forms. The beginners guide states
Flux templates can use Layouts and
Partials - but a Flux form cannot
be split into Partial templates.
Is there any way to avoid redefining these fields over and over again? Among other things, I've tried to use the <vhs:render.inline> viewhelper along with a custom viewhelper, returning the fluid-definition of the fields, but I can't get that to work.
Flux 7.0 will bring the option to place fields and sheets into Partial templates - if you are currently in a development project, I recommend trying it out from the development branches on Github:
https://github.com/FluidTYPO3/flux/tree/development
Flux 7.0 also will bring the option to create PHP classes which for example create ready-made sheets with a bunch of fields - such a class would be ideal to reuse, simply requiring one PHP class and one Fluid ViewHelper. Such an approach would be more efficient when your forms are rendered, but of course is much more technically demanding than a Partial template.
EDIT: though not yet documented, creating custom sheets involves two simple steps: 1) create a subclass of FluidTYPO3\Flux\Form\Container\Sheet and a subclass of FluidTYPO3\Flux\ViewHelpers\Form\SheetViewHelper - then include your namespace in the template, use your own ViewHelper instead of a flux:form.sheet (and add additional fields if you need them) and then inside the Sheet object, use the $this->createField() method from within object initialization, to automatically add any number of fields with predefined names, labels etc.
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
Suppose I have a <String,String> map defined in my i18n .properties files, e.g.:
userGroupMap = 0, 1, 2, 3
0=Factory
1=Administrators
2=Superusers
3=Operators
The dev guide explains that introducing a corresponding Map<String,String> userGroupMap() method in MyConstants implements Constants interface will result in calls such as MyConstants.userGroupMap().get("1") returning the localized "Administrators". So far so good.
What about UiBinder? How do I use one of the mapped values in a UiBinder template? Is there a syntax I'm missing, e.g. <ui:msg key="userGroupMap:1">Administrators</ui:msg> (doesn't actually work)?
One way you could do this would be a non-xml solution, but you could use a #UiFactory to help with the creation of the specific fields or labels that you need I18N'd. But to me, this particular problems seems like it begs the solution below, since you seem to be looking to decouple your widgets from your screen or panel layouts.
I struggled with this, and for my implementation, I ended up making core widgets with UiBinder backing for their internals(for instance a label and a text field with a help button), and then passing in a 'fieldKey' that was used as a prepender for all the I18N keys in the various maps.
For instance, for the PartNumber field, I had a key in the following maps: labelTexts(), helpTexts(), tooltipTexts(), defaultFieldValues(). Then in the constructor for that widget, I would pass in the string key 'partNumber', and that would be used to build up all the keys needed, so I would call labelTexts().get('partNumberLabelText'), helpTexts().get('partNumberHelpText'), etc.
I didn't want to do this directly in UiBinder, since I wanted the widget key to map back to it's display information, so I could create a widget with as little input information as possible, in many cases just the key and then the widget (provided it was configured in the I18N setup correctly) would just populate everything from the maps based on that.
From a design standpoint, for me it didn't make sense to have separate UiBinders for the screen sets, they were composited from objects that defined the screen layout and relation of all the widgets (meaning that you could define screen content at runtime).
I'm just going through the GWT Tutorial and one point which just don't understand is when and why to use dependent secondary styles. If I define a style in the .css stylesheet, and use the addStyleName method it seems to have the same effect.
E.g. applying a secondary dependent style to a button or applying the it as a non-dependant style seems to yield the exact same results.
Basically the dependent name is more general, since it's calculated at runtime. You can add a dependent name of "highlighted" to any Widget without knowing what it is, and GWT will come up with the appropriate css class name for you. You don't have to hard code button-highlighted, select-highlighted, mycustomthing-highlighted in GWT this way (you do still need to create them all in your css code).