I am migrating an aspx application in to Pega which has heavy UI pages.
When I tried to render the respective HTML in the form/ user interface tab of PRPC, most of the UI controls did not render and have to do heavy Pega coding to make it work.
Are there any best practices or tools available to optimize UI design by converting aspx pages UI elements in to Pega?
I can understand out-of-the-box customized controls cannot be rendered unless there is a converter.
No, how should that be possible? PRPC runs on a Java Application Server (Tomcat, Websphere or Weblogic) and thereby executes Java / JSP code - acting as a platform. The same way you can't just reuse php snippets in your Pega application.
In PRPC one UI rule type are sections. Sections are preferably auto generated, but you can choose to put in HTML code or even JSP code instead. There you could leverage the JavaScript frameworks included in PRPC or do includes on an iFrame basis. But you can't paste there php or aspx code since it won't be executed on the php resp. aspx environment.
Related
You are implementing an ASP>NET application that makes extensive use of javscript libraries. Not all pages use all scripts, and some scripts depend on other scripts. When these libraries load sequentially, some of your pages load too slowly. You need to use the ASP>NET Ajax Library script Loader to load these scripts in parallel. Which two actions should you perform?(Each correct answer presents part of the solution. Choose two)
In your site's master page, add a call to Sys.loader.definescripts to define each of the scripts that are used in the site.
In your site's master page, add a call to Sys.loader.registerscript to define each of the scripts that are used in the site.
In each page that uses scripts, add a call to Sys.get for each script that is needed in that page.
In each page that uses scripts, add a call to Sys.require for each script that is needed in that page.
Please tell me which are the two answers are correct and why?
Thanks
1 and 4, because that's what http://weblogs.asp.net/bleroy/archive/2009/11/23/enabling-the-asp-net-ajax-script-loader-for-your-own-scripts.aspx and http://www.asp.net/ajaxlibrary/HOW%20TO%20Load%20Required%20Scripts.ashx imply.
I am wondering are there any standard mechanisms available to protect the asp.net asp code in the client browser ? I found some references to Windows script encoders. Question is, are these script encoders encodes both aspx and code behind source ? If aspx is encoded with the Windows script encoders then how client browsers can decode it? Are they aware of the encoding algorithms ?
Or can we control the client browsers ( IE, Firefox, Chrome etc) to disable the view source option in the Tasks Menu when web site a loaded in them?
Any pointers will be appreciated.
The HTML code generated on a webpage is by definition public. It has to be accessible to the browser for it to be able to render the page properly. You will not find a reliable solution to hide the view source option in browsers.
To explain the basics a little bit :
When you create a page, you write markup in your .aspx file and some c# source code in the .aspx.cs file. The c# code is the server side code, which means that it is executed on the server (as opposed to, say, javascript which is executed directly in the client's browser -- client side).
When a page request is executed, the ASP.NET engine executes the server side code, and also executes the asp tags that you wrote in the .aspx page (for example : <asp:Button runat='server'... /> . It then spits out HTML code (this is a very simplified version of what actually happens).
The client's browser only ever gets the HTML (and it will not see the C# code nor any of asp markup code which is used to generate your page).
As I said before, the HTML generated is, and will always be public. There is nothing you can do to reliably hide it.
Server-side code (ie. code in code-behind pages, controllers, helpers, <% code nuggets %>, etc) will of course never be visible to a web client.
Your aspx or view pages (ie. .aspx, .cshtml, .vbhtml) files will also not be visible to web clients unless you have a signficiant security vulnerability, but the HTML generated by said files will be, along with any outputted or referenced JavaScript.
If the client couldn't read the HTML or JavaScript, how would the web browser be able to parse it?
Here's a question about obfuscating JavaScript, which will at least hinder but not completely remove a user's ability to view your source: How can I obfuscate (protect) JavaScript?
Similarly, one could theoretically obfuscate outputted HTML as well, but it could also be likely be reversed with some work.
It is impossible for the user to see your server-side (C#) source.
It is impossible to stop the user from seeing your client-side (HTML & Javascript) source.
In terms of javascript - the only thing you can do is obfuscate it to an extent that makes it worthless for someone to try to understand.
None of the code behind code is sent down to the client, only the rendered HTML.
there is no way to completely remove the ability for a client to view the source of your HTML. The only thing you can do is to obfuscate your HTML to make it harder for them to tell what they're looking at.
There are many libraries out there for obfuscating HTML in .net if you do a google search.
I'm confused really, but...
If you are on about the ASP.NET markup, you need not worry as any request to an ASP.NET page will cause the page to be compiled (if it hasn't already been, or isn't cached) which renders the page content as HTML.
If you are worried about people navigating to your code behind (e.g. mysite.com/SomePage.aspx.cs), you need not worry, as ASP.NET will not serve that content [unless the standard configuration has been changed].
If you are worried about people accessing your code through FTP, then I would suggest you change your compilation method and not deploy the source.
Am I missing anything?
I'm building an HTML5 application (with ASP.NET back-end) and i want to develop it in such a way that i can run it locally with all my resources (such js and css) not minified (so i can debug it easily). However when i build the final version i want merge and minify the resources. At the same time i want to create several versions of the app targeting different platforms (iPhone, iPad, desktop, etc) by adding appropriate css.
I thought that the final output should be a set of html files (so the get cached nicely). I could use ASPX and just control the output by a query string parameter, but i don't really want to have the form tag on my page.
So the questions are:
What are the pros and cons of using static html pages generated from a template versus a dynamic ASPX page? (apart from being able to run on any web server)
If ASPX approach good enough then how can i get rid of the form tag that's required by ASP.NET?
UDPATE
Another factor in favor of static html pages is the fact that the files are served instantly, whereas ASPX may take awhile to load if the app has recycled.
The back-end is ASP.NET 2.0.
What are the pros and cons of using static html pages generated from a template versus a dynamic ASPX page? (apart from being able to run on any web server)
Pros:
Less overhead as you no longer have to serve ASP.NET pages through IIS
No viewstate, smaller page sizes (as long as your generator or build process removes them)
Faster loading times (due to the reasons above), though this could be achieved serving ASP.NET files with output caching.
Cons:
You obviously lose the ability to serve truly dynamic pages. This isn't a problem if you're not processing forms or have data that doesn't have to be updated often.
If ASPX approach good enough then how can i get rid of the form tag that's required by ASP.NET?
If you want to use WebForms and serve dynamic pages you can't get rid of it. If you're wondering how to get rid of it after the static html pages are generated, that could be done using an HTML parser simply enough during your build process.
I ended up using aspx pages. I removed form tag and it seemed to work (as long as i didn't use viewstate)
Hello: we currently do not use asp.net controls (no web forms). The way we do is:
1> Read HTML file from disk
2> lookup database, parse tags and populate data
finally,
Response.Write(page.ToString());
here there is no possibility of using asp.net controls. What I am wondering is, if we use asp.net controls in those HTML files, is there way to process them during step 2?
Thanks and appreciate your response.
I haven't tried this but you might want to attach the html extension to the ASPNET ISAPI filter in your IIS and in your page, step 2, use Server.Execute and call out that html file. However that page will execute on its own.
If these html pages from step 1 are meant for making up parts of the page that needs to get inserted in parts of the webform (.aspx), I suggest that you make use of master pages instead.
If the html pages are standalone pages that need extra functionality you can simply upgrade them to webforms without codebehind if needed. Custom made macros in Visual Studio can help a great deal in this transition effort.
We are looking at integrating a full-blown GWT (Google Web Toolkit 2.0) application with an existing ASP.NET 3.5 application. My first gut reaction is that this is a horrible frankenstein idea. However, the customer has insisted that we use this application developed by a third-party.
I have almost NO CONTROL over the development of the GWT app.
My first thought is to actually attempt to embed this in an iFrame. Because GWT is running under Tomcat/Jakarta, it is hosted on a different server from the .NET app so the iFrame src will be to a URL on the other machine.
I need to utilize our own ASP.NET authorization scheme to restrict access to the embedded GWT application. The GWT app also uses embedded java applets, which don't seem to be working right now inside the iframe. The GWT app makes calls to a backend server (using GWT-RPC?).
Any major problems with this approach that anyone can see? Will GWT work on an iframe while hosted on a different machine?
NOTE: SIMPLY ADDING A DIV WITH THE SAME NAME DOES NOT WORK FOR THIS!
To expound on what Tony said, GWT can live on any page. At its lowest level, GWT hooks into a div by its ID or the body element, as its RootPanel, and adds widgets to it from there.
Simply add a div to your ASP page like <div id="gwt-root" /> and in your GWT code, start with RootPanel root = RootPanel.get("gwt-root"). Then you can start adding widgets to that panel to build the GWT portion of your page.
You'll also need to bring in your GWT generated code with a script tag, like so:
<script type="text/javascript" src="gwt-app-name/gwt-app-name.nocache.js">
Also, if you want, GWT can interact with the rest of the page using regular JavaScript using JSNI.
you do not need an IFRAME. Writeyour application so that the main panel is hosted inside a div with a specific id. If your ASP.net can provide a div with the same id, then all you have to do is include the generated JavaScript files (+ some style sheets) and your application will display inside the div.