I have a user control which when added to the markup via the Toolbox or manually typing
<myNameSpc:myCtrl ... I would like to spit out:
<myNameSpc:myCtrl>
<template></template>
</myNameSpc:myCtrl>
I remember doing this for windows workflows and it involved implementing something like a TypeConverter and WorkflowXmlSerializer so it maybe possible for user controls as well I'd guess ? the only thing is that I don't have time to research this matter now, so I was wondering if anyone would be kind enough to point me in the right direction so that I don't have to dig deep into the designer serialization of VS (which I remember was a big pain).
For your custom control, you can specify a ToolboxDataAttribute which defines the default html that will be generated when you drag a control onto the design service. E.g.:
[ToolboxData("<{0}:myCtrl runat="server"><template></template></{0}:myCtrl>")]
public class myCtrl : System.Web.UI.Control
{
}
For the manual generation you can create a Code Snippet. The best way to do that is find existing ASPX snippet and modify it to gen your control. I'm assuming you are using VS 2010.
Related
I have a web app that has a form on just about every page. In order to make sure each form renders the same, as to make changes easier, I want to render all of my form controls in c# in a central place so if I need to add a class to the input or change something, I only have to do it once.
At the moment, I am just using a load of static classes like TextInputHelper, CheckboxInputHelper etc that use StringBuilder to build up the HTML and returns a string to my view.
For example, all of my forms controls are of the basic form:
<section>
<label class="label">Label Text</label>
<label class="input">
...Input Element...
</label>
</section>
What I would like to do is improve this situation as I still have a lot of duplication between the different helper classes, particularly for the wrappers to the form elements. My initial thoughts are to have a class called something like BaseFormControl that has a virtual Render method that has the outer wrapper for the control, then create other classes that implement this to do specific things like a TextFormControl that puts
<input type="text".....
inside the wrapper.
Am I on the right path for this, and/or is there a design pattern that is appropriate for what I want to do?
From my POV what I read is that you over complicating your server side just because of a CSS/HTML standardization that be easily solved from the client side.
If you still want to go for the server side approach the pattern that seems to apply to your approach is the Adapter(Wrapper) pattern meaning that you probably would want to create control wrapper clases to meet your needs for each control that renders a different html from what is offered by ASP.NET built-in controls.
If what you want to do instead is to format a group of controls then a UserControl is way much better approach.
Remember that ASP.NET was build with the spirit of trying to keep layers separated the View from the Code therefore any attempt to generate html from the server side has to be an exception and not a rule.
I have two user controls that sit on a page which determines which should be displayed. The user controls generate some html that is passed into an asp:literal and subsequently manipulated via javascript. It is done this way due to the lack of a suitable control that I am allowed to use on the project.
When a user clicks a view change button, a WebMethod is called on the main page (the one that holds the controls) from the control's javascript. From here, a static method on the control is called. The control then needs to regenerate the html and place it into the asp:literal for the view change to be complete.
My problem is that I am in a static method on the control's page, and have no access to the non-static genorateHtml function. I have tried a singleton pattern with no success (this could have been due to improper implementation). Any ideas on how to make this call? THANKS!
I used to hit similar issues at with one of the projects i worked on. The solution we ended up adopting was implementation of System.Web.UI.ICallbackEventHandler with partial rendering to return just the needed content depending on arguments. ICallbackEventHandler runs in the page lifecycle.
The only trouble we had then was performance issues relative to implementation which posts back the whole form instead of just the arguments you want.
Maybe the best way for you would be through this method in which they render the control from a static method. That would probably suit your needs.
Hope this helps!
I get this error when I try to have my C# class change the skin of an asp control:
The 'SkinId' property can only be set in or before the Page_PreInit
event for static controls. For dynamic controls, set the property before
adding it to the Controls collection.
My goal is to provide a panel, call it ID="response", on every page, and then dynamically change it's CSS class from Error to Success, or Success to Error (so it's red or green). And also I make it visible = true, when a response is created.
Apparently, I am forced to use CssClass attribute, which is the only way this will work.
As a side-off-topic note:
In PHP, you would not have a problem of using different "pre-init" "post-init" etc. A completely unnecessary process. You would simply change the html before you send it back to the user. I'm a bit confused why ASP.NET decides to overcomplicate everything. It's a bit silly for me to take time to learn all these different complicated processes to simply display a webpage. It takes time to learn all the quirks written in difficult-to-read ASP life-cycle documents on microsoft. Not to insult any microsoft people, but it's just not practical.
If it is a static control, that is you are defining the Panel in your .aspx page, then the only place to change the SkinId is in the PreInit method e.g.:
protected override void OnPreInit(EventArgs e)
{
base.OnPreInit(e);
String panelSkin = ViewState("panelSkin").toString();
panel1.SkinId = panelSkin;
}
Of Course, the PreInit method is only called when the Page is being first Initialized -- not on a PostBack.
You could save the skinId you wanted to use to the ViewState and then call a Response.Redirect("myPage.aspx")... and as seen above grab the skinId string from the ViewState and set the Panel skinId accordingly.
Alternatively, rather than using a Panel try using an UpdatePanel from the .Net Ajax library. Clicking a button in the UpdatePanel (provided it's setup to Trigger an ASyncPostBack) will run the OnPreInit method.
That said, provided you are changing the background, going with the CssClass property would be the most efficient way to do this.
ASP, and its child ASP.NET, is basically a huge hack of vanilla HTML and the IIS page renderer. It hooks into various stages of the lifecycle that already existed in IIS, rather than having its own lifecycle like PHP. As such, there are things you can do in certain areas because the things it depends on either aren't set in stone so you can change them, or are so you can work with them. The great power of ASP.NET, which is the interop with .NET classes and the .NET Framework, IMO makes up for some of its idiosyncracies.
Anyway, Skins are part of Themes, which are loaded early in the process so the controls can be initialized with their proper default Styles. That's the key; the Theme is locked after PreInit, but the Styles (and CssClasses) behind the Skins are editable right up to and including PreRender, which includes event handlers (which fire validation). So, set the Style or the CssClass dynamically.
To do it without a full postback, you can put the controls that should change color in an AJAX UpdatePanel, which can be re-rendered separately from the other elements of the page and will keep its current contents until the DOM is modified via the JavaScript client-side.
Setting the CssClass attribute is much closer to what you'd do with PHP, so why not just do that?
The two real benefits of Skin files are setting defaults for all controls (no skinId at all) or setting properties that can't be controlled with css.
I'm wondering if anyone has any experience converting User controls to Web controls?
Ideally, I'd like to offload some of the design work to others, who would give me nicely laid out User Controls. Then, I could go through the process of converting, compiling, testing and deploying.
Until MS comes up with the magic "Convert to Server Control" option, it looks like I'm pretty well stuck with re-writing from scratch. Any ideas?
Is there a reason you must convert these user controls to server controls? Remember that it is possible to compile a user control into an assembly.
You are right there is no magic bullet here but since you already have a User Control its not that difficult.
Make sure all properties, events, etc. are set in the code behind since you won't have any mark up when you're done
Create a new Server Control
Paste all of the event handling and property setting code into the new control
override the Render method for each child control call the RenderControl Method passing in the supplied HtmlTextWriter
protected override void Render(HtmlTextWriter writer)
{
TextBox box = new TextBox();
//Set all the properties here
box.RenderControl(writer);
base.Render(writer);
}
I searched for hours and found many blogs about it.
The only thing worked for me was this article https://blogs.msdn.microsoft.com/davidebb/2005/10/31/turning-an-ascx-user-control-into-a-redistributable-custom-control/.
It says self-contained with given restrictions, but it does not mentions that the codebehind must be included in ascx file.
I used a Web Site project (not Web application!) and had to inline the code behind into the ascx file and only use control directive like:
<%# Control Language="C#" ClassName="MyPackage.MyControl"%>
So basically i just have a single file left for the user control. When codebehind was a separate file all control's where null when i referenced the final dll.
I also tried http://blog.janjonas.net/2012-04-06/asp_net-howto-user-control-library-compile-dll-file but with reflection the ascx file could not be found.
I need to expose some input fields based on what properties I find for particular types in an assembly.
I'm not sure how common an approach like that is. Perhaps there are easier ways. Maybe on the client side instead of server.
If anyone knows of a good way of doing something like this, I would appreciate the help.
Create input controls accordingly and simple add control to some div container? I'm not sure if it would be more complex than that.
I'll need to somehow add css classes to the controls as I build them so they get placed nicely; that might get tricky.
This all sounds like standard asp.net development. Any good tutorial should be able to help you. For the asp server controls, you use the CssClass property to set the class for the control.
Here is the asp.net tutorial from the W3C Schools.
I assume you will use reflection to figure out what properties entity has, then you would based on the type of the property create an input field. You would have to dynamically create control to handle input in code behind. Make sure you give that control and id. You will have to recreate these controls on the post back. This looks to me like dynamic property editor. There might be some free ones, google for it.
If the UI doesn't have to be completely dynamic you could include all the controls in the markup with any optional ones set to Visible="false". Then, selectively enable the appropriate controls in your code-behind. For example:
Default.aspx
<asp:Button ID="EvenButton" runat="server" Text="Even" Visible="false" />
<asp:Button ID="OddButton" runat="server" Text="Odd" Visible="false" />
Default.aspx.cs
protected void Page_Load(object sender, EventArgs e)
{
String msg = "A message to count";
if (msg.Length % 2 == 0)
{
// Enable the Even Button
EvenButton.Visible = true;
}
else
{
OddButton.Visible = true;
}
}
The advantage of this method is that you can lay things out with the appropriate CSS easily in the markup. If, on the other hand, your UI is much more dynamic than this, you'll probably have to resort to dynamically creating controls in the code-behind and adding them to the page via calls to Controls.Add(). This way, however, is harder to layout. And you have to deal with things like re-wiring any event handlers on each postback.
Hope that helps.
I ended up leveraging jQuery.
I laid out a simple markup with the basic layout I would need.
For creating controls dynamically, I did it all in javascript using jQuery methods.
This of course requires that you return some data set to the UI intelligently enough to render it.