MVC Data Binding - same name required for model instance + page attribute?

[maximilian_schaufler]

I'm dealing with the following problem:

MVC application, tableview in subcontroller, using iterator, creating inputfield in render_cell_start, _value via data binding - everything working ok so far.

Now I need to not return this inputfield as p_replacement_bee, but run render_to_string to first and make the p_replacement_bee a html_bee, because I have to alter the html output of this inputfield.

After debugging into <b>if_bsp_bee_{render_to_string</b>, going down to the METHOD IF_BSP_PAGE}GET_ATTRIBUTE, I found out:

This method is trying to retrieve an attribute from my controller with the attribute name of <b>MODEL</b>, but the name of the controller attribute is <b>MY_MODEL</b>.

In my application I always use MODEL as the page attribute, and MY_MODEL as name for controller classes attributes. Always worked fine until this special requirement came up.

While debugging I altered the name of the attribute that the method IF_BSP_PAGE~GET_ATTRIBUTE is looking for to MY_MODEL (the right controller attribute), and it worked.

So, my question is:

Is the name of the page attribute required to be the same as the controller attribute here?

Or is there an dead-easy hint I overlooked?

(renaming all page attributes to match controller attribute names is not exactly the prefererred solution, unless it was meant to be that way).

Cheers,

Max

[former_member181879]

Max,

I still have this question of yours on my watch list. Somehow, I suspect I understand the question. Can not be sure. So let me just answer any question here.

What does model binding actual bind to seems to be the question? We have a name/id for the total model, we have a controller id, we have the attribute name of the model, etc. Most of these are not interesting.

When you write a binding string, it is of the form: "//ABC/XYZ". This means ABC is the name of attribute on the view (the current execution context!) of the model. XYZ is just the name of the data on the model. Important: ABC is not the model name/id, or anything like controller name. It is the name that you actually used in the attributes tab of your view (that thing you declared as TYPE REF to something that has a IF_BSP_MODEL interface implemented).

So given this string, it explains why the call if_bsp_page->get_attribute( 'XYZ' ) is made. Given the name, we now require the reference onto the actual model class.

It is not required that the attribute name be the same everywhere. The important aspect here is the execution context. For some reason, while it is processing the tags, it thinks that the controller is "on top of context stack", and this causes the confusion. Vaguely, I can remember that there was something problem in this area. Have forgotten the exact details.

What you should look at, is to use a binding for the htmlb tableView. Then, during the interator calls, there is a p_call_binding string that should be correct.

If all of the above does not help (what I suspect), you will have to open an OSS message. This is so we can actually debug through and see what is the execution context.

brian

[Former Member]

Slightly off-topic.

It seems to me that it would be great if ABAP Objects allowed me to define virtual attributes, as is possible in some other OO languages.

This feature allows the developer to specify a method that is to be called whenever an attribute is accessed. So for example, an MVC binding of //ABC/XYZ, would resolve to (if I understand correctly):

whatever = <model_instance>->xyz.

But instead of the attribute XYZ needing to have been populated already, if XYZ was virtual then at runtime a method such as GET_XYZ would be called:

  METHOD get_xyz.
*   Do whatever, such as buffered DB access
*   R_XYZ is a returning parameter of same type as XYZ
    R_XYZ = <whatever>.
  ENDMETHOD.

That's all.

Scott

[maximilian_schaufler]

Hi Scott,

just to reply on your post - there are GETTER and SETTER methods present in model classes.

Although they are not used for every access, like you suggested it, they are very useful for data binding work.

Guess you already knew that, but just in case ...

Cheers,

Max

[Former Member]

Hi Max,

Actually, I didn't know that. Apart from basic intros, I haven't started BSP development yet, but anticipate doing so soon. Just following the forums to glean what I can beforehand.

Cheers,

Scott

[maximilian_schaufler]

I'm using a few setter methods in my application, my plans are to describe parts of it in a mini weblog series ...

Guess it's about time to stop talking and actually start writing

says and is off to structure the first weblog

Max

[Former Member]

Well, if it's any motivation, you'll have at least one reader.

Scott

[former_member181879]

The model classes works about this way. The code first checks for a getter and/or setter method. If these are available, they are used. They must just have a predefined signature. Otherwise generic ABAP is used to update values.

For ABAP, AFAIK, such virtual attributes were planned long time ago. Just never made it into reality. Would also have liked it a few times

[maximilian_schaufler]

To get back to my original question:

I renamed my page attribute vame to be the same as the model attribute - but I will try to come back to this topic later, when my development tasks allow to free some time for this.

[maximilian_schaufler]

...

just couldn't let that problem rest, on a monday morning full of energy

...

Ok, think I solved my problem, all I needed were some kind words from Brian (once again

After paying attention to the execution context I found out that of course I passed on a page_context parameter to my render_to_string method, but as I did just use it for non-data-binding bees before, I was not aware that I was just passing on any page_context that I obviously got ahold of ...

Then, sure as hell, this would cause an error when trying to get that attribute, as the used page-context was the one from the controller class, and there is no such attribute in this class.

So, "all" I had to do was to make sure that I get the right page_context (the right one being the page-context of the view) into my render_to_string call method. Adding this line to my view at the very top ...

model->page_context = me->_m_page_context.

... and changing the render_to-string method call in my iterator's render_cell_start to this ...

html = inputfield->if_bsp_bee~render_to_string(
             my_model->page_context ).

... corrected all of my previous mistakes in using just any page-context.

Final answer to my thread-naming question:

No, the name for model instance and page attribute is sure not required to be the same.

As I use render_to_string quite a few times it was just a matter of time until I had to come across this issue, where data-binding of such elements would relentlessly uncover my sloppy page-context retrieval

[former_member181879]

Yes, be very careful with that page context, especially with storing it on model classes. If you really require somewhere, why not "push" to where you want as one of the method parameters. This way, you always have the correct one in hand to use. Instead of storing this as an attribute on a class. The active page_context is a very volatile piece of pointer.

[maximilian_schaufler]

It's not a method that I explicitly define or call but the iterator's render_cell_start.

But I use this page_context just for storing the current page_context for a specific view, and atm I only access it when calling render_to_string methods.