New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Access to local variables and functions in table and pageextension #593

Open
FSharpCSharp opened this Issue Sep 4, 2017 · 8 comments

Comments

Projects
None yet
6 participants
@FSharpCSharp

FSharpCSharp commented Sep 4, 2017

When creating a TableExtension and/or PageExtension it would be useful to be able to call the local functions of the original object. This would also come close to the concepts of inheritance. You could also address the inherited object with Base.XYZ to call the function. In this case, it would also make sense to access the global variables in this object.

@FSharpCSharp FSharpCSharp changed the title from Access to local variables in table and pageextension to Access to local variables and functions in table and pageextension Sep 4, 2017

@Gallimathias

This comment has been minimized.

Contributor

Gallimathias commented Sep 4, 2017

This definitely belongs to: #153, #120, #186

@FSharpCSharp

This comment has been minimized.

FSharpCSharp commented Sep 5, 2017

True, there were already points that had similar requirements. But our requirement in this case was rather an approach known from the object-oriented world. This was not primarily a matter of overwriting existing functions, as described in the other topics. It is much more about accessing existing logic of a page or table. Of course, this is a certain danger, because you have to assume that the actual object changes only slightly from month to month. It would be an improvement if, for example, when creating NAV events, the "sender" would always be transferred by default. Then you could easily access the original object and use its public functions.

@Gallimathias

This comment has been minimized.

Contributor

Gallimathias commented Sep 6, 2017

That's why I linked them. It's a package for me.

I still see a lot of problems with competing code in general. As I see it, we use the syntax "extension everywhere" from c# 8. I haven't checked yet whether this works in the background.

Bottom line, I think it's cool but the current style and wise also in my eyes a little bit dirty. I really would like to see a clear inheritance structure.

Topics that need to be clarified are, in my opinion:

  • Handling and compatibility with original code
  • Access to "original" methods
  • Dealing with competing code
  • Time of execution
  • Error and conflict handling
@Gallimathias

This comment has been minimized.

Contributor

Gallimathias commented Sep 7, 2017

What about competing apps? For example, an app sets the customer's name to invisible and another app to visible?

Which app wins? Can I control this behavior? When I try to add the field manually, nav Crashs?

I'm adding this because I think it's the same topic or it has the same consequences.

@StanislawStempin

This comment has been minimized.

Member

StanislawStempin commented Sep 8, 2017

We don't foresee allowing access to local variables/procedures. However, something we are considering longer-term is introduction of protected visibility. It will require base app refactoring before it can be used in extensions though.

@ajkauffmann

This comment has been minimized.

Contributor

ajkauffmann commented Mar 24, 2018

I would like to express my support to the idea that tableextensions and pageextensions do have access to local variables and functions. I'm not talking about inheritance or any calling code with Base.SomeFunction.
Instead, I'm thinking like this: from the code in a tableextension you can directly access fields on the record, without the need of using Rec.SomeField. From that point of view, a tableextension is getting closer to a table then a variable of type Record. Enabling a tableextension to call all functions, including the local functions, makes it even more closer to the original table.
For example, I have seen scenario's where I need functions like CalcBaseQty or CalcUnitCost in a tableextension for table Sales Lines. Which is not possible because those functions are local. But I can call them when I add code to the base table. So why not when writing code in a tableextension?

@MicAlter31

This comment has been minimized.

MicAlter31 commented Mar 24, 2018

I totally agree with Arend-Jan. Have a look at Sales Order Subform and try to validate the field „No.“ and compare the results. There are several (page) local functions which are called (e.g. OnAfterValidateNo or OnAfterValidateQty). I think that code cloning is not the right way - remember that the code could be changed with every CU.

The best solution would be to have full access to the object when implementing a page or table extension. The easiest to declared them like some others as „external“ ;)

@rdiazbla

This comment has been minimized.

rdiazbla commented Jun 11, 2018

Hi,
I have wrote in issue #2421 and Gallimathias (thanks) redirect me to this issue, but I don't find there the solution.

I add a new procedure (personalization) in a tableextension because the original procedure is internal, and I not have acces to global variables defines in the table.

In this example I can declare local variables but not always is the solution. Is posible, using AL, access to global variables?

tableextension

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment