Master Pages and methods

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hello,

I have a Master Page with a ImageButton and a Click event associated with.
Then, I've created some pages based on this Master Page.
I need to change the action of Click event will perform depending of the page.

For example: If my page (based on the Master Page) is a customer register, I
need that the ImageButton click event call 'RegisterCustomer()' method. If is
a page with an employee register, I need that the ImageButton click event
call 'RegisterEmployee()' method.

I've tried override the ImageButton Click event in the page, but
unsuccessfully.

How can I do it?

Thank you.
 
How can I do it?
Click to expand...

Sounds like you need to re-think your architecture a bit...

MasterPages are, essentially, a way to provide a uniform look and feel for
your site, and to provide any functionality common to most if not all
content pages. If every content page needs to modify the functionality of
the MasterPage in some way rather than, say, changing the Header.Title
property, then you might question whether MasterPages are the best way to
implement your site.

Certainly, if each content page needs a button which performs an action
unique to that page, then move the button out of the MasterPage and into
each content page.
 
Ok! I understand you, but a question.

This button should exist in all pages and the button is a UI component,
then, the MasterPage is the best place to put the button.
The problem is: each page needs a different button's action.

Is better put the button in the page? If I need, for example, change the
ImageUrl property of ImageButton? If the button is in one place, I will need
to change in one place only.
 
This button should exist in all pages and the button is a UI component,
then, the MasterPage is the best place to put the button.
Click to expand...

No it isn't - the best place is in each content page.
The problem is: each page needs a different button's action.
Click to expand...

That's why the best place is in each content page.
Is better put the button in the page?
Click to expand...

In the content page, yes...
If I need, for example, change the ImageUrl property of ImageButton?
So...?

If the button is in one place, I will need to change in one place only.
Click to expand...

There is a Find and Replace feature in Visual Studio.NET...
 
How is the determination made whether it's a customer register, or an
employee register?
(by the name of the page?)
 
Hi Bruno,

You can certainly put the button in the master page - read up on events and
delegates! (then each content page must "subscribe" to the event called by
the master page).


Regards,
Nils Magnus Englund
 
You can certainly put the button in the master page
Click to expand...

He certainly can - never said he couldn't...
- read up on events and delegates!
Indeed.

(then each content page must "subscribe" to the event called by the master
page).
Click to expand...

Exactly, so he may as well have the buttons in the content pages...
 
What's the problem here? The ImageButton has its own click event handler.
The ImageButton goes into the HTML of the MasterPage. Display design view
and double-click the ImageButton. The click event handler will be generated
in the code for the MasterPage. The logic to call the registration methods
can be done like this...

protected void RegistrationImageButton_Click(Object sender, EventArgs e)
{
// Get the name of the content page loaded when the image was clicked
string pageName = Request.ServerVariables("SCRIPT_NAME");

switch (pageName)
{
case "/customers.aspx" :
RegisterCustomer( );
break;
case "/employees.aspx" :
RegisterEmployee( );
break;
default :
// whatever
break;
}
}

However...
I would do it a bit differently if an entire registration page should be
used which is often a better idea so more content about registration can be
displayed to the user who is registering to be assigned to a role such as
the customers role or the employee role.

switch (pageName)
{
case "/customers.aspx" :
Server.Transfer("~/RegisterCustomers.aspx");
break;
case "/employees.aspx" :
Server.Transfer("~/RegisterCustomers.aspx");
break;
default :
// whatever
break;
}

If registering a customer I would then call the RegisterCustomer( ) method
from the Page_Load event of RegisterCustomers.aspx.

protected void Page_Load(object sender, EventArgs e)
{
// Call the method in the page it belongs to
RegisterCustomer( );
}


<%= Clinton Gallagher
NET csgallagher AT metromilwaukee.com
URL http://clintongallagher.metromilwaukee.com/
MAP 43°2'17"N 88°2'37"W : 43°2'17"N 88°2'37"W
 
Hey Bruno,

Nils Magnus Englund had it right. Not to contradict anyone here who
told you that isn't the way to do it, but how would you implement a
save button for your app? Certainly you wouldn't place a save button
for each page?

Anyhow Bruno, here' s how you do it without custom event args. You
only need to define a delegate if you need them.

first you add a public event handler to your master page
public event EventHandler Save;

next you click into the master page event and fire the event
notification like this. I'm using a button.

protected void Button1_Click(object sender, EventArgs e)
{
Save(this, EventArgs.Empty);
}

now you just add the event listener to each page like this:

protected void Page_Init(object sender, EventArgs e)
{
this.Master.Save += new EventHandler(Master_Save);
}

void Master_Save(object sender, EventArgs e)
{
//your code here!!!
}

don't forget to add the MasterType attribute to each content page.
Otherwise you won't be able to reference the event directly.
<%@ MasterType TypeName="MasterPage" %>

ENJOY!!!
 
Nils Magnus Englund had it right. Not to contradict anyone here who
told you that isn't the way to do it, but how would you implement a
save button for your app? Certainly you wouldn't place a save button
for each page?
Click to expand...

Well, your entitled to your opinion, but I disagree totally with it.

In my opinion you most certainly WOULD put a Save button on each content
page, especially if that button did different things e.g. worked with
different data, called different stored procedures etc.

If I'm trying to debug code-behind, the very last thing I want is an extra
layer of complexity whereby the code has to work out which content page is
calling it before deciding what it actually needs to do... Even worse, what
if I need to apply different client-side attributes to the button, maybe to
pop a JavaScript confirm before a deletion etc...?

Where do you draw the line...? Why have any controls in the content page at
all? Why not simply put an <asp:Literal> in there and write code behind your
MasterPage to fill it with various content depending, er, on the content
page...? At that point, you may as well not use MasterPages at all...
 
Well, your entitled to your opinion, but I disagree totally with it.
In my opinion you most certainly WOULD put a Save button on each content
page, especially if that button did different things e.g. worked with
different data, called different stored procedures etc.
Click to expand...


Hey Mark, I'm not arguing with you. There is definitely some line you
draw when deciding your approach. However, this guy wanted to know how
to do it, not why he shouldn't do it.

Also, if I follow your thinking as stated, then we should probably do
away with base classes and interfaces right? They also allow you to
define a different action for a method as well....

Again, I wasn't trying to say your approach is bad, because your
argument is valid. Developers should always consider the angles when
making a design decision.
 
Hey Mark, I'm not arguing with you. There is definitely some line you
draw when deciding your approach. However, this guy wanted to know how
to do it, not why he shouldn't do it.
Click to expand...

That's true, but that's already been answered...
Also, if I follow your thinking as stated, then we should probably do
away with base classes and interfaces right? They also allow you to
define a different action for a method as well....
Click to expand...

:-) No, I wouldn't go that far... :-)
Again, I wasn't trying to say your approach is bad, because your
argument is valid. Developers should always consider the angles when
making a design decision.
Click to expand...

It's just opinions at the end of the day... My yardstick is always if it
makes it easier to develop and manage, unless it's *seriously* inefficient,
that's probably the best approach. The KISS principle...

Obviously, in this particular instance, there's very little difference at
the end of the day - certainly, no difference to the end user, and no matter
where the button(s) is/are stored, there'll only ever be one of them sent
down to the client per page...
 
Back
Top