Community
Participate
Working Groups
HI, christian asked me to file a bug for this. I think about proing my existing app to riena. I have large investment done in some nice editors which I's like to reuse. I do not really have a clue how I would solve my navigation with riena, maybe I need some help there too :) I have a cross entity-type fulltext search like google. Single search text box, results of the query are currently displayed in a tableviewer. I guess that could be nodes in riena navigation terms, but I don't fully understand how the parameters work. I then would like to open an editor from the navigation node where riena shows its views. Is clear what I think of ? I enabled the editor area in the SubApplicationView (i guess) but it didnt show my editors. Also btw my views toolbar was not rendered correctly :( I also completely missed the views menu.
We have to think if and how editors would make sense in Riena "process oriented" navigation. Feel free to share your thoughts. I also wanted to point out that you can use Riena's Ridgets without having to use the Riena UI / Navigation. For example it is possible to use Ridgets within a regular RCP application, where you define perspectives and views and editors as usual (i.e. PerspectiveFactory / Perspective Extensions / subclassing ViewPart / EditorPart). You can examine the classes NavigationView / NavigationController / Perspective in the 'org.eclipse.riena.sample.app.client.rcpmail' demo project to see how.
Thomas can you please give us an example what you expect from an editor in Riena that you cannot already do in a view ? As Elias also pointed out you can use editors and ridgets if you dont use Rienas navigation concept but stay with the RCP navigation model. Is that helpful or what is the thing about editors ?
I think what I'd like is impossible. I would like to see editors in the same area where you put your views (open an editor from the navigation exact the same way as you have views) sad that you went for views only in your concept. If you think this is possible let me know otherwise I sadly don't go with riena navigation and you may close this bug.,
hi thomas, what we are trying to understand is what your anticipation is what would happen if you have an editor ? You still have a navigation tree on the left so clicking on there should have some effect. Currently we are showing views that are linked to each node. So try if possible to explain what you want to happen if you click on a node A (it has an editor linked) so that editor is opened, then you click on node B (with a linked view). Would that hide the editor or what should happen ? There is another bug for showing some content permanently in the workarea (thats what we call the part right next to the navigation). #270213 and there is another bug for people who want on a second screen to show a detached view that is open for a longer period or context #270212.
i would like to see the editor in the workarea but I guess this wont work or can one display an editor where elsewhere a view goes ?
ok so you are saying that you want to display an editor just like a view. Why would you like to call that an editor and not a view ? Is it just because you already have so many code that is implemented as editor that you like to reuse or is there some typical editor functionality that you like to get that views cant deliver ?
yes the main reason is that i have many complex (Form)editors
So let me have a look at this problem and I come back on this bugzilla in a few days.
cc'ing myself We're also interested in support for EditorParts in the WorkArea. Specifically, as in Thomas' case, we have some complex FormEditors (multipage) already coded and would like to be able to reuse them in our Riena app. As far as the use case that I'm thinking of, I would like to be able to create a submodule in a module group which would represent the editor input (ie - a file resource). Selecting that submodule/node in the navigation view would open the editor in the workarea. Many of our editors are read-only, so we don't worry about dirty states etc. However, for proper support/usability (for those who actual edit with their editors :) ) I would think that selecting a different node (ie - to display a different view/editor) while an editor is displayed should check the state of the editor (isDirty()) and prompt to save changes if required before switching the view.
