.NETGURU
  Search:  
NamespacesDiscussions.NET v1.1Dot Net Guru's BlogIT Certification
Page Templates Revisited
Messages   Related Types
This message was discovered on ASPFriends.com 'aspngreuse' list.


Little, Ambrose
Hey all,

We're implementing Ryan's solution on our site, but we're running into
difficulties. In particular, it seems that viewstate is not working on our
databound controls. I've made some modifications to Ryan's solution, so I"m
wondering if I should start w/ those, or if you could tell me if this is a
known issue w/ that solution.

Also, since we're adding everything to a "template" user control, all of the
client-side IDs are written out as ctrl0_myControl or some such variation,
even if they're tecnically at the top level of the control. This kind of
makes sense, since everything is ultimately added to the "template" control
and then added to the page control collection. I'm just wondering if
there's a way to tell it not to render the top level control ID.

Finally, it seems that ASP.NET considers the relative paths to be relative
to where we store the "template" user control, instead of relative to the
ASPX. Any way to overcome this?

Thanks!

J. Ambrose Little
Software Architect
BOKF Web Services
Click here to reveal e-mail address

******************************************************************************
The Company reserves the right to amend statements
made herein in the event of a mistake. Unless expressly
stated herein to the contrary, only agreements in writing signed
by an authorized officer of the Company may be enforced against it.
*******************************************************************************
Reply to this message...
 
    
Ryan Trudelle-Schwarz
We had one known issue which was that I had it calling Control_Load =
during the Load even when it should have been Init (or the other way =
around, can't remember). Typo on my part and I just haven't fixed it =
online yet. See if that clears it up.

I'll look into the ids, I seem to remember a way to disable the naming =
container property.

What's the problem with the relative paths? Can you give some more info =
on that?

-----Original Message-----
From: Little, Ambrose [mailto:Click here to reveal e-mail address]=20
=20
Hey all,
=20
We're implementing Ryan's solution on our site, but we're running into
difficulties. In particular, it seems that viewstate is not working on =
our
databound controls. I've made some modifications to Ryan's solution, so =
I"m
wondering if I should start w/ those, or if you could tell me if this is =
a
known issue w/ that solution.
=20
Also, since we're adding everything to a "template" user control, all of =
the
client-side IDs are written out as ctrl0_myControl or some such =
variation,
even if they're tecnically at the top level of the control. This kind =
of
makes sense, since everything is ultimately added to the "template" =
control
and then added to the page control collection. I'm just wondering if
there's a way to tell it not to render the top level control ID.
=20
Finally, it seems that ASP.NET considers the relative paths to be =
relative
to where we store the "template" user control, instead of relative to =
the
ASPX. Any way to overcome this?
=20
Thanks!

J. Ambrose Little

---
[This E-mail scanned for viruses by Declude Virus]
Reply to this message...
 
    
Daniel Naumann
Ambrose,

I've only played with Ryan's template a bit so I haven't experience the things
you're getting but he's my ideas anyway (even if they are long shots......)

For the viewstate, I remember that when playing with dynamically loaded user
controls, I had to put the control into session (or something equivalent) to
maintain state, otherwise when the page did the postback, it would reload a
clean version of the user control, hence losing state info. So o the postback I
had load my control from session.

I'm wondering if you're seeing this behaviour because the aspx page is reloading
a new version of the user control (that makes up the page from the template
class)??

Are the client-side IDs doing something bad, or is it just annoying?

For the relative paths....... can you put everything relative to the web root as
opposed to relative to the page? i.e. all images in /images/. That way
everything should be ok if the page containing the path moves.

Daniel.

-----Original Message-----
From: Little, Ambrose [mailto:Click here to reveal e-mail address]
Sent: 22-May-2002 07:53
To: aspngreuse
Subject: [aspngreuse] Page Templates Revisited

Hey all,

We're implementing Ryan's solution on our site, but we're running into
difficulties. In particular, it seems that viewstate is not working on our
databound controls. I've made some modifications to Ryan's solution, so I"m
wondering if I should start w/ those, or if you could tell me if this is a
known issue w/ that solution.

Also, since we're adding everything to a "template" user control, all of the
client-side IDs are written out as ctrl0_myControl or some such variation,
even if they're tecnically at the top level of the control. This kind of
makes sense, since everything is ultimately added to the "template" control
and then added to the page control collection. I'm just wondering if
there's a way to tell it not to render the top level control ID.

Finally, it seems that ASP.NET considers the relative paths to be relative
to where we store the "template" user control, instead of relative to the
ASPX. Any way to overcome this?

Thanks!

J. Ambrose Little
Software Architect
BOKF Web Services
Click here to reveal e-mail address

******************************************************************************
The Company reserves the right to amend statements
made herein in the event of a mistake. Unless expressly
stated herein to the contrary, only agreements in writing signed
by an authorized officer of the Company may be enforced against it.
*******************************************************************************

| [aspngreuse] member Click here to reveal e-mail address = YOUR ID
| http://www.aspfriends.com/aspfriends/aspngreuse.asp = JOIN/QUIT
Reply to this message...
 
    
Ollie Cornes

I think I've solved the naming issue in my templating code... you're welcome
to check it out...

http://www.aspnetui.com/

I've added a few bits to allow easy configuration of templates by
page/app/folder, but the core technique is pretty much the same as Ryan's. I
imagine you could wrench some of my code out into your app, and Ryan you're
welcome to do that too if you like.

I couldn't figure a way to disable the naming container, so I copied the
controls from inside the template into the page, rather than copying the
template control into the page.

Ollie

----- Original Message -----
From: "Little, Ambrose" <Click here to reveal e-mail address>
To: "aspngreuse" <Click here to reveal e-mail address>
Sent: Tuesday, May 21, 2002 10:52 PM
Subject: [aspngreuse] Page Templates Revisited

[Original message clipped]

**
[Original message clipped]

***
[Original message clipped]
Reply to this message...
 
    
Little, Ambrose
Ryan,

I've actually modified the way we're templating since I sent this. I'm
using a combination of your version and the version that was in VS Magazine.
I lay out the basic page layout in code w/ literal controls, and I use
placeholders for where to add the controls (this was the VS Mag way), and
then I used your idea of overriding the exposed control collection and
adding a load handler to automatically add controls declared in the
inheriting classes to the proper place on the template.

This way I avoid having to have everything sit inside of a user control
(eliminating two of the problems I mentioned--the annoying clientIDs and the
relative path problem), and I have noticed a performance increase. I've
also eliminated the need for two of the elements (the template interface and
the user control files), reducing the template to one class that all pages
inherit from.

Of course, I admit that the initial setup is a bit more involved, since I
have to write out the template in code, but I didn't find that to be
particularly hard for basic layout. And anything more robust (like our
"TopBar" stuff) can be put in an ASCX and loaded into the right place on the
template. I also understand that I sacrifice the ability to design multiple
templates and use them with the template interface, but I don't think that's
going to be a problem, since it's unlikely for us to change that often, and
even if we want to change it, we just have to change that template and
recompile, as opposed to modifying the old ASCX template. And if we, for
some reason, wanted to add (instead of modify) a template, we'd just create
another class file using the same method, instead of creating another ASCX
and "TemplatedPage" class that uses that template.

IOW, the only real sacrifice, IMO, is that I have to create the layout in
code instead of the designer. We did this by first designing the layout in
the designer and then just cut & pasting into the code editor. I think the
benefits (eliminating top-level control naming container & the path problem
and increased performance) outweigh this initial difficulty. Plus I think
it is a bit easier to manage (one class file instead of three class files,
an ascx file, and a resx file).

Anyway, don't get me wrong, I'm not trying to trash your scheme or anything.
I couldn't have come up with this w/o your help, and I think that the
judgment on the pros and cons for each method could differ depending on the
project and the developer. I just wanted to throw this out as another way
to do this and explain why I went this direction.

If anyone's interested in an example template class using this scheme, see
http://code.clanlittle.org/ShowCode.aspx?name=Epro.Templates.TemplateBase
(beware of URL wrapping)

Please check it out and see if you can think of any improvements, and also,
if my comments lead you to believe I'm not understanding something
correctly, please let me know.

Now, on to your comments. The only one I think may still apply to my scheme
is where to call the control load. As you can see in my code (linked to
above), I'm still loading the controls from the inheriting page classes at
the Page.Load event. Is this what should be moved to the Page.Init? I'm
not sure when this should happen.

Another thought I had was maybe that I should call base.OnInit first to
load, which I assume will load the viewstate for the controls on the page,
and *then* move the controls into the proper place on the template. I'm
guessing that maybe moving them is interfering w/ the viewstate restoration.
I'm going to try a few things like this, but if you can think of anything,
let me know.

Viewstate actually seems to work for the non-databound controls, and what I
believe to be an associated problem is that an event wire for a drop down
control in a repeater seems not to be getting wired.

E.g.
http://code.clanlittle.org//ShowCode.aspx?name=Epro.TriggerEdit

See the ddlForms control has an OnSelectedIndexChanged event handler
declaration, but with the template in use, this event handler is never being
fired, though it works when inheriting directly from Page. Any thoughts on
this would be appreciated.

Thanks!

--Ambrose

[Original message clipped]

******************************************************************************
The Company reserves the right to amend statements
made herein in the event of a mistake. Unless expressly
stated herein to the contrary, only agreements in writing signed
by an authorized officer of the Company may be enforced against it.
*******************************************************************************
Reply to this message...
 
    
Little, Ambrose
Ollie,

I thought about doing what (I think) you're doing--adding all the controls
from the template to the base page, but I thought that'd be too hard on
performance. See my recent reply to Ryan for the solution I came up with.

Thanks!

--Ambrose

[Original message clipped]

******************************************************************************
The Company reserves the right to amend statements
made herein in the event of a mistake. Unless expressly
stated herein to the contrary, only agreements in writing signed
by an authorized officer of the Company may be enforced against it.
*******************************************************************************
Reply to this message...
 
    
Little, Ambrose
----------------
See inline below.

[Original message clipped]

Well, if you read my recent reply to Ryan, I've changed my templating scheme
a bit, so this should not be the problem. I'm thinking it may be the event
order I'm misunderstanding.

> Are the client-side IDs doing something bad, or is it just annoying?

Mostly just annoying. I use stylesheets, and I use the ID references in
some cases (#clientSideID) to apply a style just to that ID, and I had to
have #templateControl_controlID to get it to work, which I find annoying. :)

[Original message clipped]

Yes, my coworker is actually the one who's discovered this, and I
recommended the same, but if there's a way to use relative paths
correctly... But as I said in my reply to Ryan, this has been resolved.

Thanks.

--Ambrose

[Original message clipped]

******************************************************************************
The Company reserves the right to amend statements
made herein in the event of a mistake. Unless expressly
stated herein to the contrary, only agreements in writing signed
by an authorized officer of the Company may be enforced against it.
*******************************************************************************
Reply to this message...
 
    
Ryan Trudelle-Schwarz
-> -----Original Message-----
-> Ryan,
->=20
-> This way I avoid having to have everything sit inside of a user =
control
-> (eliminating two of the problems I mentioned--the annoying clientIDs =
and
-> the
-> relative path problem), and I have noticed a performance increase. =20

I've been meaning to tune it for performance, I'll have to take a look =
at your code to see if there are any bits I can steal ;)

-> Of course, I admit that the initial setup is a bit more involved, =
since I
-> have to write out the template in code, but I didn't find that to be
-> particularly hard for basic layout. And anything more robust (like =
our
-> "TopBar" stuff) can be put in an ASCX and loaded into the right place =
on
-> the template. I also understand that I sacrifice the ability to =
design
-> multiple templates and use them with the template interface, but I =
don't=20
-> think that's going to be a problem, since it's unlikely for us to =
change=20
-> that often, and even if we want to change it, we just have to change =
that -> template and recompile, as opposed to modifying the old ASCX =
template.
-> And if we, for some reason, wanted to add (instead of modify) a =
template, -> we'd just create another class file using the same method, =
instead of
-> creating another ASCX and "TemplatedPage" class that uses that =
template.

One of the main points of separating the two is that the only =
requirement for using a new template is to make a new .ascx. Ollie =
exemplified this a bit by allowing for multiple templates in the =
web.config and just specifying them by a name.

Personally I see a web designer liking the .ascx method much better then =
coding the layout ;)

