Showing results for 
Search instead for 
Did you mean: 

Problem with Data-binding

Former Member
0 Kudos

Hi there,

hopefully somebody can help me out because I'm having some strange problem with Databinding in one of my MVC-BSPs.

When executing I am running into an "SAP Internal Server Error" telling me that there is a parameter missing for a dynamic function call.

After some debugging and testing the code triggering this is within my view:

<htmlb:dropdownListBox id              = "x_y_ddb"
                       table     = "<%=w_table%>" 
                       selection = "//mymodel/my_table[1].w"
                       nameOfKeyColumn   = "name"
                       nameOfValueColumn = "value"
                       disabled          = "<%=flag%>" >

This code was running ok last week. After some modifications in the model- and the controllerclass it is not running anymore. The strange thing is that I did not change anything regarding the used table or the attributes...

When debugging I found out that the method causing the error is "selection_model->get_attribute( attribute_path = selection_path )."

The attribute selection_path is correctly filled with "my_table[1].w". So all needed parameters are filled as this is the only one passed.

The method is called from "RESOLVE_MODEL_BINDING" of class "CL_HTMLB_DROPDOWNLISTBOX".

After trying a few things I have no more ideas. The error only occurs when binding to the table. Upon binding to a structure or to a field ev erything works fine.

Thing is, Im am 99% sure this worked last week and I can't remember having changed anything directly connected to this. I am still able to see the data that was created during testing last week.

Any ideas for me?



Accepted Solutions (0)

Answers (1)

Answers (1)

Former Member
0 Kudos

Hi again,

I finally found the solution to my problem.

First of all I really like to credit Thomas Jung for his answers in this thread:

I didn't realize that there is a shortdump generated in the system in case of a RABAX_STATE. This definitly saved my day because I was able to track my problem down to this:

As stated above I have an attribute named "my_table" defined in the modelclass. This attribute is called via databinding from within the view.

Something else I have is a method within the model which is called "get_my_table". This method was meant to read some more informations from other databasetables to achieve a more user-friendly output in a tableview (via iterator).

The shortdump told me that it is not the "selection_model->get_attribute( ... )" method which misses a parameter but "get_my_table".

After renaming my method to sth. like "get_my_table_text" everything works fine - no more shortdumps.

My conclusion is that during runtime a method called "get_my_table" is created dynamically for the databinding. Because I allready defined this method the wrong one gets called.

Only remainig question: is it my fault because one should never name a method "get_<i>attributename</i>" which is not returning the parameter itself but something else or is this some sort of bug?

For the record: we are on 620 SP41 with some fixes from note 616900.

Any information/documentation on this?



Former Member
0 Kudos

Interesting you might want to log that with the OSS it sounds a little like a bug - if nothing you will get an answer from the guys who can look under the hood. Perhaps it has something to do with reserved names?

Former Member
0 Kudos

Hi Craig,

I think so too. Just wanted to wait a day or so. Maybe Brian stumbles over this one and asks me to log it into OSS. Would be no problem doing so...

It looks like I have overwritten a dynamically created method which only exists during runtime. I think I should get some points for overwriting not existing methods...

Active Contributor
0 Kudos

Hi Alexander,

I would not exactly call it your 'fault', but as per definition the setter and getter methods have to be named according to these rules (SET_, GET_, SET_S, and so on ...), there is no other way to differentiate for a method whether it is meant to be a setter/getter method or not but the name itself.

So if you want it or not, by creating a method starting with <b>GET_</b> you created a getter method.

That's just my understanding of this, so my word doesn't weigh like Brian's will

But from my point of view this seems logical ...


Former Member
0 Kudos

Hi Max,

I totally agree with you. The naming convention in OO development are the way you explained it.

The conclusion of that is that you are able to define your own getter and setter methods for attributes which are used by the runtime in <b>every</b> case.

Maybe this is OO-dev standard, I don't know.

Or is it documented anywhere that you should not use naming conventions like described unless you want to achieve that those methods are used by the runtime?

Hopefully Brian could bring some light to the dark.