TabStrips and required InputFields

[alejandro_bindi]

Hello,

I'm trying to solve this requirement: Having a tabstrip with a number of tabs, each of which will have some of it's inputfields defined as required, I should not let the user leave the current tab until all of the required fields are entered (another custom validations could also need to stop the tab changing)

After setting the SelectionChangeBehaviour as Manual I'm trying two different approaches here, both with some problems:

Alternative A) at first I thought of having a main view which held the tabstrip, and a viewcontaineruielement inside each tab. Then, after embedding a view in each of those viewcontainers, each embedded view WDDOBEFOREACTION method checked if it was inside the selected tab (relying on naming conventions, since there's no direct relation between the view and the tab because of the viewcontainer) and if so, triggered the method cl_wd_dynamic_tool=>check_mandatory_attr_on_view. The resulting messages where evaluated and there was a "required_ok" flag setting. Finally, on the WDDOMODIFYVIEW of the main view (which has the tabstrip) the tab changing was fired (set_selected_tab) only if the required_ok flag was set.

Problems with this:

- It is cumbersome (i'm having great difficulties trying to explain it here)

- Each view had to have exactly the same code in WDDOBEFOREACTION.

- The main problem: the framework methods WDDO* execute <b>for each view</b> so, although there's only one tab selected at a time, all of the inner views of each tab get processed (i really don't get the cause of that behaviour but this would be a pain given the 30+ tabs I must handle - not counting the views apart from the one with the tabstrip, which also get processed).

Alternative B) If I define the fields directly inside each tab and trigger the method cl_wd_dynamic_tool=>check_mandatory_attr_on_view on the WDDOBEFOREACTION of the view holding the tabstrip, all the required fields on the other tabs get checked as well, leaving focus in the current tab with an error message but not focusing on any field (that's why I assume it's pointing to fields in other tab).

Main additional problem with this: work cannot be split between different people, since all of the fields are in the same view / tabstrip. So one single developer will be able to program the view at a time.

Do you see a different solution to this requirement or a way to solve the problems with our approaches?

Have in mind, that the tabstrip view will be (through component usage) part of a larger view, through (yes, you guessed) a viewcontaineruielement. In fact, there will be two tabstrips (one belonging to header data, one to item data) and both of them should have this behaviour of required fields validation.

Many thanks for reading all this and any suggestion you may do.

[Former Member · Accepted solution]

Hi Alejandro!

I'm not sure whether I really understand your problem. I suppose that you want "required field" checks only for the currently active tab of the tabstrip and not for fields on the other tabs.

You can achieve this the following way: As per default the whole tabstrip with all tabs and their contents is handed over to and rendered at browser client the first time you call the tabstrip. Thus all the rest when changing tabs is the job of the client ...

To avoid this and to just render the data of the current tab you have to force the WDA application to make a server roundtrip each time a tab change is done. You can achieve this by using the tabstrip UIElement property selectionChangeBehaviour and by doing some coding on your own.

For more details have a look at http://help.sap.com/saphelp_nw2004s/helpdata/en/e8/ac884118aa1709e10000000a155106/content.htm and may be you also will find a sample in one of the SAP test WDA application WDR_TEST_* like WDR_TEST_UIELEMENTS

Hope this helps.

Regards,

Volker

[alejandro_bindi · Accepted solution]

Hello Volker, thanks for your help.

That's what I want to do, you got it right.

But I think the solution you suggest is exactly what i'm already doing, i've already set the selectionChangeBehaviour as manual and on the change action i'm capturing the clicked tabs. I'm the one changing the tab programatically. That's not exactly the problem. Or maybe i'm not fully understanding your suggestion.

This whole thing is really hard to explain.

Thanks again.

[Former Member · Accepted solution]

Hi Alejandro!

I think this is the only way you can achieve it. But of course I am not WDA god ....

To avoid cumbersome redundant coding in the serveral view controllers you may make use of assistance class technology (http://help.sap.com/saphelp_nw2004s/helpdata/en/43/1f6442a3d9e72ce10000000a1550b0/content.htm) or maybe even better create your own "service/helper class" outside the WDA framework just using SE24. Instantiate an object of this class in your main component controller and use it in your sub-components ....

Did you get what I mean?

Regards,

Volker

[alejandro_bindi · Accepted solution]

Yes, I thought about isolating the validation code in one method of the assistant class, so the only code on each WDDOBEFORE action would be a single method call, sending the View reference...but nevertheless, i'm not really happy with this solution, because of the multiple method calls even if inside there's an exit because it's not the selected tab.

To shorten something really long: I need to do validations over some input fields which will be inside each tab. Only when all validations pass, the user is able to leave to other tab, otherwise messages will be issued staying in the current tab.

What solution do you see to that? How would you architect the component and where would you do the validations? Maybe you can give me further ideas to try (I really did try a lot already).

Thanks

[Former Member · Accepted solution]

Hi Alejandro!

Unfortunately and like already mentioned in my last reply I think the way you do it now is the only (although maybe cumbersome) way you can achieve what you need.

But of course I am not a WDA god and maybe other forum members may have additional/better ideas ... Last chance may be to make use of BSP technology instead of WDA ...

Sorry for that ;-(

Regards,

Volker

[alejandro_bindi · Accepted solution]

Ok, so let's pray for some god to show up

BSP is not an option, it must be WDA as it's a business requirement.

Regards

[Former Member]

Hi,

if you want only the active tab to be checked and every tab of the tabstrip is a

different view, you should define the lifetime of the views to when visible,

this way only the view on screen will be checked.

grtz,

Koen

[alejandro_bindi]

Hello Koen,

The WDDOMODIFYVIEW methods of each view execute always, regardless of the lifetime setting.

The When visible setting on help reads: <i>A view may be visible in the technical

sense as part of a view set, although its

content on the screen may be a hidden tab

in the background, for example. In this case

the view data is still available as before, and

the view exists.</i>

I think this applies to this case, meaning that the view is "visible" because it is part of the current main view.

I'll have to relate the view to the tab and exit each view's processing if it's not inside the current tab.

If anyone comes up with a better idea please post.

Thanks

[Former Member]

Hi,

this may be stupid, but just in case:

in BSP i did the following: check on the main controller whether there was an instance

of the subcontroller, which was only there if visible.

so if you do the transportation to webdynpro:

have on the component controller the layout node with the visible attributes

of each view, read this attribute in the view methods of the corresponding view,

if it's abap_true, it means it is on screen

or you can enhance each tab with the embedding of the empty view, which you set default view

if the tab is clicked, set visible and navigate towards

the view you need to display, if the tab is changed, navigate

back to empty view for the last shown, and to the real view

for the one you clicked

grtz,

Koen

Message was edited by:

Koen Labie

[alejandro_bindi]

Hello Koen,

Your second idea with dynamic navigation is something I'll keep as an alternative.

We were trying to avoid dynamic navigation but maybe it's not that complex compared to all the work needed for the current solution.

Many thanks

To others, please keep coming with alternatives (i'll leave the thread open).