Is there a DoubleField or LongField Vaadin 7? I see a TextField and PasswordField, so it sort of shocked me when I did not see fields for numeric types. This seems so standard, especially since GWT has such fields under the hood, that I feel like I am missing something.
Also, there are some numeric field add-ons, but most of them say they don't support Vaadin 7, which leads me to believe there is some standard way to do it in Vaadin 7 already. Am I missing something?
I couldn't find a way either but I created my own with a custom TextChangeListener. Basically you override the method textChange(TextChangeEvent event) to check if the value is valid. If it's not valid then you delete it. Just be careful to adjust the cursor appropriately. I created a listener for integers (with max/mins), one for doubles, percentages, etc. Basically any kind of number validation you need. The tricky part is managing the cursor position. I wish I had some sample code to show you but I don't have it available on my current computer, but at least this should give you a running start.
Related
Can anyone actually explain, in layman's terms, what is a real-world use case for the set operation's options?
While I fully understand what set with merge does, as well as merge beeing a boolean and mergeFields being an array of fieldPaths, I cannot think of cases in which mergeFields might be of any use.
I also understand the fact that mergeFields basically acts like a mask for the object passed to the set operation, but I still cannot think of how is it so useful that it actually got implemented within the SDK.
Can someone shed some light?
After looking through the documentation, there seem to be two reasons why you might want to use one vs the other:
mergeFieldPaths/mergeFields trigger an error when passing in field values that don't currently exist on the document while merge will add in those fields if they don't exist. The error is good for safety purposes if you're concerned about typos/writing to incorrect field paths.
This one is just a guess, but the documentation indicates mergeFieldPaths/mergeFields ignores AND leaves fields untouched while merge ONLY leaves other fields untouched. It's possible there's some performance advantage to using mergeFieldPaths/mergeFields esp for documents with a ton of fields. The difference might be direct access vs still needing to look at unspecified fields to identify the matches in some way.
SetOptions Reference
This is a really basic design question, but I can't seem to find an answer. I'll use a really simple example, but my concern is for cases where the model-level calculations, "2+2" in this example, become complex.
Let's say I'm designing an application to run in Zope or Plone; its job is to add two numbers. Dexterity lets me easily create a content type with fields addend1 and addend2, and will generate add, edit, display forms for me. I could modify the display form to also present a field named "sum," but "sum" is a result of extensive calculation in my model, and I don't want to present it in the "add" or "edit" forms because I don't need that as input, just as a result of calculation. I don't want to calculate it in my view, because it's expensive, I'd like to reuse it after initially calculating it, and I don't want my "view" to need any knowledge of how I do my calculations anyway.
So what is the proper "zca"ish approach for doing model-work that has nothing whatsoever to do with presentation of results? Do I create an interface like ISum and create an adapter that converts my content type to one including a sum, then do a view for the ISum interface? If not that, what? Searching PP4D and the Zope 3 Developers Handbook hasn't helped.
Thanks in advance for any insights.
Use events; you can register event handlers for when your content type is added, or edited, and you set the value on the object whenever these events trigger your handler.
Let's say I'm creating some app documentation. In creating a content type for functions, I have a text field for name, a box for a general description, and a couple other basic things. Now I need something for storing arguments to the function. Ideally, I'd like to input these as key-value pairs, or just two related fields, which can then be repeated as many times as needed for the given function. But I can't find any way to accomplish this.
The closest I've gotten is an abandonded field multigroup module that says to wait for CCK3, which hasn't even produced an alpha yet as far as I can tell and whose project page makes no obvious mention of this multi-group functionality. I also checked the CCK issue queue and don't think I saw it in there, either.
Is there a current viable way of doing this I'm not seeing? Viable includes "you're thinking of this the wrong way and do X instead." I've considered using a "Long text and summary" field, but that smells hackish and I don't know if I'd be setting myself up for side-effects. I'm new to Drupal.
There is the http://drupal.org/project/field_collection module but it's not yet ready. Right now you would need to implement your entity alas to do this :( not easy.
Not sure how well it would work, because it currently does a bit more (eg, forces to group pairs into categories and the keys need to be predefined) but you might want to have a look at http://drupal.org/project/properties.
You could create a these key-value fields on their own: create 2 regular fields that that can be added as often as needed.
So you have a x fields for the keys and x for the values. If this is only for you or other people it might work OK but usability wise, it's very ugly.
If you need to extract the fields from the function, to display it properly in a page template, you should propably use a different approach. Write the function with its arguemnts in a CCK field and in the template extract them as needed. The arguments are always (depending on language) in () and the different arguments are seperated by , so splitting them would by pretty easy.
What is the best starting point for a Qt4 widget for entering Latitude/Longitude in DD:MM:SS format (degrees, minutes, seconds)? Customize a QLineEdit? A series of spin boxes?
There are some variants:
QLineEdit with Validator - wasn't good enough for us, we couldn't achieve usable editing and proper view (with ', '' and degree symbols in place and ability to forbid incorrect values and still allow semi-correct states, and the target behaviour is not to mark errors and force user to fix them, but to allow user to enter only valid values).
Three spin edits in a line with the proper symbols between them grouped as a single widget and some code to move keyboard input from one no next when needed etc. Looks good enough in some cases, and you can find the variant of realization in the famous Marble project.
Still, my boss said that this approach is almost as ugly as first, so here is another approach: subclass QAbstractSpinBox, as Trolltech did in their QDateTimeEditor. In fact, behaviour of such a widget is near similar to one, implemented in QDateTimeEditor.
I, myself didn't do it yet, cause of task priorities, but will have to do.
I would use a QValidator, attaching it to a QLineEdit using QLineEdit::setValidator().
You'll need to subclass so you can implement the validate() function and possibly the fixup() function for your particular case, since the two validators included with Qt only cover integers and doubles.
It's a bit friendlier, in my opinion, to provide a single input box for this rather than three separate spin boxes (which could look cluttered and isn't as nice to type in).
[Edit: One other alternative is to set a "validation input mask" on your QLineEdit using QLineEdit::setInputMask(). You might want a line edit with symbols already in place and placeholders for other characters, for example, and this approach will give you something similar to that. The QtDemo app has an example of this which you can check out by choosing Widgets->Line Edits (Widgets is on the second page).]
A short discription of the application I'm developing is: It's a WinForms app, where the UI is databinded to some classes that implement INotifyPropertyChanged. That classes are updated by a background thread, and we want to allow the user to see what has been changed.
The current solution in short: every setter of a property is checking if the new values is different than the current one. In the class I'm holding a flags-enum, where every bit represents one of the properties. So if the value changes, the corresponding bit is set. Additionally there is a timer ticking every 2 secs, that takes back that bit after a while.
First thing I would like to achieve is to get ride of the mess in the property setters, and to have the logic encaplused somewhere. Another reason is that me might run out of bits within the enum, etc etc...
This solution isn't ideal, as it makes it necessary to touch every setter, and maintain an enum property, so I would like to replace this solution with a "better" one (whatever this really means).
I'm wondering if and how somebody else solved that problem already?
tia
Martin
You need to raise a PropertyChanged event when when the value is changed. See for example MSDN