Showing posts with label controls. Show all posts
Showing posts with label controls. Show all posts

Thursday, March 29, 2012

Performance question regarding dynamic controls

I am trying to build a reasonably large table (maybe 50 rows x 12
columns) dynamically on the server-side using the Table(), TableRow(),
and TableCell() objects provided by ASP.NET. For various reasons I
don't want to use a datagrid and do any binding, but would rather build
the table dynamically.
My question has to do with the performance of these objects - would it
be significantly faster for me to just dynamically generate some static
HTML strings and write those out to the client instead of instantiating
all these objects? I have a feeling that it would be faster, but no
idea how much so. I realize that using static HTML will preclude using
any ASP.NET server side objects in the code, but this purpose it may be
ok.
Does anyone know how much slower the dynamic controls would be as
compared to standard string output?
Thanks!I doubt you would see any performance difference between the two. If
it were me, I'd build whatever was most readable and maintainable. I'd
only worry about performance if it proved noticably slow during
testing.
Jason Kester
Expat Software Consulting Services
http://www.expatsoftware.com/

Performance question regarding dynamic controls

I am trying to build a reasonably large table (maybe 50 rows x 12
columns) dynamically on the server-side using the Table(), TableRow(),
and TableCell() objects provided by ASP.NET. For various reasons I
don't want to use a datagrid and do any binding, but would rather build
the table dynamically.

My question has to do with the performance of these objects - would it
be significantly faster for me to just dynamically generate some static
HTML strings and write those out to the client instead of instantiating
all these objects? I have a feeling that it would be faster, but no
idea how much so. I realize that using static HTML will preclude using
any ASP.NET server side objects in the code, but this purpose it may be
ok.

Does anyone know how much slower the dynamic controls would be as
compared to standard string output?

Thanks!I doubt you would see any performance difference between the two. If
it were me, I'd build whatever was most readable and maintainable. I'd
only worry about performance if it proved noticably slow during
testing.

Jason Kester
Expat Software Consulting Services
http://www.expatsoftware.com/

Saturday, March 24, 2012

Permission on a page

I want to lock certain users out of a certain page or using certain controls. What is the correct practice to do that?
Thank Youim not to sure about the absolute correct way to do this
but if you have login you can block people out of it by doing this
web config file

this will not allow any users in who are not logged in

<authorization>
<deny users="?" /> <!-- deny users not logged in -->

<!-- <allow users="[comma separated list of users]"
roles="[comma separated list of roles]"/>
<deny users="[comma separated list of users]"
roles="[comma separated list of roles]"/>
-->

</authorization>

then to allow unauthorized users into a certain page i.e. who are not logged in
this will allow users who arent logged in to page
webform1.aspx - put in bottom of webconfig file
<location path="WebForm1.aspx">
<system.web>
<authorization>
<allow users="*" />
</authorization>
</system.web>
</location>

im not sure this is what you are looking for but it might help get you started
Our users will have to log in and that goes against Active Directory. However, only certain users are allowed to a certain page. Is the above the best way to approach this? Does that means that I will have to maintain who has rights through webconfig file and what page they have rights on?

Friday, March 16, 2012

Persist Page Location

