|
|
Rank: Advanced Member
Groups: Member
Joined: 10/15/2008
Posts: 45
|
Hi there,
I've been struggling for a while with entire Master page reloading with every Postback caused by some child controls, so decided today to investigate your renowned alternative: CallbackPanels hoping for a feasible resolution.
Unfortunately, your relevant documentation is very brief, and the one about Triggers is even shorter. Consulting your Car Demo made me more confused since the code-behind leverages creating a new class then building its properties! Is it that complicated to work with CallbackPanels?
Situation:
I have an aspx page (Codes.aspx) that opens into a childMaster that opens into parentMaster. Codes.aspx features a TreeView and a block of controls to manipulate TV data: a DropDownList and 3 TextBoxes.
Background:
When selecting a childNode, block controls need to be updated with info of selectedNode, then display said info. I have all of that functioning fine, including passing parameters among.
Additionally, a set of buttons are also utilised to Insert a new Node, Save changes made to Node info and Delete a particular Node. After each modification, the TV needs to be updated as well reflecting changes. That also is working fine. I'm happy with functionality except for the annoying reload of entire Master page on every Postback.
Attempted:
So, I encapsulated the TV inside a CallbackPanel (ID=TV) and used another CallbackPanel (ID=Content) as a container of other controls (excluding the buttons). Then created the Execute handler of TV Panel, but couldn't proceed further. Couldn't figure how to integrate my already functioning routines with Panel handlers and Triggers.
I wish to maintain same functionality but with partial page reload as anticipated. Is it a must to define Triggers for each Panel? Do I also need to create a class as you demonstrated in the Car Demo to be able to work with CallbackPanels?
What does the Execute handler exactly perform? What does it tell the Panel to do? How is that linked to defined Triggers in Panel declaration?
Appreciate a more deeper explanation. I'll be happy to provide any code if necessary. BTW, I'm using VS2005 with 2.0 framework (VB).
Regards,
Saed Hamdan
"Man may be destroyed but not defeated" -Hemmingway
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,194
|
Hi,
Using trigger is not a must, but it's easier than handling the CallbackPanel's Execute event. This is because when a trigger is used, it automatically dispatches to the trigger's event handler. So if you have multiple triggers that do different things, you do those different things inside their respective event handlers.
The other difference of using trigger is, Execute event is called during render stage (for backward compatibley purpose), while trigger event handler are called during "normal" event handling stage. Usually this does not pose a problem though.
The "Cars" example uses an additional class purely for data access. It has nothing to do with CallbackPanel.
In addition to Execute and event handler, you can always handle the case in your Page_Load or Page_Init. You would check whether the current request is a CallbackPanel request and then decide what to do. This method is usually used together with eo_Callback on the client side. You can take a look of our sample project and see how it works. Our sample project uses a CallbackPanel to load sample when user clicks a node in the TreeView.
It's most likely that you will need to use a combination all these techniques. You may also need to use the "Group" feature. The group feature allows you to "Group" two or more CallbackPanels together so that when one is triggered, others will also be updated. You can use these features by setting the CallbackPanel's GroupName property.
Hope this helps.
Thanks!
|
|
Rank: Advanced Member
Groups: Member
Joined: 10/15/2008
Posts: 45
|
eo_support wrote:Using trigger is not a must, but it's easier than handling the CallbackPanel's Execute event. Not for me I'm afraid as I don't want to also begin coding in JS. Enough the VB coding I'm handling in the code-behind. Imagine in the middle of your work you have to drift to another discipline and start mastering! It won't be a problem for me to do some extra coding if necessary to have everything in VB, including creating trigger handlers, unless JS is a must?! I checked your Sample project and noted how it functions. However, the eo_Callback must be called inside a JS function. Speaking of Sample project, there is a declared function that is apparently not called anywhere: GoToDemo(nodeId, tabPageToShow). Is it so or I'm missing something here. The bottom line is that I only wish to have everything in VB rather than using a combination of all these techniques as you said. Would that be possible? One more thing I noted. I'm using ASP TreeView. Most of the ClientSide functionalities and properties used with your TV are not supported by ASP TV. So, either I switch to your product dropping ASP TV (and consequently, rework all the properly functioning code) or start tweaking your code to suite ASP TV. What a situation and what a marketing strategy guys! (Thumb up) Thanks. Regards,
Saed Hamdan"Man may be destroyed but not defeated" -Hemmingway
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,194
|
Hi,
I am afraid that you are a bit off on this. I do not believe the JS functions have anything to do with marketing. It's all about features. ASP.NET programming generally falls into two categories: server side (code behind) and client side (JavaScript). Each side has its strength and drawbacks. The most important strength of server side code is that it runs on the server side, so it can access all your backend stuff; The most important strength on the client side is that it runs on the client side, so that it can response instantly. As an example, if you wish to perform some task when a button is clicked, it can be done on the server side; If you wish the button to turns blue when mouse hovers over it, you’d better do it on the client side. So usually the situations dictate which interface you would be using, or prefer to be using.
Traditionally MS has been focusing more on the server side because ASP.NET is a server technology. However for a lot of cases, client side coding works much better. Thus we fill the gap by offering much stronger client side interface. In another word, we offer features that MS does not offer.
So the reality is that if you need to have client side JavaScript capability, you choose a product that supports it. If you do not know JS, you try to do everything with code behind till you either succeed in meeting all your requirements, or hit a wall when you realizing things can not be done all with code behind ---- this is well possible because JS interface exists as additional features, not as replacements to server side interface. It is completely wrong to think that each JS feature has a server side counterpart. We offer both server side and client side interface and both are well documented and demonstrated with our demos. In the case of CallbackPanel, you either use triggers or use JavaScript (through eo_Callback) to trigger the callback. So it’s fairly straight forward for you. If trigger works for you, great. If trigger doesn’t work for you, then you may have no choice but to work with JavaScript. JS syntax is fairly simple and straight forward. So it should not be difficult for you.
Hope this clarifies any confusion you may have.
Thanks
|
|
Rank: Advanced Member
Groups: Member
Joined: 10/15/2008
Posts: 45
|
I think I should have clarified my situation a little bit more...
The issue is not using JS or not, nor it is the lack of knowledge. We market an application that was developed as Windows-Forms. My Boss handed me the source to migrate it into Web Forms, with strict instructions NOT to change the source code or implemented functionalities, except for what is deemed necessary for the sake of migration only.
In many situations I realised that implemented code could become more efficient if we drop this or add that, to end up with my Boss rejecting all of that and insisting on sticking to original code. He has a point though. Since my role is to pave the road and set the roadmap so he and other team members could proceed in the migration, they don't wish to rework entire original source, baring in mind that my Boss was the sole developer of said application!
If I'll suggest to him now to inject JS ClientScript and alter original code accordingly as the mean to overcome annoying frequent reloads, can't predict the outcome. I hardly managed to convince him to drop utilising Frames to the favour of Master pages. The bulk of application pages leverage similar structure to what I presented, with lots of TVs and GridViews.
I hope you got the picture now.
Regards,
Saed Hamdan
"Man may be destroyed but not defeated" -Hemmingway
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,194
|
Hi,
I see what you are trying to do. Obviously we are not in a position to make suggestion on your migrating strategy. From our point of view, we merely point out the options that are available to you, and each options' purpose, scope and limitations should you are interested. You will be the one that decides and implements. We do not feel it's realistic to expect converting a WinForm application to a Web application without considerable code change though.
Thanks
|
|