While I have this component in another package (called
HComponents ), I’ve re-packaged them as single components. They are also compatible with a current Vaadin 6.2-nighty. HComponents will be deprecated.
The component handles a oft-requested feature of the server side of Vaadin being able to recognize the changes in a TextField’s value
as they are being typed . The SuperImmediateTextField fixes this.
While a picture tells more than a thousand words, this
video tells more than a few handful of pictures.
This is excellent. I would actually have a need for two of your components (SuperImmediateTextField and Refresher) in my project (which I originally derived from AdressBook and HbnContainer).
I have not yet ventured in the client-side of things, and would need a pointer (RTFM is fine) on how to proceed to integrate the components – the whole topic about packaging widgetsets has me confused.
Basically you no longer need to worry too much about widgetsets, you just drop in some jars and press the compile button in Eclipse, and be done with it
Currently these are only available with 6.2 nightlies and the experimental Eclipse plugin version.
You are not the only one who thinks so. And this is the exact reason why Vaadin 6.2 will make packaging of widgetsets automatic ;) It will still take several weeks before 6.2 will be released, but if you are adventurous, you can try 6.2 nightly series out as Jouni explained above. (Please do, all feedback before release is really welcome).
Ok, I bit the bullet and checked out SuperImmediateComponent from the incubator.
I have a few questions.
a) I copied the source directories to my application. Magically the plugin prompted me to recompile my widgetset. How is this integrated with the Eclipse build process (which doesn’t prompt) and when exactly does one get prompted ? I figured out that there is a button on the toolbar to rebuild the widgetset
b) I had to add a line for the widget set in the web.xml directory. Why is this necessary – at one line per widget the web.xml will grow obese and this error-prone. Also seems redundant since what I added is verbatim the name of a directory underneath VAADIN/widgetset – why doesn’t the application just go read the directory names ?
c) What is the envisioned mechanism for packaging a component ? Will we put VAADIN/widgetset inside a jar along with the server side and the plugin will pull it out ?
More excellent work from the team, I’m this much closer to creating my first widget !
d) After successfully bruteforcing the text field, I decided to push my luck and integrate Refresher. So I copied the source files. Then something weird happened. The compile widgetset stopped recognizing my project (in fact all my Vaadin projects). So I created a new one from scratch, and copied the four folders (two for superimmediate, two for refresher). But no matter what, the plugin only sees one of the two components. What is the proper way to have two components in the “new style” ?
e) What is the plugin looking at to determine it is inside a Vaadin project. I looked at the files in .settings, and fail to see anything broken in the projects it no longer recognizes.
Sorry for the late catch-up, I forgot to subscribe to this thread. Apparently I haven’t packaged this (and the two other components) quite as it should be. These are only the sources. With 6.2, you should only need to drop in a provided JAR into your classpath, and you’ve got a new component.
I haven’t packaged these components into a single JAR yet, but I will do this as soon as I can (probably when I get back to my home computer, where I have my projects set up). I’ll drop in a note once I get that done. You can expect the JAR to be present in the project’s incubator directory.
I tried to use your supercool superImmediate Textfield and I didn´t figured out how I use and compile it with a maven managed Project. I already searched your post but I just don´t get it.
Can you please give me a step-by-step example or just a link to it?
Hi. The SITF isn’t, unfortunately, available as a maven dependency (or what it’s called, I’ve never used Maven myself), so you need to download the Jar and compile it yourself. So this should not have anything to do with Maven… You get
the jar from Directory, and compiling the widgets is easiest done with Vaadin’s
Eclipse plugin
I successfully compiled the widgetset with SuperImmediateTextField and it’s working as it should, like a super immediate textfield. But my problem is that when I try to use inherited methods (from TextField-class) setSecret() or setVisible(), nothing happens - setEnable() works although.
Have i misunderstood something? is this how it suppose to be working?
SuperImmediateTextField is downloaded from Vaadin Add-ons and version is 1.0.
Oh, right that… I might’ve been to hasty in promoting it to 1.0, since it indeed does inherit TextField, but is not 100% feature compatible. Indeed, setSecret() will not work, and probably neither will using it as a multi-line text input (setRows(), setColumns()) , since those are flat-out not implemented. While I’m sorry you stumbled upon this, I’m thankful of you notifying me. I’ll put a notice up on the Directory about this.
setVisible() should work, however, since that ought to be handled by Vaadin, and is rarely implemented on a per-component basis. I might take a look at that, see what’s failling. But since my time is pretty limited, I’m not sure when I have the time to take a look, and maybe fix that.
The way how the secret and multirow modes are implemented in the client-side is a bit annoying for TextField extensions. If I’m not wrong, the only solution seems to be to have separate server-side classes for the modes. Oh well.
I’d like the SITF to be 100% feature complete with TextField, too. But, frankly, the best way would be to get the normal TextField rigged with a super-immediate functionality. The original SITF was intended as just a hack, since there were people asking for such a feature, but it never got implemented in Vaadin.
The problem with having SuperImmediateTextField separately is that the added value to TextField is effectively a ValueChangeEvent on each keypress. Bearing that in mind, forking the whole functionality of TextField into a component of its own is not a good practice. The chances of me implementing secret and multiline functions are slim, exactly for the reasons Marko gave above.
I’d suggest everyone interested to comment on, and/or add your emails to the cc-field for, the ticket
#2387 :
setSuperImmediate() for TextFields
?