Yes that sounds backwards. I want to create an area or frame in my Silverlight app to host another page from my site. I've seen it done before but I can't seem to find any examples.
This way I can control the entire page layout using SL but still use existing aspx pages.
thanks
Yes, it can be done and its quite easy to do. I plan on blogging about my HtmlBrowser control and posting the source. The basics are to make sure the Silverlight control is hosted with the isWindowless parameter enabled and then you can at runtime through the HtmlPage class create an IFRAME element and set the src attribute to the HTML page location. The fun part is getting the sizing right, but its not too difficult.
Follow my blog http://craign.net/ over the next couple of days as I'll post my control.
Will frame break out code break out or not when using this technique.
Related
I have been tasked with creating a small website using SharePoint 2010 Site Pages via SharePoint Designer. I am bringing over my favorite html template, which loads and runs as expected (mostly), but I quickly ran into the following problem.
I typically use PHP to inject certain data into my page by reading directly from a local file. I have no experience with ASP, which appears to be the only method to accomplish this. I have searched the docs and so many sites but haven't found a clear-cut way to do this, and now my head is spinning. Can anyone help me with a simple process for reading a file into the middle of my html file as it gets served?
For example:
<html>
<body>
Here's my title
<inject file contents here>
Here's my footer
</body>
</html>
Thanks all, any help will be much appreciated!
You cannot do this out of the box. You will have to create a customised solution to do this, by implementing a custom controls for instance.
When you start using Sharepoint you need to change your mindset about whatever you used before. Believe me you don't want to pick a fight with Sharepoint, because the beast will win.
back to your problem I think you should be looking at Reusable Content.
Here is a description about it:
http://en.share-gate.com/blog/sharepoint-reusable-content-a-forgotten-beauty
Basically you have a list where you manage all your reusable content bits (sort of like your files).
And then in the Rich text editor for the page content you can then insert a snippet that inject your reusable content.
if the content changes all the places you are using the reusable content bits will also change.
So this behaviour is pretty much the same you get if using a file. Except it's the SharePoint Way.
Good luck
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.
I downloaded GraffitiCMS the other day(now open source and free), and like a lot of what I see, but what I really want to use it for, is to add CMS capabilities to an existing asp.net database/application.
Without getting bogged down with all the details of my app, can someone give me the basic 'approach' that should be taken to add custom content to Graffiti; content that won't be a 'post'?
I've seen for example, how to add custom-widgets to Graffiti - basically inherit from the widget class, compile your dll and plop it into the correct directory and it becomes part of the system. Is there a way to do something similar for the main content areas?
For simplicity sake, pretend I have a non-graffiti database with gig's of data that I want to display on the website using standard asp.net grid's and forms. I realize I could just go in and hack apart the source code to integrate my existing app, but that is likely not the correct approach.
Not looking for a complete solution her, just a pointer and what areas to investigate...thanks.
If you check out the latest source of Graffiti (or the 1.3 branch that was recently created), support was added to put widgets anywhere you want on any page. There is a new chalk function - $macros.Widget - that provides you with this ability. Dan Hounshell wrote a blog post on how you can use this new functionality:
http://danhounshell.com/blog/graffiti-cms-1-3-add-a-widget-anywhere-in-a-view-with-new-widget-macro/
If you're looking for something different than that, just let me know - we're working to make Graffiti even better for situations just like you are currently in.
What we have done to be able to integrate Graffiti CMS with our current ASP.NET projects is to create a post in Graffiti called "hidden" and then with our standard .ASPX pages we call a class in our Render Override that pulls the "hidden" post (ie: site.com/hidden/) and uses the header and footer to wrap the Graffiti theme around our custom .ASPX page. We use some HTML comments in the "hidden" post to be able to parse the header and the footer. It is kind of a hack, but has worked out really well for us.
I think you're trying to put the cart before the horse - depending on the size and amount of functionality, I would be looking to rebuild it after learning the development platform of my CMS system of choice.
I'm pretty much in the same boat right now. I have avoided Graffiti because I have to learn "Chalk" (whatever that is) and Umbraco (using XSLT for layouts is retarded). So far, this leaves me with Sitefinity at the top of my list and Telerik have just pulled the free version!
I may end up grabbing a very basic CMS which is easier to customize. I know this doesn't directly answer your question, but it may give you some food for thought :-)
you must have seen widgets like code which people place inside their HTML and it starts showing a small widget in there, how we can we do it in ASP.net, for example if i want to show some specific data of my site to anywhere some specific code is placed, how can i generate that embeddable code that can start showing my specific block of data to anywhere from any site?
Here are a few methods used by various people to embed a snippet of content on an external website.
1) An iframe!
iframe's can be a right old pest, but are quite good at displaying a bit of external content. They have been added back into the HTML standards in the HTML 5 draft specification, so you should get futureproof support for them in the future.
<iframe src="http://www.widget-address.com/Widgets/SomeWidget/" title="Some Widget"></iframe>
You can style your iframe (give it a width and height) and all that jazz.
2) External Image
This is largely used by advertising engines. You pop an image on the page and the image is dynamically created to display some advert - each time it appears it is different. This isn't great if you want information to be screen-readable (i.e. accessible).
<img src="http://www.widget-addrees.com/Widgets/SomeWidget.jpg" alt="Some Widget">
3) Server Side API
You could make an API available so people can call a "service" on your site that supplies them with the information for the widget. For example, their ASP.NET code or PHP code (or whatever language) calls http://www.widget-address.com/Widgets/WidgetService/ and it returns some data that they can format and display on their page. This would give you the benefit of inline HTML, which is the most accessible and valid way of displaying the data.
There are lots of other methods, so if you don't fancy one of these, I'm sure more suggestions will flood in - including (be careful...) JavaScript / AJAX.
I'm not quite sure I understand the question, so I'm sorry if I'm way off here. But I guess you are using the webforms framework for asp.net? If you are there is something called server controls. Those can be used to create widgets like calenders for example (that is already included in the framework, so no need to build it again).
If you are looking for code block, similar to <?php [[code]] ?> in php (if you have used that), then the answer is <% %>. Those are code blocks in the .net world. If you want to write something out you use Response.Write("string to write"); inside the code block. Or you can use the faster way: <%="string to write"%> that will render the same think (string to write).
If you are using the webforms framework you can also take advantage of the built in server controls in the framework. You can read more about the framework here or simply google asp.net webforms.
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.