Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 336816 - Easier access of navigation arguments
Summary: Easier access of navigation arguments
Status: NEW
Alias: None
Product: Riena
Classification: RT
Component: navigation (show other bugs)
Version: 2.0.0   Edit
Hardware: PC Windows 7
: P3 enhancement (vote)
Target Milestone: ---   Edit
Assignee: Project Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-02-10 08:20 EST by Stephan Mann CLA
Modified: 2011-05-30 08:34 EDT (History)
1 user (show)

See Also:


Attachments
convenience methods for navigation (3.79 KB, patch)
2011-02-10 08:21 EST, Stephan Mann CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Stephan Mann CLA 2011-02-10 08:20:48 EST
As navigation is an important part in Riena, using it could be easier. Many controllers need to access navigation arguments or their parameters or need to navigate to another controller. During a customer project we have come up with 5 convenience methods, that make life easier and prevent the developer from writing the same code over and over again. 

The attached patch adds these methods to SubModuleController. I'm not sure whether they'd better be moved to NavigationNode.
Comment 1 Stephan Mann CLA 2011-02-10 08:21:43 EST
Created attachment 188680 [details]
convenience methods for navigation
Comment 2 Christian Campo CLA 2011-05-30 02:58:41 EDT
how about a declarative approach ?

@RequiresNavigationParameter(type=Customer.class)
public void configureRidgets(Customer customer) {
}
Comment 3 Stephan Mann CLA 2011-05-30 07:39:48 EDT
The declarative approach would be preferable, but IMHO not at the cost of an impaired flexibility. So multiple annotations would be required to differentiate between required and optional navigation parameters.
Comment 4 Christian Campo CLA 2011-05-30 08:34:01 EDT
(In reply to comment #3)
> The declarative approach would be preferable, but IMHO not at the cost of an
> impaired flexibility. So multiple annotations would be required to
> differentiate between required and optional navigation parameters.

I totally agree. I was also thinking of multiple annotations. (just too lazy to actually write them down :-) )