[CLOSED] client names under the App namespace

[bogc]

Hello:

I am upgrading from 2.1 to 2.2, and I noticed that the algorithm of setting the component names under the App namespace has changed.

I am using IDMode="Predictable" in the ResourceManager object, and in 2.1 the framework created, for instance, window.App.optionsTreePanel while in 2.2 it creates window.App.MainViewPort_optionsTreePanel, i.e. in 2.2 it prefixes the name with the top container id (MainViewPort).

Where can I find the exact rules that govern the naming convention for the references created under the application namespace?

thank you

[Daniil]

Hi @bogc,

Is MainViewPort an <ext:Viewport> control? If so, its ID should not be used with IDMode="Predicable" since it is not a NamingContainer.

Could you, please, provide a test case?

Where can I find the exact rules that govern the naming convention for the references created under the application namespace?

The best we have at the moment is these comments.

enum IDMode

public enum IDMode
{
    /// <summary>
    /// [Default] Inherits the IDMode for the Parent. This is the default functionality of all Ext.Net Components.
    /// </summary>
    Inherit,
        
    /// <summary>
    /// Legacy functionality for generating CliendID's. No change from default ASP.NET functionality.
    /// </summary>
    Legacy,
        
    /// <summary>
    /// Render the "id" property in the client as exactly the value set. Developer must manually ensure client-side ID uniqueness.
    /// </summary>
    Static,
        
    /// <summary>
    /// Do not render the "id" property in the client. 
    /// </summary>
    Ignore,
        
    /// <summary>
    /// Only render the "id" property if the .ID is explicitly set, otherwise renders as the ClientID if autogenerated by the ASP.NET runtime.
    /// </summary>
    Explicit,

    /// <summary>
    /// Only render the ClientID property if the .ID is explicitly set.
    /// </summary>
    Client,

    /// <summary>
    /// The ClientID value is generated by concatenating the ID value of the parent naming container with the ID value of the control. Each segment is separated by an underscore character (_).
    /// </summary>
    Predictable,

    /// <summary>
    /// The ClientID value is generated by concatenating the ID value of the parent Ext.NET component of the parent naming container with the ID value of the control. Each segment is separated by an underscore character (_).
    /// </summary>
    Parent
}

[bogc]

Hi, Daniil:

First of all, I should say that my original title was misleading, the issue that I have is not about the IDMode, it is about the names (references) that are inserted in the App javascript object (where App is namespace set in the ResourceManager object).

Now, the viewport name was added to the name of the panel because the viewport was created in code as a class which implemented the INamingContainer. So this is not a problem with the framework.

I did create some tests so you can see what I meant in this post.

For your convenience, you can download a zip file from here containing the project files.

After you open the project you'll have to fix the references. I created the project as a C# MVC3 project, then I added Ext.Net via Nuget. After I tested 2.2.0 I flipped the references to point to Ext.Net 2.1.1.

Here are the things that I noticed (display each page then click the button to step into the debugger).

1. Test.cshtml & Test2.aspx are basically equivalent, however, their ids are not generated the same in each page. So:

- test.cshtml -
Ext.Net 2.1.1 - Ids: MainViewPort, OptionsPanel. Names under window.App: MainViewPort, optionsPanel (this is the itemID of the OptionsPanel)
Ext.Net 2.2.0 - Ids: MainViewPort, OptionsPanel. Names under window.App: MainViewPort, OptionsPanel (uppercase O is not a typo)

- test2.aspx -
Ext.Net 2.1.1 - Ids: 1_MainViewPort, 1_OptionsPanel. Names under window.App: 1_MainViewPort, optionsPanel (this is the itemID of the OptionsPanel). In 2.1.1 for whatever strange reason, the title is not displayed.
Ext.Net 2.2.0 - Ids: 1_MainViewPort, 1_OptionsPanel. Names under window.App: 1_MainViewPort, 1_OptionsPanel

