I'm workin on my first webpart.
I use some number of user controls as screens. And I have a trouble here.
First screen contains a list of dynamically created options (hyperlinks). After user made a decision with click, I want to change the screen and pass to the new screen some parameters.
My dicision is to load all controls I need on webpart creation. Controls I don't need right now I make invisible.
SomeUserControl1 uc1 = (SomeUserControl1)Page.LoadControl("~/_controltemplates/SomeUserControl1.ascx");
SomeUserControl2 uc2 = (SomeUserControl2)Page.LoadControl("~/_controltemplates/SomeUserControl2.ascx");
uc2.Visible = false;
Controls.Add(uc1);
Controls.Add(uc2);
Option in first user control realized as LinkButtons (serverside). OnClik event calls a special method in the webpart class and in this method i change a visibility of my user controls and pass some parameters to usercontrol2.
I don't like this approach. Are there different ways to realize described functionality?
Thanks!
You need use a ASP.NET Wizard Control, it does what you exactly you want.
From a design standpoint what you are doing looks a little bit frightening. You should think about nesting the various user controls into a single user control that you can use as the face of your webpart. Keep the coupling between the various user controls loose and think about implementing the Observer pattern if you need to do things like playing with control visibility.
Related
The Situation: I've got a mid-sized chunk of html/javascript that contains an authentication script/input (it's a text input, radio control, and a combo box and a few buttons). What it is is less important than the concept that it's a mass of static client side code that the marketing department can pretty easily accidentally the whole thing.
The Desire: I want the users to be able to add it as a whole to a page, but not be able to modify it. When something needs to change, I want to change it in one place and have it be changed on all the pages.
What I've Tried: Widget with a default text. It works, but feels wrong. Users can edit it, and if they do when I fix it one place it doesn't propagate to all the instances. I'm a bit of a Kentico noob, but it seems like there should be a better way to do this.
Also note: I'm using portal engine if that makes a difference.
A widget is the proper usage. What you make your widget inherit from is the key in this case. I'd suggest creating a new widget based on a static HTML webpart. This way you can set the static HTML markup and hide the property from the content editor on the front end. You can do this by going to the Properties tab of the widget and setting the visibility of the field on the form. Don't delete the field, just hide it. It should be a checkbox that says hide on public form or editing form.
** Edit **
As I read through my answer and comments, I realized I meant to say clone the static HTML webpart and set its default text to your javascript. Then create a widget based on that cloned webpart. The text will reside in the web part and will allow you to update it in one place later, if needed.
I will not do it this way because you will be not able to make changes in the future. You can better create a new webpart this can be an empty webpart and then create a custom layout. In this layout you can put you're code. In this way you can always change you're code in the future and then it will be changed on all the places where the widget is placed.
I'd use a new widget based on the Static HTML webpart (make the field read only or hide it as Brenden mentioned), but store the data in a new custom setting.
no coding needed (only a macro to read the custom setting)
able to edit the script on the fly on any instance in the settings module. If you have multiple of these settings you won't need to go through all kinds of widgets to adjust their default setting but find them on a central place.
Cheers!
David
In this case I think it makes sense to create a custom web part to store all your code in it and use it that way. If you want to achieve it without creating a custom web part, you have to store the code in some non-web part and not widget specific object. I like the suggestion of creating a custom setting. You can then access this custom setting via a macro. This macro can be used as a default property of a newly created web part (inherited e.g. from the static text web part, you'd use the text property). You may as well create a widget out of it. Another approach is to use Kentico localization keys as a workaround. you can create a key in the Localization application and access it again, via a macro, e.g. {?customkey.myhtml?}. The approach with a custom setting however sounds cleaner to me.
This syntax should be working to access a custom setting value via macro:
{%Settings.CustomSettings.xxx%}
{%Settings.CustomSettings["xxx"]%}
{%Settings.CustomSettings.GetValue("xxx")%}
I am creating a new footer sublayout in sitecore for use in multiple sites (we run a multi site environment). Currently a sublayout called StandardLayout is used, but I would like to change this across several of our sites to a new layout GlobalFooter.
The problem is that child items of the Home Page have overridden layout components, so what I would like to know is if there is an easy way to change the layout without losing all of the overridden components (as I expect that I may need to reset the layout in order for the flow down to occur)?
I am hoping to be able to just change the top level element (Home) and then have this flow down to the child elements, otherwise this task will become very long and tedious if I need to go through each item and change the presentation to use the new footer.
The icon circled in red in the image above indicates that the presentation has been overridden for that particular sitecore item.
To answer your question, directly, there is no way to apply an update of the presentation details of a template to templates that inherit from it that have had their presentation details changed without losing the changes.
The solution described in the blog post you linked to is the best solution for updating inherited presentation details in this manner. IMHO, I believe that this functionality should have been built into Sitecore long ago as a separate button on the ribbon, and you may choose to add one if you are so inclined. If you do not have the time to do so however, creating an admin page that you later delete from the site after using is a perfectly viable solution as well.
This post appears to detail a way that I can achieve my goal, basically I would create a admin page that does not publish and put the code in the blog into it to update the layout via a button trigger.
https://www.sitecore.net/Learn/Blogs/Technical-Blogs/John-West-Sitecore-Blog/Posts/2011/09/Programmatically-Update-Layout-Details-with-the-Sitecore-ASPNET-CMS.aspx
Okay... this is a little difficult to explain but I will try my best.
In Custom Control while adding properties in Property Definition we can set "Allow multiple instances" which allows us to add multiple instances of that property when the control is embedded in XPage.
Similarly, I need to know whether it is possible to add (and remove) Editable Areas in a custom control when it is embedded in XPage? What I plan is that I would have a repeat control inside my custom control and I would be able to put the contents in each editable area in every loop of that repeat.
Is this the right way to go about or am I looking at this problem incorrectly? Any solution not involving editable areas is also welcome :)
Update 4 Apr 2013:
A use case context I am looking for is a simple carousel where contents of each screen in carousel can have different contents. These contents would be put into each (dynamically added) editable area. The contents can be very different from each other with one screen containing only text, other only image and another both image and text.
Look at the table walker example in the 26 original exercises. It does mostly what you are looking for (conceptually). You won't need multiple editable areas. Whatever is inside the repeat gets repeated.
What you want to do is to give the control a custom property "boolean editMode" so you can render that one line to be edited - if that's the UI pattern you want to follow.
You also could consider a dojo table with Ajax which allows for a familiar spreadsheet UI
I have a simple ContactEditPanel which contains a form and a number of textfields. Up until now I included an AjaxSubmitLink in this panel which, if the form content is valid, saves/updates the Contact instance contained in the Panel model. So far so simple. However now I'd like to remove the link in order that I may, depending on the context in which I use the ContactEditPanel, place the submit link at different levels of my overall component hierarchy. For instance in one context I'd like to use to flip between ContactEditPanel and ContactViewPanel with a bar of actions above the current view (edit | save , cancel). Another context would be to use ContactEditPanel in a standalone way (maybe part of a multi-step process) with just a save link below.
I was contemplating refactoring my ContactEditPanel to extends FormComponentPanel rather than Panel as described here but I'm not sure whether this is the right approach and I'm having trouble wrapping my head around this.
Any help would be most appreciated!
Many Thanks,
A
Your using the panel like a FormComponent so extend FormComponentPanel, it will allow you to keep all the validation you write contained to the component and also allow you to reuse it as you wish.
Just think of it as you've created a new FormComponent, like a TextField or DropDownChoice.
I want to able to create reusable user controls within my web app and i'm wondering on how to go about doing so.
Should a user controls properties be
visible to a form that's using it?
What's the best way to go about
loading the controls on the user
control from the form thats using
it? Should there be a public method
within the control that allows you
to load it from an external form or should the user
control be loaded in the page load
event
Is it okay to nest user controls within user controls?
etc...
Thanks for any advice
1) You only need to make properties visible if any page needs to read or modify information on your control. I personally like to keep my user controls as self contained as possible, and keep this to a minimum.
2) I would just rely on the built in page life cycle to render your control, but it is important to note when each of your control's events fire in relation to your pages. You may find that there are times that you need something on your control to render before something on your page does. In this case you will need to rely on the page_init in your control more than the page_load of your control.
3) You technically can nest user controls, but things will get tricky if you need to start reading and writing information (as in your first question) from any of the nested controls. Also, the page life cycle of the nested controls gets even more important. I would avoid this if you can.