Hello!
You can avoid binding data in the code-behind using HttpProxy like in this sample: https://examples1.ext.net/#/GridPane...rting/Handler/
You can add to the handler additional parameter to say from what table read the required data and return the data to the client. Also, I'd add some config option to your custom control that will say URL for the Store to avoid hard-coding.
Hi
Well, I want to do data binding in code behind because datasource is not just a select * from table and lists are in the cache anyway. Also I don't want to do a separate ajax call to the server just to load data which is not mutated over time (or very slowly) - it's good when reloading the grid or doing autocomplete but not in my case.
In my case - it just a some persistent data and all I want to do is to define SimpleStore and data fields so I won't have to fill the SelectBox manually in code-behind (the routine uc.DataSource = list; uc.DataBind(); can be changed to just uc.LoadData(list) in such a case).
Also it's interesting to me if SimpleStore is better than the reader/proxy stuff.
Just to clarify, SimpleStore is a synonym (old name) of the ArrayStore: http://docs.sencha.com/extjs/3.4.0/#...ata.ArrayStore . ExtJS has many versions of basic Store and each of them work with some type of data. Therefore, as you use arrays as the source for your Stores, then yes ArrayStore is a preferable way to do it.
I don't think that there is a better way to bind the data to your ArrayStore. However, you can try to set Data property directly
Code:<CustomConfig>
<ext:ConfigItem Name="data" Value="[['3m Co',71.72,0.02,0.03,'9/1 12:00am']]" Mode="Raw" />
</CustomConfig>
Can you clarify, what do you mean? ArrayStore has readers and proxies as well but they designed for arrays.Quote:
Also it's interesting to me if SimpleStore is better than the reader/proxy stuff.
Well, I have List<T> of some objects, taken from database. I can convert it to the array, however, but I wanted to do binding the data without manual conversion - just define store, set it to some List<T>, define model, etc. Just want to push data directly into the ComboBox without having to iterate the list and add ListItem objects in the loop. It just that I don't like reflection, but it seems that Ext.net is doing the reflection internally anyway, no? However, the main goal is to minimise usage of javascript because it has very poor performance in the FF :-(
I mean that additional objects are created for simple persistent data. For what? I want to set just an array of data to the ComboBox in code-behind without additional javascript objects Ext.ux.data.PagingStore, Ext.data.JsonReader, Ext.data.PagingMemoryProxy... I don't think that such additional objects will improve performance which is poor in FF. Or do you mean that SimpleStore (ArrayStore) create all such objects internally?
There are several positions I would like to comment.
1. Ext.ux.data.PagingStore/Ext.data.PagingMemoryProxy VS Ext.data.SimpleStore.
- Yes, a PagingStore is used by default for <ext:Store>.
- I don't think a PagingStore is required in your case, but I don't see a built-in possibility to switch an <ext:Store> to SimpleStore. A SimpleStore is only used with a SelectBox's Items. Maybe, you would like to subclass an <ext:Store> rendering a SimpleStore with that.
- Yes, a SimpleStore is a bit more lightweight than a PagingStore. A SimpleStore doesn't use any kind of proxies. A PagingStore uses a PagingMemoryProxy and have some additional functionality which is not supposed to be used in your case. Generally speaking, you are good that you want to simplify the thing as much as possible. I always try to do the same Though, if you worry about the performance, I would say the difference between a SimpleStore and a PagingStore/PagingMemoryProxy is totally insignificant.
- Any kind of Stores uses some Reader. A SimpleStore has a predefined ArrayReader. A common <ext:Store> has a Reader which is configured by a developer.
- As a conclusion, I would say there is no difference in the performance while using a SelectBox's Items and a SelectBox's Store. So, I see the only reason to opt one or another - the convenience of using one or another on server side.
2. Reflection.
This question:Quote:
it seems that Ext.net is doing the reflection internally anyway, no?
Yes, reflection is used during data binding. Unfortunately, in some cases it is not possible to avoid it. Though, we also try to avoid reflection as much as possible due to its performance costs. Generally speaking, very similar to your "conversion to Items" is being done during Store.DataBind().
3. FireFox performance.
This statement:
That is an interesting statement. Do you mean that FireFox has a slow JavaScript engine? Yes, it is not the best. For example, it loses to Chrome. But beats IE.Quote:
However, the main goal is to minimise usage of javascript because it has very poor performance in the FF
Could you, please, provide any more details regarding that?
A quick summary.
You are on the right way to simplify the things as much as possible, but, I am afraid, in this concrete case it won't give you any improvement in the performance. So, if you have any problems with the performance, it is 100% not because of the SimpleStore VS PagingStore issue.
Thank you for your answer, it is very detailed and interesting.
It's good that there is no significant difference, but it's not very convenient to see some strange objects used for simple array of data. Anyway, I already plan to subclass SelectBox and since I'm migrating to 2.3 (at last it is released), I'll try new options with setting Data of Store property directly or something else.
Well, I think that I can avoid it my overriden DataBind function.
Well, I don't remember in which version of FF it was started, but I remember that at some point of time js in FF had started to perform poorly...
It is a long story. Anyway when I worked on some project 6 years ago in which I tested different js engines for the conformance to standard, I also tested their perfomance - and SpiderMonkey was good comparing to others (well JScript was better in some areas while SpiderMonkey was better in another).
But now our complex application sometime hangs up badly in FF, but never in Chrome and IE - strange but fact. And I don't know why. The only thought is that it is because of complex javascript code generated, may be some functions are not optimized in FF.
I read that ExtJs have bad perfomance in FF because of several reasons (and Firebug is definitely not the cause of it because our clients just don't have it installed). Anyway I don't have time to do profiling. Anyway I'll check it again after upgrading to v2.3. Also I already did some tweaks and the question SimpleStore vs PagingStore/PagingMemoryProxy arose during those tweaks - I just can't stop when I do optimization job :-)
Yes, just like I thought, but anyway I just can't stop :-) and if something can be made simplier - it should be :-)
Anyway it would be good to have possibility to configure Store to be rendered as SimpleStore. May be it is possible in v2.3 - I'll check the possibility to set Store.Data property directly, but this thread can be closed - it was very informative.
Well, the simplest would be replacing
withCode:foreach (object l_object in l_list)
and access the properties by:Code:foreach (SomeEntity l_object in l_list)
instead of reflection:)Code:l_object.PropName
Another option is using generics.
An interesting fact about FireFox. Good to know, thanks. It is also interesting how v2.3 will behave with your application.
Absolutely, I follow this policy as well:)
Yes, it is better in v2.x.
The following example:
Example
renders the following SelectBox:Code:<%@ Page Language="C#" %>
<%@ Register Assembly="Ext.Net" Namespace="Ext.Net" TagPrefix="ext" %>
<script runat="server">
protected void Page_Load(object sender, EventArgs e)
{
if (!X.IsAjaxRequest)
{
Store store = this.SelectBox1.GetStore();
store.Data = new object[]
{
new object[] { "1", "Item 1" },
new object[] { "2", "Item 2" },
new object[] { "3", "Item 3" }
};
}
}
</script>
<!DOCTYPE html>
<html>
<head runat="server">
<title>Ext.NET v2 Example</title>
</head>
<body>
<form runat="server">
<ext:ResourceManager runat="server" />
<ext:SelectBox
ID="SelectBox1"
runat="server"
DisplayField="text"
ValueField="value">
<Store>
<ext:Store runat="server">
<Model>
<ext:Model runat="server">
<Fields>
<ext:ModelField Name="value" />
<ext:ModelField Name="text" />
</Fields>
</ext:Model>
</Model>
<Reader>
<ext:ArrayReader />
</Reader>
</ext:Store>
</Store>
</ext:SelectBox>
</form>
</body>
</html>
Though, I should note again that a Store's Data is serialized by Json.NET. I think it is done using reflection. If you like to avoid it, you could still prefer to put the data into Items without reflection.Code:Ext.create("Ext.ux.SelectBox", {
id: "SelectBox1",
renderTo: "App.SelectBox1_Container",
valueField: "value",
store: {
model: Ext.define(Ext.id(), {
extend: "Ext.data.Model",
fields: [{
name: "value"
}, {
name: "text"
}]
}),
storeId: "ctl04",
autoLoad: true,
data: [
["1", "Item 1"],
["2", "Item 2"],
["3", "Item 3"]
],
proxy: {
type: 'memory',
reader: {
type: "array"
}
}
}
});
As for migrating to the v2.x.
Are you going to support IE < 9 after migration?
Yeah. and since all data types have the same columns {id, label}, it will be simple
There are only two options which differs: javascript engines and renderer. So it could be ExtJS (which is developed by Sencha, not you) or browser fails to render complex layout. And I tend to think that it is a ExtJS.
Well, since I want to implement my own server control which is inherited from the select box and everything will be done in code-behind - the simpliest solution will be filling items manually - I just don't need to define model in that case.
But I'll think about it :-)
Who's using them nowadays? :-) Well, no.
Is it intuitive?:) If the same application works fine in IE and Chrome, I would not exclude FireFox from possible reasons... But, certainly, you know your "long story" better than I do:)
Well, it is used more than we all could imagine:)