I have an aspx page which has many controls. Just enough to cause the user t
o scroll down a little to see them all. Incidentally the last control is a t
able control which allows you to add a new row dynamically upon clicking a l
ink button.
Because link button fires a postback, which is what is needed in order to ad
d the next row to the table it brings the user back to the top of the page a
fterwards.
I want the user to be back where they clicked on the link button at the bott
om of the page. I recall there is a setting or some easy way to do this but
for the life of me can not remember. Any help would be great!
-DemetriOn 8/4/2004 10:45 AM, Demetri wrote:
> I have an aspx page which has many controls. Just enough to cause the user
to scroll down a little to see them all. Incidentally the last control is a
table control which allows you to add a new row dynamically upon clicking a
link button.
> Because link button fires a postback, which is what is needed in order to
add the next row to the table it brings the user back to the top of the page
afterwards.
> I want the user to be back where they clicked on the link button at the bo
ttom of the page. I recall there is a setting or some easy way to do this bu
t for the life of me can not remember. Any help would be great!
>
SmartNavigation was the way to overcome some of this 'page viewing
state' problems in the browser, but I've heard it's buggy.
Craig Deelsnyder
Microsoft MVP - ASP/ASP.NET
Hi Demetri,
Have a look at Scott Guthrie's TechEd 2003 Black Belt Web Forms presentation
(http://www.scottgu.com) he coveres this scenario, under the title
"scrolling and postback".
Hope this helps,
Michael
This posting is provided "AS IS" with no warranties, and confers no rights.
"Demetri" <Demetri@.discussions.microsoft.com> wrote in message
news:54F55A7E-B548-402A-BCF4-1DBFDD5FF9BE@.microsoft.com...
>I have an aspx page which has many controls. Just enough to cause the user
>to scroll down a little to see them all. Incidentally the last control is a
>table control which allows you to add a new row dynamically upon clicking a
>link button.
> Because link button fires a postback, which is what is needed in order to
> add the next row to the table it brings the user back to the top of the
> page afterwards.
> I want the user to be back where they clicked on the link button at the
> bottom of the page. I recall there is a setting or some easy way to do
> this but for the life of me can not remember. Any help would be great!
> --
> -Demetri

persist values from one postback to another

Hi,

Not sure if the title makes sense but heres my dilemma. I have two
dropdownlist controls on a webform. I want to make sure that the first
dropdownlist control was clicked on and a value was selected. I want to check
in the second dropdownlist control that this has happened before processing
any info. I thought I would set a boolean in the selected event of the first
ddl control but when the event fires for the second ddl control the boolean
is set back to false due to the page reloading, I assume. How can I persist
that boolean value between postbacks? And for this scenario what is the best
way to achieve my goal if the way im describing is not the best?

Thanks,

JJTake a look at requiredFieldValidator and custom validator
The easiest way to handle this is to simply check and ensure the first
control is not set to index 0.

if(ddlFirstControl.SelectedIndex==0)
//code to indicate the user did not touch drop down 1
else
//code to process dropdown 2

If you want to persist a boolean (not necessary if the first drop down has
an invalid value, like "choose one"), you can store it in ViewState.

//in Drop down change event for the first drop down
ViewState("FirstControlChanged") = true;

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

***************************
Think Outside the Box!
***************************

"JJ" wrote:

> Hi,
> Not sure if the title makes sense but heres my dilemma. I have two
> dropdownlist controls on a webform. I want to make sure that the first
> dropdownlist control was clicked on and a value was selected. I want to check
> in the second dropdownlist control that this has happened before processing
> any info. I thought I would set a boolean in the selected event of the first
> ddl control but when the event fires for the second ddl control the boolean
> is set back to false due to the page reloading, I assume. How can I persist
> that boolean value between postbacks? And for this scenario what is the best
> way to achieve my goal if the way im describing is not the best?
> Thanks,
> JJ

Persist tables controls

Hi everyone,

I don't know why all the controls of the Table class (server control)
has to be reconstructed for each page load. The MSDN said that it is
because the children controls are not the Table properties. But why
other controls like ListBox or DataGrid can persist their child
controls?

I'm very confused about this.

Thanks for any reply,

Nhat YenHi,

all non-controls are persisted via ViewState and they can be restored that
way. But controls do need to recreated on every request (and they then load
their own state indepedently after they have been created)

ListBox works so that it saves the state by calling SaveViewState of its
Items collection (ListItemCollection) which stores the items in key/value
sense. On postback items are loaded from ViewState and ListItemCollection
is reconstructed. E.g ListBox actually uses the similar procedure to
repopulate the collection. ListItems aren't controls so therefore ListBox
can work this way without controls "in the middle".

DataGrid can recreate the controls because they (child controls) are usually
specified in templates (or via columns). DataGrid stores the count of rows
which it uses to recreate the Items collection (by instantiating templates)
and then the child controls load their state independently after they've
been created. So basically DataGrid doesn't store the child controls but
recreates them on postback.

Basically you can't avoid recreating controls because control are themselves
responsible for storing their state. Also it would be terribly inefficient
tho store complete control instances to ViewState, therefore only control
state is stored and controls themselves are recreated.

--
Teemu Keiski
MCP, Microsoft MVP (ASP.NET), AspInsiders member
ASP.NET Forum Moderator, AspAlliance Columnist

"Nhat Yen" <s2119205@.rmit.edu.vn> wrote in message
news:1d84a655.0402211915.5cfed176@.posting.google.c om...
> Hi everyone,
> I don't know why all the controls of the Table class (server control)
> has to be reconstructed for each page load. The MSDN said that it is
> because the children controls are not the Table properties. But why
> other controls like ListBox or DataGrid can persist their child
> controls?
> I'm very confused about this.
> Thanks for any reply,
> Nhat Yen
Thanks for very clear explanation Teemu, it help me a lot.

Again thank you!

"Teemu Keiski" <joteke@.aspalliance.com> wrote in message news:<erMHQre#DHA.3816@.tk2msftngp13.phx.gbl>...
> Hi,
> all non-controls are persisted via ViewState and they can be restored that
> way. But controls do need to recreated on every request (and they then load
> their own state indepedently after they have been created)
> ListBox works so that it saves the state by calling SaveViewState of its
> Items collection (ListItemCollection) which stores the items in key/value
> sense. On postback items are loaded from ViewState and ListItemCollection
> is reconstructed. E.g ListBox actually uses the similar procedure to
> repopulate the collection. ListItems aren't controls so therefore ListBox
> can work this way without controls "in the middle".
> DataGrid can recreate the controls because they (child controls) are usually
> specified in templates (or via columns). DataGrid stores the count of rows
> which it uses to recreate the Items collection (by instantiating templates)
> and then the child controls load their state independently after they've
> been created. So basically DataGrid doesn't store the child controls but
> recreates them on postback.
> Basically you can't avoid recreating controls because control are themselves
> responsible for storing their state. Also it would be terribly inefficient
> tho store complete control instances to ViewState, therefore only control
> state is stored and controls themselves are recreated.
> --
> Teemu Keiski
> MCP, Microsoft MVP (ASP.NET), AspInsiders member
> ASP.NET Forum Moderator, AspAlliance Columnist
>
> "Nhat Yen" <s2119205@.rmit.edu.vn> wrote in message
> news:1d84a655.0402211915.5cfed176@.posting.google.c om...
> > Hi everyone,
> > I don't know why all the controls of the Table class (server control)
> > has to be reconstructed for each page load. The MSDN said that it is
> > because the children controls are not the Table properties. But why
> > other controls like ListBox or DataGrid can persist their child
> > controls?
> > I'm very confused about this.
> > Thanks for any reply,
> > Nhat Yen
Thanks for very clear explanation Teemu, it help me a lot.

Again thank you!

"Teemu Keiski" <joteke@.aspalliance.com> wrote in message news:<erMHQre#DHA.3816@.tk2msftngp13.phx.gbl>...
> Hi,
> all non-controls are persisted via ViewState and they can be restored that
> way. But controls do need to recreated on every request (and they then load
> their own state indepedently after they have been created)
> ListBox works so that it saves the state by calling SaveViewState of its
> Items collection (ListItemCollection) which stores the items in key/value
> sense. On postback items are loaded from ViewState and ListItemCollection
> is reconstructed. E.g ListBox actually uses the similar procedure to
> repopulate the collection. ListItems aren't controls so therefore ListBox
> can work this way without controls "in the middle".
> DataGrid can recreate the controls because they (child controls) are usually
> specified in templates (or via columns). DataGrid stores the count of rows
> which it uses to recreate the Items collection (by instantiating templates)
> and then the child controls load their state independently after they've
> been created. So basically DataGrid doesn't store the child controls but
> recreates them on postback.
> Basically you can't avoid recreating controls because control are themselves
> responsible for storing their state. Also it would be terribly inefficient
> tho store complete control instances to ViewState, therefore only control
> state is stored and controls themselves are recreated.
> --
> Teemu Keiski
> MCP, Microsoft MVP (ASP.NET), AspInsiders member
> ASP.NET Forum Moderator, AspAlliance Columnist
>
> "Nhat Yen" <s2119205@.rmit.edu.vn> wrote in message
> news:1d84a655.0402211915.5cfed176@.posting.google.c om...
> > Hi everyone,
> > I don't know why all the controls of the Table class (server control)
> > has to be reconstructed for each page load. The MSDN said that it is
> > because the children controls are not the Table properties. But why
> > other controls like ListBox or DataGrid can persist their child
> > controls?
> > I'm very confused about this.
> > Thanks for any reply,
> > Nhat Yen