-> IOW, the only real sacrifice, IMO, is that I have to create the =
layout in
-> code instead of the designer. We did this by first designing the =
layout
-> in the designer and then just cut & pasting into the code editor. I=20
-> think the benefits (eliminating top-level control naming container & =
the=20
-> path problem and increased performance) outweigh this initial =
difficulty.
-> Plus I think it is a bit easier to manage (one class file instead of=20
-> three class files, an ascx file, and a resx file).

Agreed there, would be nice to trim out some of the files.

What was the change that removed the top level naming container? Are you =
using a different type of tag now?

-> Anyway, don't get me wrong, I'm not trying to trash your scheme or
-> anything. I couldn't have come up with this w/o your help, and I =
think=20
-> that the judgment on the pros and cons for each method could differ=20
-> depending on the project and the developer. I just wanted to throw =
this
-> out as another way to do this and explain why I went this direction.

Heh, no worries ;) It's interesting to see different takes on the =
techniques. I'm not trying to sell it or take over the world with it or =
anything ;)

-> If anyone's interested in an example template class using this =
scheme,
-> see
-> =
http://code.clanlittle.org/ShowCode.aspx?name=3DEpro.Templates.TemplateBa=
se
-> (beware of URL wrapping)

-> Please check it out and see if you can think of any improvements, and
-> also, if my comments lead you to believe I'm not understanding =
something
-> correctly, please let me know.