Not sure this is an issue at all, that is the discrepancy between the ids generated by cshtml vs aspx, however I would have thought (at a superficial level, let's say) that the ids would the same.

2. Test3.aspx shows you the problem that I was trying to point out in this thread.
- in Ext.Net 2.1.1 there is an object window.App.optionsPanel pointing to the Options Panel - again, optionsPanel is the ItemID of the options panel.
- in Ext.Net 2.2.0 under window.App the application has created window.App.PageContent_OptionsPanel.

To conclude, it seems that the JavaScript reference names created under window.App have changed between versions 2.1 and 2.2. In 2.1 the ItemID was used (if present), while in 2.2 the ID is used. I am curious to find the place in the source code where these JavaScript references are created (it might be deep buried in ExtJs)

I hope this clarifies my post.

[Daniil]

Thank you for the test project and all the details.

- test.cshtml -
Ext.Net 2.1.1 - Ids: MainViewPort, OptionsPanel. Names under window.App: MainViewPort, optionsPanel (this is the itemID of the OptionsPanel)
Ext.Net 2.2.0 - Ids: MainViewPort, OptionsPanel. Names under window.App: MainViewPort, OptionsPanel (uppercase O is not a typo)

ID is a priority over ItemID in v2.2 comparing with v2.1. It was otherwise in v2.1 and it was bug.
http://forums.ext.net/showthread.php...l=1#post106235

- test2.aspx -
Ext.Net 2.1.1 - Ids: 1_MainViewPort, 1_OptionsPanel. Names under window.App: 1_MainViewPort, optionsPanel (this is the itemID of the OptionsPanel). In 2.1.1 for whatever strange reason, the title is not displayed.
Ext.Net 2.2.0 - Ids: 1_MainViewPort, 1_OptionsPanel. Names under window.App: 1_MainViewPort, 1_OptionsPanel

Not sure this is an issue at all, that is the discrepancy between the ids generated by cshtml vs aspx, however I would have thought (at a superficial level, let's say) that the ids would the same.

As we know the Predictable IDMode prefixes client ids with an INamingContainer's ID. So, this "1" thing is the ID of the Page which an INamingContainer. The Razor View engine doesn't operate with the "control" term at all. So, as far as I can understand the INamingContainer doesn't make sense for the Razor View engine at all. Respectively, the Predictable IDMode doesn't make sense there as well. Generally speaking, the IDMode feature doesn't make sense with the Razor View engine at all.
http://forums.ext.net/showthread.php...l=1#post110003

2. Test3.aspx shows you the problem that I was trying to point out in this thread.
- in Ext.Net 2.1.1 there is an object window.App.optionsPanel pointing to the Options Panel - again, optionsPanel is the ItemID of the options panel.
- in Ext.Net 2.2.0 under window.App the application has created window.App.PageContent_OptionsPanel.

I think it is due to same bug in v2.1 stated above.

To conclude, it seems that the JavaScript reference names created under window.App have changed between versions 2.1 and 2.2. In 2.1 the ItemID was used (if present), while in 2.2 the ID is used.

Exactly!

I am curious to find the place in the source code where these JavaScript references are created (it might be deep buried in ExtJs)

Ext.NET shares the client reference in the App namespace.

The main part here is generating a control's ConfigID. This property means an ExtJS "id" config. It is done on the server. The main part of logic is inside the BaseControl class, see:
trunk\Ext.Net\Core\BaseControl\BaseControl.cs

As for the JavaScript part of that, please see the ComponentMgr's registerId method, see:
trunk\Ext.Net\Build\Ext.Net\extnet\src\ComponentMa nager.js

Also this post should help to understand the background better.
http://forums.ext.net/showthread.php...ll=1#post73893

It is for v1. Some details has been changed in v2, but the entire picture is very similar. So, I think it is worth to read.

Hope all this helps and please don't hesistate to ask any questions further.

[bogc]

Thanks for the information.