I have quite a number of user controls that I need to embed in Umbraco macros. Each user control has quite a bit of in page javascript that needs loaded into the page.
I have been building up the javascript with StringBuilder.Appendline then registering a startup script with code behind but this stinks and I feel there has to be a better way of going about this.
Has anyone any ideas please?
Thanks,
B
If the javascript isn't dynamic, that is that it changes based on the usercontrol you would probably be best to extract it and put it in either one .js file for the site or in a number of them. Doing so allows it to be cached by the browser.
If it is dynamic then I would personally keep it isolated inside the control rather than try to write it out all at once. I don't believe there is any major performance hit from having several script blocks, although I could be wrong.
Related
I am working with ASP.net and I have two gridvew controls and some link buttons. Now, to bind these gridviews, I have to call web services and data access. Since I am pulling large amount of data, the page loads slow. I am wondering if there is a way I could do partial page load, meaning that I would like show the link buttons first then show rest of gridview as data are available (to bind to gridivews).
Is there a way I can accomplish this? (Preferably, without AJAX).
Thanks.
If you want a truly AJAX-less method, you could go with the ol' trusty IFrame tags and have your gridviews be stand alone pages. I believe the page will render around the IFrames while the IFrames themselves load.
NOTE: I also am not advocating this a the best solution, but it may meet the intent of this scenario.
Not without AJAX. But can you define what you mean by "without AJAX"?
Have you seen PageMethods? They may do what you intend, in a way that is palatable to you.
Alternately, you may mean "without UpdatePanels" in which case, are you familiar with XMLHttpRequests? (Note: I do not intend that an XHR is the appropriate solution here, I'm probing for familiarity with the topic)
First a couple of things, you may want to limit the data you are grabbing. If you are using a gridview this data will be stored in view state, causing huge overhead. If you are only displaying data, consider using repeater or datalists they are lighter. In any case you should be using pagination, though you may have to implement a custom pagination solution for the repeater.
Okay, maybe it's a bit pedantic, but do ASP.NET user controls HAVE to have an ascx extension?
My reason for wanting to know this is purely academic. I made the statement to someone that they usually have an ascx extension, but then I had the curious thought of if that was always true or not.
No. It's default, but it's not a requirement. I would recommend that you stick to this standard, however, as it makes it easy for anybody coming onto your project to understand what files are user controls just by glancing at them.
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.
Not sure if this belongs in community wiki...
Can somebody give some general guidelines on how to successfully build an ASP.NET site that isn't dependent on JavaScript? My understanding is that I should build a functional site initially without JavaScript, and use it to enhance the user experience. That is easier said than done... how can I make sure my site works without JavaScript short of disabling JavaScript and trying it? Or is this something that comes with experience?
Try ASP.NET MVC! sure most of the examples use JavaScript for the AJAX functionality, but it's easy to build a fully functioning site that doesn't use JavaScript.
Since ASP.NET MVC doesn't use server controls with all their embedded JavaScript, it's a great way to build a site with very minimal and lightweight HTML, while still writting your data access and business logic in C#, VB.NET, or any other .NET language.
I've built working ASP.Net sites with little or no JavaScript, so it's definitely possible (just a royal pain.) The trick, and this sounds silly, is to use as few <ASP:> type tags as possible. Those all spawn various levels of JavaScript. Regular old-school HTML elements work just fine with no scripting.
So, on the extreme end, you write, say, your form using all plain-vanilla HTML elements, and then you have that form submit point at another page that accepts the form submit and hands it off to your server-side scripting.
To put it another way, pretend that all you get with ASP.NET is a snazzy server-side programming language and you're writing HTML in 1998.
Now, having done this, I can tell you that what this ends up as is a classic ASP webpage with cleaner programming syntax. ;) Most of the features that make ASP.NET "better" than classic ASP hang on JavaScript, so writing a JavaScript-free ASP.NET system is an exercise in shooting oneself in the foot repeatedly.
However, the one thing you should absolutely do is make sure the first page or two do work without JavaScript. Unlike 10 years ago you can safely assume that any browser hitting your page has JavaScript, and unlike about 8 years ago, your visitors probably don't have JavaScript turned off for speed reasons, but they very well might have something like the NoScript plugin for Firefox dialed all the way to 11. So, your first couple of pages need to work well enough to a) tell the new visitor that they need JavaScript, and b) still look and work good enough to make it look like adding your site to the white list is worth it. (In my experience, most people get the first one done, but in such as way as to totally drop the ball on the second. To put it another way - if your super fancy web 2.0 mega site starts looking like craigslist if noScript is fired up, I'm probably not going to bother letting you run scripts on my machine.)
If you want to use many of the ASP.NET controls (i.e. the DataGridView), ASP.NET pages are generated with lots of JavaScript in order to handle the events on the controls (i.e. selecting a row in the DataGridView). I think you're going to lose so much of ASP.NET that trying to have ASP.NET work without JavaScript enabled is impractical.
Disabling Javascript is the best way to test how a web site performs with out it. Good news, IE8's developer tools provide a quick and easy way to do just that. Now, having said that, often times the only thing that you can do is put up a message with a noscript tag to the effect that your site requires javascript for best function.
Many ASP.NET functionalities & controls won't work when JavaScript has been disabled. Think of LinkButton's onclick event which contains a call to a JavaScript function.
LinkButton is just an example. But there are many other things too.
If your concern is with JavaScript being disabled in user's browser then you can check for that and handle your site accordingly.
If you do decide to build the site without JavaScript then you will end up building a somewhat static web site. If your need is just to build a static website then you can go on with this approach.
Write everything with basic html forms and css, and then you will know that it works without javascript.
Once you are happy with it, then look at unobtrusive javascript, so you can modify the way the application works when javascript is enabled.
Last time I looked at some stats about this around 1% disable JavaScript, so why spend hours and hours on this when what you should do is show a message telling the user that your site requires javascript.
Use your time to be productive instead of trying to write around perceived limitations.
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.