-> Now, on to your comments. The only one I think may still apply to my
-> scheme is where to call the control load. As you can see in my code=20
-> (linked to above), I'm still loading the controls from the inheriting =

-> page classes at the Page.Load event. Is this what should be moved to =
the=20
-> Page.Init? I'm not sure when this should happen.

Yes, IIRC performing the Control_Load (or whatever you have it called =
now) during the Init event will allow the controls to participate in =
post backs where doing it in the Load won't. Not sure about that though =
as this is second hand knowledge...

-> Another thought I had was maybe that I should call base.OnInit first =
to
-> load, which I assume will load the viewstate for the controls on the
-> page, and *then* move the controls into the proper place on the =
template. -> I'm guessing that maybe moving them is interfering w/ the =
viewstate
-> restoration. I'm going to try a few things like this, but if you can
-> think of anything, let me know.

Since the controls are staying within that Page it shouldn't be a =
problem since it will use the same Viewstate bag.

-> Viewstate actually seems to work for the non-databound controls, and =
what
-> I believe to be an associated problem is that an event wire for a =
drop=20
-> down control in a repeater seems not to be getting wired.

Try moving the Loading method to the other event and see if this fixes =
the prob.

-> Thanks!
->=20
-> --Ambrose
->=20

---
[This E-mail scanned for viruses by Declude Virus]
Reply to this message...
 
    
Little, Ambrose
See inline.

