[OPEN] [#257] Namespace and ID issue in v2.2

[Vladimir]

Just that when it transforms # tag to actual id, it should return NameSpace.ItemId. How do I ensure that?

It is required to change TokenParser code. I am not sure why do you need #{} syntax if you know namespace and ItemID is not changeable by ASP.NET (so client id is compeletly predictable)

I want to understand why the following code is inconvenient for you

UserControl

<%@ Control Language="C#" %>


<script runat="server">    
    protected void Button1_DirectClick(object sender, DirectEventArgs e)
    {
        TextField1.Text = DateTime.Now.ToShortTimeString();
    }
</script>


<ext:TextField ID="TextField1" runat="server" Namespace="Controls" IDMode="Static" />
<ext:Button ID="Button1" runat="server" Namespace="Controls" OnDirectClick="Button1_DirectClick" Text="Set value (server)" />
<ext:Button ID="Button2" runat="server" Namespace="Controls" Handler="#{TextField1}.setValue(new Date().toString());" Text="Set value (client1)" />
<ext:Button ID="Button3" runat="server" Namespace="Controls" Handler="Controls.TextField1.setValue(new Date().toString());" Text="Set value (client2)" />

If you would say that two user controls will raise an exception that TextField1 is already defined then lets imagine that ItemID is used for sharing

<ext:TextField ID="TextField1" ItemID="TextField1" runat="server" Namespace="Controls" />

In this case we will not have that exception, shared variable will be Controls.TextField1
But if you define two user controls then shared variable of second user control will shadow of variable in first user control, it is the same error (only silent)

So, what advantages give you ItemID? Can you provide a little sample demonstrates ItemID convenience

[amitpareek]

Yes you are right. But only if I use same namespace. I can ensure ItemId is unique in a namespace. Because my Namespaces are specific to UserControls. Each UserControl has its own namespace. So TextField1 will be unique in Controls and Controls2 namespace.

I can replace #{ throughout the app with namespace and id. But its just extra work. Earlier it would replace #{} with Namespace.ItemId. I still don't understand why is the new way of doing things better.

I would not have argued for this so much if it were'nt for upgrading the project. If it was new project, I would have designed with the way you mentioned.

We upgraded from v1 to v2 that took us nearly a month, and this is just a minor upgrade release. Then why such a big change. How has it improved your system?

Can you not have a property in extnet global config to restore to older method?

I will get you a working example with a full project explaining my issues to you. May be then you will understand better.

[Vladimir]

Javascript override (which i gave you) and the following ClientID code (Ext.Net\Core\BaseControl\BaseControl.cs, line 167) should be enough to revert 2.1 behaviour (do not use IDMode=Ignore because id must be rendered in config)

public override string ClientID
        {
            get
            {
                this.EnsureDynamicID();


                if (this.HasOwnNamespace && this.ItemID.IsNotEmpty() && this.IsGeneratedID)
                {
                    return this.AddNamespaceToID(this.ItemID);
                }


                return this.AddNamespaceToID(this.ConfigID);
            }
        }

If I wrong then please post test case

[amitpareek]

Hi Vlad,
I am confused. Everything worked well just after implementing the JS code apart from #{} token.

so to make #{} token work, do I need to override with the given code?

I will need to change the source and custom compile the app then.

The only different in your code and the existing code is this.isGeneratedID is added in your code.if (this.HasOwnNamespace && this.ItemID.IsNotEmpty() && this.IsGeneratedID) -- your code vs

if (this.HasOwnNamespace && this.ItemID.IsNotEmpty()) -- Existing code.

[Vladimir]

By the way, we are discussing to introduce new id property which will contain shared id
At this moment, we use the following scheme
Namespace.ConfigID = new class({id:ConfigID})

or (if ID is not defined but ItemID and Namespace are defined)
Namespace.ItemID = new class({id:ConfigID})

We want to introduce new property like SharedID which will not affect on server side ID
Namespace.SharedID = new class({id:ConfigID})

It is like ItemID in 2.1 but we don't want to use ItemID for that because ItemID is ExtJs native feature for local searching inside container
SharedID will not require own namespace (like ItemID), it can use global namespace (for example, namespace is defined in web.config)
If SharedID is not defined then ConfigID will be used

We are still thinking about such change therefore do not use it in real application

[Vladimir]

The only different in your code and the existing code is this.isGeneratedID is added in your code.

IsGeneratedID is now using in 2.2 code, it prevents ItemID using (like shared variable) if ID is defined by developer
Therefore if you want to have 2.1 behaviour then you need to remove it from ClientID code

[amitpareek]

By the way, we are discussing to introduce new id property which will contain shared id
At this moment, we use the following scheme
Namespace.ConfigID = new class({id:ConfigID})

or (if ID is not defined but ItemID and Namespace are defined)
Namespace.ItemID = new class({id:ConfigID})

We want to introduce new property like SharedID which will not affect on server side ID
Namespace.SharedID = new class({id:ConfigID})

It is like ItemID in 2.1 but we don't want to use ItemID for that because ItemID is ExtJs native feature for local searching inside container
SharedID will not require own namespace (like ItemID), it can use global namespace (for example, namespace is defined in web.config)
If SharedID is not defined then ConfigID will be used

We are still thinking about such change therefore do not use it in real application

Gr8. But couple of questions.

1) ConfigID=ID of Control. Right?

