I am using a com.vaadin.flow.component.grid.Grid in my Vaadin 14 sample app. I have added an extra header row and introduced a toggle button for changing its visibility.
Unfortunately, this led me deep down to com.vaadin.flow.component.grid.ColumnLayer, which is not visible.
I have also considered dropping the header cell contents and re-adding them. However, this just leaves a full-height row behind. I have also thought about applying some CSS, but could not find a way to, without altering the official source code.
Can anyone help with a more appropriate solution than building my own Grid version (by forking the official implementation)? This feels like pretty common grid functionality to me...
To whom might be interested about this...
I have used the dirty workaround mentioned the link shared by Tatu Lund.
However, that only works for GridSingleSelectionModel.
For GridMultiSelectionModel, the underlying implementation is rather strange.
For example, I complemented the GridSingleSelectionModel workaround with setting visibility to false on the Un/Select All checkbox the GridMultiSelectionModel generates. This seems to have a listener on it and automatically hides the checkboxes generated by the GridMultiSelectionModel on each row. Which is similar to GridNoneSelectionModel, so unusable if you need to be able to select items.
Unfortunately, I have trusted that Vaadin 14 should be pretty mature by now, but as I explore it I find myself in the position to rather choose version 8, for instance.
It's not the first issue of this kind and, that being said, I am not sure I understand why is Vaadin releasing new major versions every so often, while they don't seem to be able to deliver a comprehensive, stable and reliable option to their adopters. Vaadin 8 is almost 5 years old, and it looks like no later version is even close to it.
I have a Spark list with a customItemRenderer that is taking a good 3 seconds to initialize with just 50 items.
I'm using Flex 4.5, my ItemRenderer is already very optimized, using as little nesting as possible, fxg and so on.
Is anyone having similar issues?
I've tried almost everything in the book bar going back to mx.
So the issue was due to the way that spark handles styling the issue is detailed here: http://bugs.adobe.com/jira/browse/SDK-29880 and can be sorted by monkey patching with: http://taytay.com/?p=169
Also removing global css selectors "*" helps.
Avoid HGroup and VGroup as much as possible, use absolute layout instead. I've had this same problem at that's fixed most of it for me.
1 hgroup + 1vgroup each three times = 6 automatic layouts PER ITEM. So in total you have 150 objects, WAY too much.
After applying the monkey patch mentioned by Pedro with only modest performance gains (I suppose we had fewer styles, or the performance was fixed in a more recent patch), I continued profiling the initialization of our List instances.
One thing I found is that Flex spends quite a lot of time in UIComponent's initializeAccessibility function, even though our application does not support accessibility in any way (whether applications ought to do that is an entirely different issue).
Merely adding -accessible=false to the compiler arguments cut time spent initializing a particularly heavy list by about a third! Not only that, the whole application in general feels snappier when windows are opened, controls are shown for the first time, etc. If you have no need of accessibility support, you might want to check this out - if you do, I'm sure something can be done to fix the abysmal performance of initializeAccessibility - simply through overriding it in your component implementations, or through even more monkey patching :-)
Are your item renderers checkboxes by any chance? A few folks have recently run into a bunch of performance issues with Spark in general.
http://blogs.adobe.com/aharui/2011/04/migratory-foul-performance-problems-migrating-from-flex-3-x-to-flex-4-x.html
Adobe has been notified, and apparently are working on it:
https://bugs.adobe.com/jira/browse/SDK-29451
I know there have been similar threads in the past but I can't seem to find a decent definitive answer / workaround for the problem I'm facing.
What I'm trying to do:
capture ALT+SHIFT+something keyboard events. Pretty straightforward, right?
Issue:
When pressing ALT+SHIFT doesn't seem to ever shoot an event. The only combination that seems to work with ALT is CTRL+ALT+something, as pointed out here.
Question:
really? I've read that the browser catches some of the keyboard events, but this happens with the basic flash player too - maybe that catches events too? Would love to know if there is a solution that doesn't involve messing with JS.
thank you!
The problem as you've said is that the browser captures some of the key combinations, and the underlying OS may catch others. From the research I've done, and read about on the bug on Adobe's bug base I filed on this, it can be made better if you do an Air app, but even then there are some of these combinations that are just eaten by the OS, so it never even comes NEAR your application.
We have a flex based UI whose functionality (eg: login, logout) needs to be tested periodically in IE 7. Manual testing takes a lot of time and hence we want to automate it.
EDIT: We dont have the source code of this app uder test so cannot use something like FlexUnit. Is there a way to automate this testing?
I have heard of FleXmonkey, but have read negative reviews of it and hence wary of trying it.
EDIT: source of negative review:
Automated testing of FLEX based applications
(Comment by Ryan H)
Please suggest if theres a way to go about it.
EDIT: An open-source solution is preferred.
Thank you.
You won't get very far in your development adventures if you avoid reviewing things just because you read negative reviews. ( Please provide a source for said negative reviews ). I've also read bad things about Flex and Flash Builder and the Flash Player. Yet, you still ended up using Flex?
That said, I strongly suggest checking out Flex Monkey.
RIATest is another option.
I believe you can also do this sort of testing with QTP. I couldn't find a specific source for QTP info, but there are a few links if you google.
http://www.learnqtp.com/does-quicktest-professional-support-flashadobe-flex-applications/
http://vishnuagrawal.blogspot.com/2009/04/flex-automation-testing-with-qtp.html
Without recompiling the source code, it is not possible to test Flex in all cases. Saucelabs IDE claims that it can test Flex without recompiling the code. You may check that.
I think FlexMonkey is pretty cool and worth judging on your own. Most of these tools use the same underlying automation framework provided by Adobe, and thus have many of the same pains and challenges. We've actually done a lot the last few months to make it easier to work with and have been working to provide more documentation on dealing with common challenges.
If you do have problem, you will find that our Forums are very active with questions and answers: http://www.gorillalogic.com/forum/7
-Jon Rose -
Gorilla Logic, Inc
Some Flex automation tools support testing of Flex applications without requiring to recompile it.
RIATest definitely supports it (called runtime loading) and if I am not wrong QTP does it as well. AFAIK there are no open source tools that support it.
Beware though that runtime loading is not for every application. If for example you are using custom html wrapper you cannot use it with runtime loading.
I currently do a lot of work in ActionScript 3.0, I also love to program in Java. Is JavaFX perfect for me? What is the general feeling on JavaFX, will it become a power house, or go down the same path as Java Applets? Could the designers I work with become comfortable with JavaFX to the same extent they are comfortable with ActionScript and JavaScript?
Just wanted to add my $.02... I've been working in JavaFX for the last 4 days on my first little side-project using it. As some background, I've been programming professionally for about 9 years, starting with C, and have been doing Java and C#/.NET for the last 6 yrs.
IMO, JavaFX its way more frustrating that it should be. Here are some gripes:
The syntax is just odd at times. It could easily be more like Java, since its JavaFX. But the syntax isn't an easy transition from Java.
The order of items in a .fx file actually matters, which means you run into stupid circular reference errors, and "oh you can't use this variable yet because it hasn't been initialized" problems that the compiler should handle with ease, but doesn't.
Random things just don't work. Actions/events on Swing controls don't always work, for example SwingSliderBar's onKeyPressed/released don't seem to be called.
Error handling is just bad. If an exception occurs that isn't handled, there is no real way to tell other than the Java console, and UI elements start to react funny. For example, make a SwingText box and bind its value to a variable. Now trying to edit the value in the text box will throw an exception because you cant edit the bound variable. However in the UI, the text box just starts having funny things happen. some characters only 1/2 paint, sometimes backspace does nothing, sometimes it deletes a character, sometimes you can press 2 keys ont eh keyboard like "1" and "2" and the text box will end up having "21" entered in it instead of "12", etc...
Although my absolute #1 problem with JavaFX development right now is Netbeans. It is pathetically bad at JFX. Can't debug, errors display wrong in the IDE (I've had it flag comments as errors!), the intellisence only works like 40% of the time, event he code templates preprogrammed in the IDE for drag & dropping controls aren't correct. I forget which one, but one of them drops a "&" at the end of the inserted code that is never valid and always has to be manually deleted... its just plain awful, and is unacceptable for a company like Sun.
Another gripe is general documentation. Its just lacking. Somehow the JavaFX API doesn't even come up as the #1 search result on google when searching for methods/classes. Tons of "examples" out on the web don't work any more as every version has major refactoring changes, and classes removed or renamed.
Overall, I give JFX a 4 out of 10. I want to like it, but JFX 1.1 just doesn't cut it... its definitely not what I would consider "production ready".
A resounding "meh".
When I looked at it a year ago, they had a one-way SVG to JavaFx conversion tool. Great, so you can author your visual content once, mark it up with a lot of behaviour, and then the next time you want to make it look good, then what?
If you take a look at this tutorial you can see what I mean. We're drawing stuff by dragging shapes from a palette into source code. OMGWTF. I am not showing that to my graphics department.
I hope I'm wrong about JavaFx, but I don't think they get it. Please, won't somebody at Sun give us a presentation layer that doesn't have its tentacles inextricably intertwined with code?
I left my last job to move from Java to .NET development.
There were a number of reasons for making the move, but the single biggest reason was that I was sick and tired of trying to build 1st class UI software with Java & Swing. It has been six years and I'm so glad I moved on. I see no reason to believe that Sun finally understands UI development with JavaFX.
I am convinced that Microsoft is finally in the process of giving us a platform to build rich interactive applications in the browser. I say that after having built commercially available software which was delivered as a Netscape Plugin 13 years ago, followed by ActiveX controls and Java Applets, and seeing all of these platforms fail to become ubiquitous in the enterprise for one reason or another.
I realize that Silverlight 2 is still lacking in depth and maturity, but Microsoft has shown me enough commitment at this point that I believe it will be the dominant RIA platform in a few short years - at least for projects which require a "real" programming language. I am sure Flash et al. is not going away anytime soon, but Flash is not appropriate for the kinds of software my company builds.
The icing on the cake for me is the fact that I will still be able to use Visual Studio, C# and a large percentage of my current code base (the core engine which is entirely separate from the UI). Of course, if you are coming from ActionScript, this would not help you.
One more important point is the fact that Silverlight and WPF share so much in common. Our plan is to share a large amount of implementation between Silverlight and WPF versions of our software. It is only a matter of time before WPF is the standard for Windows applications – I don’t know whether that is a couple of years or ten years, but it will clearly happen over time. Being able to target the most popular browsers / OS’s with Silverlight and Windows from the same code base is a tremendous advantage IMO.
If you know Java then moving to C# is a piece of cake. And unless you are using one of the nice (not free) Java IDEs, then even the free versions of Visual Studio will be an improvement over what you are used to. The hurdle will be learning the new way of doing things with XAML – but it’s some pretty cool stuff so you might actually enjoy it.
Although it appears fairly powerful in terms of capabilities, I'm kinda blah about JavaFX because of its structure and implementation. It seems like a really half-hearted attempt at getting into the Flash/Silverlight market. Too scripty.
I would argue in favor of going the Silverlight 2 route, but I'm primarily a C# developer so I'm a little biased there. If you don't like that route for whatever reason but still want a richer UX for your users, I'd suggest Flex; it seems much better organized than JavaFX to me.
Just my two cents on the subject.
If you know Java but want to do the stuff you thought was only feasible in Flash - then yes JavaFX would be good for you.
Without a doubt it's going to be much more easier to merge your Java knowledge with the design stuff.
And I believe the tooling will only get better which will make it simpler to use.
Unless you’re working on an internal app I would stay away from it. Users generally don’t want to have to deal with another program that accomplishes the same thing as Flash. I don’t think its install base is large enough yet to make it convenient for end users.
I've been developing Flash Applications with Flex for about 2 years now and I decided to give a try to JavaFX because we are constantly getting user complains that they cant use the applications from their IPhones (and I love Java).
That's one strike for Flash (no wide mobile support).
To be honest I was quite impressed with JavaFX (in a very bad way).
The documentation is incomplete.
The script is simply awful; its this weird hybrid between JSON and R with a feeling of a Java-deja-vu.
I spent the first 3 days painting polygons and making gradients with CODE... WTF!!
I tried to convince my graphic department to try it and they simply don't seam to grasp how the production suite is supposed to work, they keep complaining that Flex skinning is way easy and looks better in the end (Which is absolutely true).
The "CSS support" is simply a bad joke.
It generally feels like a mediocre attempt to offer an option for RIA frontend.
I can only think of a couple of good things about it:
It can be run from an IPhone / IPad and almost all mobile devices.
You have access to all the Java code you want which is great considering the limitations that ActionScript has (no overloading, no private constructors, etc). This is a great thing for us the programmers, but lets remember for a second that this is a frontend/presentation technology... that means that users will have to actually see the thing, so if it doesn't look good and have cool animations / effects they wont dig it.
The Script is way less verbose that MXML files are (with the cost of being unintelligible).
Talking about performance... Flash Player is this huge green blob that keeps growing and growing until no RAM is left compared to how JavaFX runs (JVM rocks! unfortunately this has nothing to do with the actual JavaFX API its just that the JVM... well it rocks!).
It has this cool feature where you can drag the applet outside the Web Browser.
In the end, Im happy I have an option to go mobile but this is light years way of the matureness that Flex/Flash has accomplished regarding RIA applications. The future of Flex/Flash as a wide distributed web technology is not clear (it may end up being used only for annoying banners and online games), no one wants to depend in a close technology as the Flash Player is, that's why the whole Web community is striving to get Flash out of the picture (HTML5 video support, No Flash Player for Apple devices, etc). So an attempt to have an open one is always welcomed, it's just that JavaFX feels like this incomplete rushed beta version of something that Sun felt obligated to come up with in a weekend during a bad hangover.
I Hope this is useful to someone (and offensive to someone at Sun/Oracle =p ).
I've spent the weekend 'playing with it. I see nothing useful in it. It's a iteration of swing / awt. I guess it will be nice for mobile devices but beyond that its nothing useful.
Ideally I'd like to use flash but find it painful to intergrate with a backend of any type.
Well, the syntax of both ActionScript and JavaFX seem to share a lot of similarities, so maybe "Yes".
I'm learning JavaFX script at the moment and I actually like it. But what I don't like, and is maybe it's biggest drawback, is it's awful documentation, which is often not up to date or incomplete.
I've been working on a JavaFX application for several months now. Personally, I love the language. They seemed to me to have made some very smart decisions in choosing the syntax and language constructs (I can bore you with a list if you'd like). I've been programming in it for a few months now and it seems like a very efficient and even enjoyable language to program in.
I think its best use right now is for desktop applications and/or applications deployed through webstart. On the desktop it has a rich set of features and can still make use of the other features of Swing and the rest of Java. From what I hear applets are still slow on some systems, and without Android support the mobile capabilities are non-features. The applet/mobile/TV/web support seems to me more like a bonus for desktop developers then as key features that would get you to use the technology.
So it really all depends on what you plan to use it for. If you are building desktop applications that you want to run on the Java VM that can make use of easy multimedia and rich ui controls, then I think there are good reasons to look at the language. WebStart has improved quite a bit and makes for a nice deployment tool. If you are looking to build web applications, then it might be interesting, but for now I'd say HTML5/ajax are more relevant (you might want to look at ZK in this case). However even with HTML5 ajax has its limitations, and if you find yourself running into them then JavaFX may offer you options. For mobile platforms it won't be relevant until there is stable Android support - in that case I'd just stick with the Android platform itself for now.