due to lack of documentation about this feature i can't find a way to do this. I am trying to use autoLoad with merge mode. I have a TabPanel in which each tab is supposed to open autoloading another page using merge mode.
i am aware that plain HTML does render, but pages including Ext.net components fail to render. In my child page i have a resource manager registered with RenderScripts set to 'None' Ext.Net examples page shows a merge mode example in that way.
Right now i get a 'Ext.net.Store is not a constructor' in the child page.
Is there any special parameter which needs to be sent in the loadConfig when doing the autoload? or are there any special elements besides resource manager needed on the child page?
Using <AutoLoad Mode="Merge" /> is very tricky. In general I'd say it should be avoided, with preference given to using 'XRender' functionality or <AutoLoad Mode="IFrame" />.
It's tough to say exactly what's going wrong in your code. Posting a simplified sample demonstrating how you have things configured and demonstrating how to reproduce the problem would be very helpful.
Related
I am using a Repeater web part in Kentico to pick out pages from the content tree, to generate nicely repeatable snippets of structured HTML, based on an ASCX transformation. (No surprises here - its been working great!).
However, a new requirement landed whereby alongside the existing HTML structure mentioned above, each repeated item must also have an area where we can add any amount of additional content; based on other web parts.
I have previously written a few "layout" type web parts; implementing CMSAbstractLayoutWebPart, as described here, which has allowed me to generate a repeating amount of web part zones, so I feel like I'm half way there. The issue with that though is that as it stands, I don't seem to be able to make use of the great power and flexibility of the transformations on the page type (which I really think I need to do, and seems like it should be possible..).
I thought I may be able to specify the WebPartZone control in the transformation markup directly, like in the following:
<%# Register Src="~/CMSInlineControls/WebPartZone.ascx" TagName="CMSWebPartZone" TagPrefix="cms" %>
<cms:CMSWebPartZone ZoneID="ZoneIDHere" runat="server" />
<div>
<h3><%# Eval("Heading") %></h3>
<p><%# Eval("Summary") %></p>
</div>
But the design view doesn't seem to pick up the web part zone; so I'm assuming the page lifecycle may not allow me to do this as I'd hoped.
So what I would like to know is:
Is it possible to include WebPartZone control in a transformation such that I can then bring in new web parts in Design view?
If not, what is the recommended way to go about this? (If a custom web part is the way to go, I'd like to clone the Repeater web part in the first instance, as many of its existing properties will be needed - but presumably this must still inherit from CMSAbstractLayoutWebPart?
Thanks!
Update
Good point about the editor's experience; I would definitely like to keep this as consistent as possible. The issue for me is that the requirements that drive my data structures are not always fully understood - and are certainly subject to change. Also, they are liable to vary (albeit subtly) across different products. So I've been trying to keep templates and page types more or less the same across the board, and push out the differences into page properties that drive web part config through macros. So given that the transformation approach won't work, I expect a custom web part is the right fit for me.
I shall post my findings!
I think adding a web part zone into transformation is not a right direction as web part zone should be a part of page template (not transformation) in order to utilize it.
I'd probably try to organize my content so each item you currently showing in the repeater has any number of child pages (potentially of a different type) and use something like hierarchical viewer in order to present all of them on the page. It allows using different transformation based on either page type or node level. Another advantage of this approach is that you keep editors experience consistent.
In the end, I was able to use transformation markup to specify the generation of web part zones. I went down the route of creating a custom web part that inherits from CMSAbstractLayoutWebPart, rather than using CMSRepeater web part or similar...
Here's a breakdown of things I needed to do this:
Gave the custom layout-type web part some properties with which to query the content tree, and supply them to a TreeProvider.SelectNodes() method in the web part code once it has initialised (by overriding the OnInit() method)
Gave the web part a TransformationName property so that the raw markup can be retrieved using TransformationInfoProvider.GetTransformation(this.TransformationName)
Used the markup above and resolved macros within it using each node from the node query
Example of macro resolution code (HTML transformations with macros)
protected virtual string ResolveNode(TreeNode node)
{
var resolver = this.ContextResolver.CreateChild();
resolver.AddAnonymousSourceData(node);
return resolver.ResolveMacros(rawTransformationMarkup);
}
Then I go looking for placeholder text in the transformation markup and use the methods available in the CMSAbstractLayoutWebPart parent class(es), as detailed here, to Append() the resolved markup and also call AddZone() as necessary to tap into the response string builder
Summary: The great functionality of the API allowed me to completely avoid the use of any repeater controls. I could generate web part zones as part of the layout web part usual layout generation process.
It would be nice if I could figure out how to resolve the expressions in SCRIPT tags in ASCX transformations to complete the story, but by using HTML transformations I can use the above to accomplish what I need.
ASP.NET, web form model.
Is there any sample code/site that demonstrate a couple samples for regular website patterns/ templates? Like if I want to use tab to switch between different pages, should I put the code in a single page or in different page, and treat each tab as a page.
Or if in a search page (just a single search bar and button), should I display my result panel in same page using dynamically enable the result panel, or just to another page?
I want to find a general design pattern/ template. Please advise, thanks.
I don't know if this answer will be helpful to you or not. Correct me if I am wrong.
You are specifying demonstration about web designing. It seems the functionality you want is clearly saying to choose from weather you want to use AJAX or not. I suggest why don't you use jQuery Framework for all this functionality.
I would give this a read and consider what best fits your application and your programming style, no one size fits all with paterns.
http://msdn.microsoft.com/en-us/magazine/dd252940.aspx
After you have a general idea, head over to google.com and look for the patterns that catch your eye for simple tutorials
Edit:
For the specific question about whether you should modularize your code. The answer is almost always yes. If you think there is a chance that the component will be used somewhere else then doing this a head of time can save you a lot of headache later. This practice also makes maintaining a lot easier because it gives a clear scope of what could be causing a bug. Instead of having to look threw an entire page of unrelated code for things changing state unexpectedly in the page life cycle.
When I generate code using T4 templates in Visual Studio 2010, I get the following error for each of my asp controls when I try to compile:
Control "ddState" is missing required attribute "showat".
I have never gotten this error in previous versions of .NET. Further, I don't get this error when I manually construct my pages either by dragging/dropping, nor do I get it when I type out the control text myself. When I generate code, I have to manually add showat="client" to my tag for the compiler to be happy. It was my understanding that I never had to explicitly specify this tag. The following:
<asp:dropdownlist id="ddState" runat="server" showat="client" />
solves the problem. Why do I have to add this to generated code but not other times?
(It's a VS-2010 webforms project, using VB, in case that makes a difference.)
Apparently .NET 5 or another one of those super service packs is going to allow something called targeted rendering. It was originally intended for use just in the context of webforms, but I've heard recently there will be some fancy way to use it in MVC (using some helper classes) and in services using WCF. It will work well with Dynamic Data but is very loosely coupled with it; you can use one or the other completely independently. If you configure your dynamic data with certain tags you can have it constructed on the client, etc.
For now, just put showat="client" in all your tags, and all is good. That's supposed to be the implicit default, but I've heard of cases where the IDE seems to require it. In the future, showat="client" will be the safest setting anyway, giving the expected behavior in 99.9% of cases.
This is required in VB, but not C#, which is why it seems to not be necessary sometimes. To be more specific, the C# compiler puts the equivalent of showat=client into the IL automatically, unless you specify a showat target other than client.
"showat='client'" should currently have little effect on your coding. It's main purpose is for future WCF output targeting, which they will want to be backward compatible. For now, the only possible value is "client", but in the future there will be other possible values that will allow pre-rendering of cached values, and apparently "pushing" output to services. The example I saw at the last code camp was where you could push to a service at (probably) the same site as well as to the client machine, for logging/debugging purposes. You'd have something like (to use your example):
<asp:dropdownlist id="ddlCP" runat="server" showat="client, logService" />
. . . and then the rendering would go to your log file. Or, to your session provider (if you've got multiple web servers and are implementing a shared session provider), etc. I think logService above would have to be defined in the web.config or something.
Check to see if VB does anything in the web form designer page when you use the IDE to add the control. I'm not sure how VB inserts the implicit tag. But that would be something the T4 template would miss, just a thought...
Agreed that my VS2010 solves this issue for you. Then you can remove the tags completely. I would suggest getting the upgrade. It's well work the $599 upgrade cost. Otherwise, look to add the showat="client" in all the tags. I think that Rising Star got that one right, although I haven't tested it yet.
Walter Rumsby provided a great answer to Where to place JavaScript in an HTML file. He references the work done by the Yahoo Exceptional Performance team and their recommendation to place scripts at the bottom of the page. Which is a hard and fast rule that I've been following for quite sometime now. In the same thread Levi Rosol pointed out "the best place for it [JavaScript] is just before you need it an no sooner." That is the predicament that I now find myself in.
I've added my reference to jQuery at the end of my page but have run into an issue with how to structure a user control that I'd like to add client side functionality to. Specifically, I am having a hard time working out the best way to accommodate dependencies. The user control has a span tag containing a numeric value that I'd like to update based on the number of check boxes the user has checked in the user control. I am using jQuery to find the span tag and update its text property.
Unfortunately, unless my reference to jQuery appears prior to the user control I receive JavaScript errors. This makes sense because the control is referencing functions that have not yet been added. I can think of several solutions to the issue but am looking for a best practice option.
Placing a reference to the jQuery library inside of the user control.
Downside: if the user control was placed into a repeater multiple references to the jQuery library would be made.
Put no JavaScript in the user control and write all code to update the span tag for the user control in the containing page.
Downside: I'd end up with the same code in multiple places creating a potential maintenance nightmare.
Place the jQuery reference in the head section of the page.
Downside: I've violated the recommendation to place scripts at the bottom of the page and have created an unusable user control if the page does not include a reference to jQuery.
Those are the options and downsides I came up with when thinking about solutions to this problem. I am certainly open to suggestions for better solutions and barring none looking for a recommendation of which of the three I should choose.
There's a Google project that aims to solve these pains you may want to look at called Jingo:
http://code.google.com/p/jingo/
Another solution I'd recommend is a loader like YUI Loader Utility.
http://developer.yahoo.com/yui/yuiloader/
It will allow you to manage dependencies etc. and it's not just useful when you're using their UI components. It can be used for anything; just look at the docs around addModule.
If you're using ASP.NET the ScriptManager is another good solution.
Another option would be to dynamically generate the script reference by registering a startup script from your usercontrol that wrote a script reference to the document head.
The javascript function could check for an existing jQuery reference, and if none was found, write the reference out. This would solve the multiple references. A basic example was discussed in this thread.
The simplest solution to this I've found is to use a helper to accumulate Javascript fragments to be included at the page body while rendering other page elements. Then, you can include jQuery first, followed by any deferred literal Javascript fragments.
It does require maintaining some extra state during page generation, which can complicate your rendering pipeline just a bit. However, it allows you to get deferred Javascript inclusion, without requiring complex DOM manipulation after the page is loaded to pick out any existing references to jQuery.
I wonder what the best practice for this scenario is:
I have a Sharepoint Site (MOSS2007) with an ASPX Page on it. However, I cannot use any inline source and stuff like Event handlers do not work, because Sharepoint does not allow Server Side Script on ASPX Pages per default.
Two solutions:
Change the PageParserPath in web.config as per this site
<PageParserPaths>
<PageParserPath VirtualPath="/pages/test.aspx"
CompilationMode="Always" AllowServerSideScript="true" />
</PageParserPaths>
Create all the controls and Wire them up to Events in the .CS File, thus completely eliminating some of the benefits of ASP.net
I wonder, what the best practice would be? Number one looks like it's the correct choice, but changing the web.config is something I want to use sparingly whenever possible.
So in that case I would wrap it up in a feature and deploy it via a solution. This way I think you will avoid the issue you are seeing. This is especially useful if you plan to use this functionality within other sites too.
You can also embed web parts directly in the page, much like you do a WebControl, thereby avoiding any gallery clutter.
What does the ASPX page do? What functionality does it add? How are you adding the page into the site? By the looks of it this is just a "Web Part Page" in a document library.
I would have to do a little research to be 100%, but my understanding is that inline code is ok, providing it's in a page that remains ghosted, and thereby trusted. Can you add your functionality into the site via a feature?
I would avoide option 1, seems like bad advice to me. Allowing server side code in your page is a security risk as it then becomes possible for someone to inject malicious code. Sure you can secure the page, but we are talking remote execution with likely some pretty serious permissions.
Thanks so far. I've successfully tried Andrew Connel's solution:
http://www.andrewconnell.com/blog/articles/UsingCodeBehindFilesInSharePointSites.aspx
Wrapping it into a solution is part of that, but the main problem was how to get the code into that, and it's more leaning towards Option 2 without having to create the controls in code.
What I was missing:
In the .cs File, it is required to manually add the "protected Button Trigger;" stuff, because there is no automatically generated .designer.cs file when using a class library.
Well, it's a page that hosts user controls. It's a custom .aspx Page that will be created on the site, specially because I do not want to create WebParts.
It's essentially an application running within Sharepoint, utilizing Lists and other functions, but all the functionality is only useful within the application, so flooding the web part gallery with countless web parts that only work in one place is something i'd like to avoid.