[Original message clipped]

Yes, multiple templates would have to be created and changed through
compilation instead of web.config. Both require an app restart, so IMO the
only benefit of using web.config is that you don't have to recompile.

[Original message clipped]

Well, two things, the designer could design the template(s) first and the
coder could copy&paste that. Second, if the template is limited to basic
layout using placeholders, the designer could still create controls (ascx)
for the various places, such as the top bar, the left nav, etc. Kind of
like you have done on your site I think. The basic structure of where the
placeholders go is not likely to be that complex or change that much.

[Original message clipped]

We're adding everything to the page directly, instead of adding it to a user
control and then adding that control to the page.

[Original message clipped]

Unfortunately I've now tried moving the control hierarchy creation all over
the place w/ no success. There seems to be a disconnect somewhere when
ASP.NET tries to restore the state through viewstate. What's really messing
w/ my head is that viewstate is restored just fine for the textbox, but the
drop-downs and repeater controls are not being restored. I'm thinking it's
having problems because the controls on postback are not exactly the same
hierarchy as they are in the ASPX. How does ASP.NET know what viewstate
goes with what control? Why does it connect the textbox but not the
dropdown or repeaters?

TIA,

--Ambrose

******************************************************************************
The Company reserves the right to amend statements
made herein in the event of a mistake. Unless expressly
stated herein to the contrary, only agreements in writing signed
by an authorized officer of the Company may be enforced against it.
*******************************************************************************
Reply to this message...
 
    
Simon Jones
Did anybody find a solution to the ID's being munged?

--------------------------------
From: Simon Jones
Reply to this message...
 
 
System.Web.UI.Page




ExamGuru IT Solutions - .Net Guru is owned and operated by ExamGuru, Inc., the man behind .Net Guru. If you're in the market for bespoke software or software consultancy, why not get him and his highly trained team to help? - www.examguru.net/ITCertification
Ad


Need Dot Net Interview Questions?
Ask ExamGuru, Inc. for advice and help on Passing .Net Interviews
.Net Projects
Best-of-breed application framework for .NET projects, developed by ExamGuru, Inc. and ExamGuru IT
Free .net Help
Commission ExamGuru, Inc. and his team for your next bespoke software project
FogBUGZ
The only bug tracking system carefully crafted with one goal in mind: helping teams create great software.
Awesome Tools
If you don't know about these, you're missing out... IT Certification Questions
IT Interview Questions
Free Oracle 10g Training
MCSE Boortcamp
Cisco Study Guides
Cheap Study Guides
Exact Questions
Dot Net Interview Questions
Oracle OCP
Cheap Travel
Designer Perfumes - Wholesale Prices
Free Programming Tutorials
 
ExamGuru IT Solutions - .Net Guru is owned and operated by ExamGuru, Inc., the man behind .Net Guru. If you're in the market for bespoke software or software consultancy, why not get him and his highly trained team to help? - www.examguru.net/ITCertification
 Copyright © ExamGuru, Inc. 2001-2006
Contact Us - Terms of Use - Privacy Policy - www.dot-net-guru.com - www.examguru.net - www.oraclesource.net - www.itinterviews.net - www.examguru.net/ITCertification