2) ItemID = Searching control with ItemID in ExtJS is completely different then what we had in 2.1 ItemID becomes sharedID within its namespace. I don't see any harm in it. I don't know where it could cause issue using ItemId as sharedId.

3) SharedId = Can we not have a property in extnet global config, something like "SharedIDMode" having properties, "ID, ItemID, Defined". If ID, then it will use ID, else it will use ItemId and lastly if Defined selected, user defined SharedId.

This way we need not specify shared ID and itemid for every control. It can determine automatically.

In the above case, if ID is specified, and a name space is mentioned in control tag, then client ID would become NameSpace.ID.

for eg :

<ext:button ID="btnSubmit" NameSpace="Controls" ></ext:button>

it would become Controls.btnSubmit on client side (by automatically setting ID as sharedid) insteal of Controls.ctl02_panel1_btnSubmit

This way we don't have to specify the SharedID seperately everytime, if ID is present, sharedID will be ID.

IsGeneratedID is now using in 2.2 code, it prevents ItemID using (like shared variable) if ID is defined by developer
Therefore if you want to have 2.1 behaviour then you need to remove it from ClientID code

I have latest from SVN, and I cannot see IsGeneratedID in 2.2 code. Did you mean its removed in 2.2?

Anyway, my issues are resolved with JS you provided. Only stuck with #{} token translations. How do I fix them.

[Vladimir]

1) ConfigID=ID of Control. Right?

No, it is ID is transformed according IDMode and ClientIDMode rules. It is ClientID without Namespace

2) ItemID = Searching control with ItemID in ExtJS is completely different then what we had in 2.1 ItemID becomes sharedID within its namespace. I don't see any harm in it. I don't know where it could cause issue using ItemId as sharedId.

Because in many cases it is required to use ClientID for direct referencing and itemId for local searching

<ext:Container ID="Container1" runat="server">
     <Items>
             <ext:TextField runat="server" ID="TextField1" ItemID="field" Namespace="Controls" />
     </Items>
</ext:Container runat="server">

<ext:Container ID="Container2" runat="server">
     <Items>
             <ext:TextField runat="server" ID="TextField2" ItemID="field" Namespace="Controls" />
     </Items>
</ext:Container runat="server">

So, for direct referencing you need to use Controls.TextField1 and Controls.TextField2 and Container1.query("#field") for searching withing a container
But in v2.1 ItemID is used for sharing therefore Controls.TextField1 and Controls.TextField2 doesn't work, only Controls.field is defined and there is no possibility to get TextField1

3) SharedId = Can we not have a property in extnet global config, something like "SharedIDMode" having properties, "ID, ItemID, Defined". If ID, then it will use ID, else it will use ItemId and lastly if Defined selected, user defined SharedId.

Thanks for suggestion, we will consider ID. I guess that SharedIDMode can have the same values as IDMode, for example SharedIDMode=Static will produce

Controls.btnSubmit = new class({id : "ctl02_panel1_btnSubmit"});

I don't want to use ItemID as shared variable, reason - see Item #2

I have latest from SVN, and I cannot see IsGeneratedID in 2.2 code. Did you mean its removed in 2.2?

Try to update from SVN again, it was fixed today

Anyway, my issues are resolved with JS you provided. Only stuck with #{} token translations. How do I fix them.

Can you provide test sample? Please note that #{} syntax expects ID (not ItemID), so if you have

<ext:TextField ID="TextField1" ItemID="field" Namespace="Controls"....

then need to use #{TextField1} and it will be transformed to (if you use that javascript override and ClientID without IsGeneratedID) to

Controls.field

[amitpareek]

Hi Vlad,
1) I agree to everything you say about ItemID. I understand it better now. Thanks!

2) I don't mind have SharedIDMode = "Static". But then what would be other options and what would they mean? Secondly, hope it does'nt make it unique in the app, but unique only within a namespace.

There is a tendency for users to get confused in IDMode and SharedIdmode if both have same values. If its only 2 values, either deriving from ID or manually defined, then might as well just have 2 options "ControlID" or "UserDefined".

3) I got the latest change now. Thanks.


Also, I have posted another post, related to your reply to one of the forum members earlier. Its a continuation. I would appreciate if you could look into it.

http://forums.ext.net/showthread.php...482#post106482

[amitpareek]

Hey Vlad,
Do you know by when this could be implemented?

Also, can you ensure #{} token uses shared id, since it will be by default ID.