I have an Editor screen built in legacy platform version 6 named “BidInvitePeriodicEdit” with a composition table from where the screen calls the Editor screen “BidInvitePeriodicVendorEdit” which is created in platform V7. I am getting the following error which create button is clicked.
This new editor screen is not registered as the new platform version created screen doesn’t require registering the screen in web-screen.xml. If I register it manually as follows:
java.lang.IllegalArgumentException: Unable to create screen erp$BidInvitePeriodicVendor.edit with type FRAGMENT
at com.haulmont.cuba.web.sys.WebScreens.createScreen(WebScreens.java:177)
at com.haulmont.cuba.web.sys.WebScreens.openEditor(WebScreens.java:1193)
at com.haulmont.cuba.gui.components.HasWindowManager.openEditor(HasWindowManager.java:132)
at com.haulmont.cuba.gui.components.actions.CreateAction.internalOpenEditor(CreateAction.java:303)
at com.haulmont.cuba.gui.components.actions.CreateAction.actionPerform(CreateAction.java:256)
at com.haulmont.cuba.web.gui.components.WebButton.buttonClicked(WebButton.java:62)
at com.haulmont.cuba.web.widgets.CubaButton.fireClick(CubaButton.java:76)
at com.vaadin.ui.Button$1.click(Button.java:57)
at sun.reflect.GeneratedMethodAccessor424.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at com.vaadin.server.ServerRpcManager.applyInvocation(ServerRpcManager.java:153)
at com.vaadin.server.ServerRpcManager.applyInvocation(ServerRpcManager.java:115)
at com.vaadin.server.communication.ServerRpcHandler.handleInvocation(ServerRpcHandler.java:431)
at com.vaadin.server.communication.ServerRpcHandler.handleInvocations(ServerRpcHandler.java:396)
at com.vaadin.server.communication.ServerRpcHandler.handleRpc(ServerRpcHandler.java:260)
at com.vaadin.server.communication.UidlRequestHandler.synchronizedHandleRequest(UidlRequestHandler.java:82)
at com.vaadin.server.SynchronizedRequestHandler.handleRequest(SynchronizedRequestHandler.java:40)
at com.vaadin.server.VaadinService.handleRequest(VaadinService.java:1577)
at com.vaadin.server.VaadinServlet.service(VaadinServlet.java:425)
at com.haulmont.cuba.web.sys.CubaApplicationServlet.serviceAppRequest(CubaApplicationServlet.java:329)
at com.haulmont.cuba.web.sys.CubaApplicationServlet.service(CubaApplicationServlet.java:215)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:741)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:231)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:53)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
at org.springframework.web.filter.CompositeFilter$VirtualFilterChain.doFilter(CompositeFilter.java:107)
at org.springframework.web.filter.CompositeFilter.doFilter(CompositeFilter.java:73)
at com.haulmont.cuba.web.sys.CubaHttpFilter.doFilter(CubaHttpFilter.java:108)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:199)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:96)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:490)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:139)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:92)
at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:668)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:74)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:343)
at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:408)
at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)
at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:834)
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1417)
at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:748)
I understand screens developed from old or new platform version are useable from one another based on the comments from @knstvkhere unless I misunderstood.
Excuse me for returning to this, but I think I’m loosing my time on this same subject
What you mean is that all entity editors on a compostion in a legacy screen (like the details of a master-detail legacy screen, based on nested datasource) must use the old API and NOT the new one, right?
Must needed clarification on the clarification, Thanks
And in my opinion defeats any reason for upgrading or importing a legacy 6.10 project into 7.0.
My reason was precisely to redo the editor screens with the new Form component, far from perfect but a lot better than FieldGroup.
Oh, and I’ve just tried 7.1 Snapshot and that seems to be the complete destruction of my legacy AppMainWindows.
Don’t really understand comments by KK as pointed by mortozakhan about the “entire codebase working” and “creating new screens and being able to invoke them from old screens”.
Well that’s not true, thanks for clarifying.
Hi @pedro.armelim
The V7.1 platform’s default menu is a side Menu but wondering why any existing screen should be destructed! I shall wait for the release as we will have some instructions from the CUBA team how to move to the new version.
With regards to Legacy Vs new platform/Studio. I also personally see a lot of features lost and it’s been difficult and sometimes less productive compared to legacy version. Some of the old features are planned to be made available but still some miles to go which is a kind of counter-productive moving to the new version but I have no way to go back and do not want to as it has been quite some time and we need to move ahead with new versions!
The project I am working is a large one, and it’s not so quick to migrate all of the code base to V7 for me. As a result I am using existing code base / screens developed in legacy system and new screens in new version and they are working. What doesn’t work is if you want to call an Editor screen from respective Browser screen where the editor screen is created in new version and browser screen is in old version. When I have recreated screens, i have done for both as a pair.
New screens can be invoked from old code and old screens can be invoked from new API. The only limitation is @Composition editing, since it requires data sources from both sides with the same API level.
Oh, and I’ve just tried 7.1 Snapshot and that seems to be the complete destruction of my legacy AppMainWindows.
This version is in active development right now, so it is a little bit early to use 7.1 in projects.
Precisely guided by what I red and is mentioned in these forums I migrated a “small” project, 5 months later from your platform 7.0 launching. And most things work, for example new API editor screens with old base entity browsers. With lots of work on conversion as pointed out by @mortozakhan. The idea, as I said was to redo the editors with the Form component, the only new practical thing and improvement I’ve seen in your platform for ages. And I’ve put some 3/4 days of work on the project before bumping into your “limitation”. That’s a quite serious limitation, most of my editors are also used to edit compositions. And I can’t redo things by the pairs (basically the whole thing) as @mortozakhan, simply don’t have the time. Then just to try and guess what I have coming to my migrated 7.06 project I tried your 7.1 snapshot. And, well, I guess that wouldl be some more very lousy days on Cuba.
I have everything on my AppMainWindows, charts, javascript components, Vaadin components, entity browsers and actions. I used one of your earlier samples not the dashboard add-on witch I haven´t tried.
Things don’t get deprecated anymore they simply vanish. My main windows refresh mechanism (some forum hacking, as usual not documented) was by overriding setWorkArea in AbstractMainWindow. That seems to be no more in 7.1, gone. Then commenting all that doesn´t compile I’m presented with a blank main Window with a side menu, not nice.
Reading again what was said by @knstvk I must say that it all adds to a very strange notion of version coexistence and compatibility.
While I certainly understand your frustration, I thought I might make a couple of points:
From my own experience, you can take a version 6x code base, recompile and run onto version 7+ with minimal changes; if you leave stuff as it is then you’re pretty much good to go. If you decide use the new data containers, for example, then I would certainly expect a certain amount of work to upgrade your code. When someone says they’re making something backward compatible, I assume that means I can take what exists and make it run on the new framework without any work, but that doesn’t necessarily mean I can use the new features without some work on my part.
However, I would expect is that stuff I could do in the old version should be carried to the new version. This isn’t the case with linking data sources on a page. If I want to use version 7 to take advantage of multilevel composition, I can’t because I lose the huge advantage of linking data sources without having to write a wodge of code for each link. I know that this will be added at some undetermined date in the future; I just happen to think it should have been there on day 1. So in that regard, I would agree that this is something that has ‘vanished’.
I disagree that the new form object is the only improvement.
They have decoupled the screens from the dialogs and notifications. They have also paramaterised all of the screen components which means less time chasing down runtime errors. We also have type-checking when passing data parameters to screens. They have revamped the event model so that we can subscribe to events, rather than relying on a rather fragile subclassing model. And these are just the improvements that I’ve noticed.
So rather than seeing huge whizz-bang changes, I think we’re looking at clean-up of the framework so that it’s much easier for newcomers to get to grips with, and much easier to extend in the future.
I’m in two minds about Cuba Studio as it hasn’t reached the level of stability of the old Studio as yet. I’ve also noticed (though I probably shouldn’t be surprised) that I can’t run both the Cuba Studio plugin and the Vaadin Designer plugin in IntelliJ IDEA at the same time.
