I realize that this question can start a discussion but that's really not my intention. We've created a Flex Application to take tests from candidates. The advantage of the Flex Application is that all state can be stored in the application running in the browser of the client. Things like time limits, navigation, scoring, ... can all be handled within the application without us having to worry about a back button for instance. Even running the app offline with Adobe Air isn't that hard.
My question now is if such an application could easily be made with HTML, Javascript, Ajax, ... ? The reason I'm asking is because an application in HTML would be much easier to distribute on Mobile devices for instance. Also, our domain model for instance is mostly implemented in AS3 (Flex) so using it along the server side means porting it to C#.NET. (with two codebases as a result).
Look at any good MVC toolkit, you will easily be able to handle this. Castle project is good as is Microsoft MVC, both of which allow you to choose from a variety of view engines to handle the actual page rendering thereby allowing you to choose the most 'mobile efficient' engine...
As for the technicalities, you would store all persistent data in a server session object.
Related
We currently have an application that is usable by several clients, it is used to download and store data from our application that they have on their environment.
We have a need to pass this application over to a developer but at the same time, we need to protect our code. The way that I see it working is that we would like to some how consider our current app a framework, allowing another app to be created on top of it, but the app may have its own screens, but re-use some of the built-in screens.
Is it possible to protect our app in such a way with out rewriting everything into protected DLL's? Or should we just suck it up and share our code with consulting firms that want to build these types of apps for our clients?
If your proprietary code is entirely focused on downloading and storing data. You could create an online REST api that returns the data over the internet. The other developer could then just request the data from your servers using an HTTP call.
However if your code needs to be client-side, the only real thing you can do is compile a DLL, and even then that can be decompiled.
We've an existing application developed in VB 6. There are 6 - 8 modules available. In main screen, a separate button is available for each module, which on click will load the respective modules. We're in the process of migrating this to a web-enabled system and identified to go with Java-based solution.
Now instead of completely developing and migrating to Java platform, we're doing a technical feasibility study of migrating module-wise. That is, on click of 'Module 1', for example, will open up a browser instead of existing VB application forms and all subsequent handling/processing/loading/saving will be handled by the web-based Java application, which actually runs on a web/app server. Slowly this will be migrated for other modules also.
My question is, is this technically possible/feasible? That is, can we open up a browser on click of a button and direct all subsequent requests, sessions, cookies to the Java application running on web/app server. Any pointers/suggestions/thoughts towards this are really appreciated.
NOTE: I heard about WinINet API from my friends which enables to interact with HTTP protocols.
If you are moving to the "poor client" (Web) model then your back end will be creating 100% of the user interface as Web pages.
In such a case your existing rich client needs to be dumbed down. There is no point in trying to request the HTML from the server and reinterpreting it into a rich user interface written in VB6.
Thus you don't need to worry about the WinInet API (which you wouldn't need anyway since from Win2K onward you have at least 3 very nice wrapper ActiveX controls and classes at your disposal: the Internet Transfer Control, the XmlHttpRequest class, and the WinHttpRequest class).
No, in your case you will probably be stuck with replacing your "modules" (???) which probably means Forms (?) by a Form hosting a WebBrowser control.
However it will be clumsy to integrate what goes on in there with your other "modules." If that's needed you're going to probably need to spelunk the WebBrowser DOM to fish out data, inject data, etc.
Ideally you'd be moving to a Web Service model instead of a Web model. This opens a world of front end possibilities (Web, mobile, rich client) without the need for multiple back ends and is quite usable in VB6. Things have even gotten easier over time as SOAP is abandoned in favor of simpler, loosely-coupled RESTful Web Services.
What you have described is feasible to a degree, but when you start adding requirements like session cookie control it might get ugly. You may end up needing two logons in your program, one for the old/existing parts and another for the browser-based parts.
You might be better off just letting part go over to a browser and strip parts out of the old app and make people run both side by side.
I am currently looking into Flex and Liferay for delivering an RIA. We are replacing a rather large existing application built on an internal AJAX/Java library. For this, Flex seems to meet our needs for development but we've had a wrench thrown into the works. We need to integrate with another internal app that's been built on Liferay and JSF.
After looking into Liferay a bit I'm not convinced that it provides any benefits to our existing application since delivery via a portlet doesn't appear to have any inherent benefits other than achieving the integration with the other application. It also appears to have a number of downsides including smooth interaction between the swf and the rest of the page, hooking into Liferay's user management and their general lack of developer oriented documentation.
It seems to me Liferay is a good solution if you need an internal wiki/news/social application, but for delivery of a robust RIA it seems like we're trying to fit a square peg in a round hole.
My question is this: Is Liferay used for delivering full RIA applications or is it a platform that's better suited to delivering smaller apps? Am I missing something about Liferay that makes it a good fit for RIA?
Thanks in advance for any advice!
You can easily get a Flex app to show up in a portal (Liferay or other) but here are some issues you might run into:
1) Typical portal servers hold all of the state - for all of the portlets - on the server. Every interaction causes a page refresh which rerenders everything on the page based on the serverside state. For Flex applications you don’t usually want the state on the server. And you don’t want every interaction reloading the Flex app. Some portals are getting more Ajax’y which solves part of this but there will always be some interactions in HTML portlets or in the portal chrome that cause a page refresh. This means that Flex applications must done some work to persist state beyond a page refresh. A simple way to do this is using LSOs but this requires a lot of extra plumbing code.
2) Inter-Portlet-Communication (in JSR 168 portals) goes through the server based on a page refresh. This also doesn’t work well with Flex apps. JSR 286 is attempting to solve this to support Ajax portlet IPC. Until then making Flex apps work with standard IPC is difficult (but possible).
3) A big part of portals is entitlements, customizations, and preferences. These are all difficult to use and interact with from Flex. In JSR 168 portals there isn’t a standard way of doing this. In JSR 286 there is a standard which makes it easier for Flex to read and update user preferences.
4) With WSRP and other remote portlet technologies portal servers can consume remote portlets and proxy all requests back to the portlet provider. With Flex this is more difficult because portal servers don’t know how to proxy Flex requests (HTTPService, RemoteObject, DataService, etc). In many cases the only solution is to allow the end user’s machine to talk directly to the portal producer server. However many times this causes problems for IT because it means moving another server to the DMZ and potentially bypassing the security constraints imposed by the portal server, SSO server, Security Appliance, etc.
Have a look at www.qooxdoo.org. This is a framework for writing large applications entirely in javascript. It combines excellent GUI control with a java like programming paradigm for javascript and a clever build process for the final application.
I have a large flex application (the app) running on one server, and many small flex applications (widgets) running on another server, which are to be included in the app so that visually the user see's one continuous application. Due to proprietary third party software, this structure cannot be changed. I am looking for some way to allow the app and the widgets to communicate, allowing the app to make changes to the widgets and the the widgets to notify the app when events are triggered, so that user interaction is fluid and continuous.
There are a few related questions which indicate it's possible to do this by setting up event triggers and listeners. I am wondering if there is any standardized way to do this (the answers aren't very clear) or if anyone has developed a library or API to make this easier.
Something I've had success with is using javascript as a bridge between the swf files. It's a nightmare to debug but it works quite well. Check out the tutorial here for a quick discussion of how to interact with javascript from within flash and vice versa
I assume you are running your Flex apps on a client, not a server; is that correct? You want to swfs from multiple servers to act as single application, correct?
I believe that you can communicate between two swfs using LocalConnection:
http://www.adobe.com/livedocs/flash/9.0/ActionScriptLangRefV3/flash/net/LocalConnection.html
The other questions you link to seem to talk about loading onw swf inside the oher; which is a separate approach.
Use Modules and ModuleLoaders. You'll be able to set the security context, and if you sublcass the Module class and add your own API, you can have a consistent way to communicate with your modules.
Check here for a simple Module:
http://blog.flexexamples.com/2007/08/06/building-a-simple-flex-module/
The company where I work created this application which is core to our business and relies on the web browser to enforce certain "rules" that without them renders the application kinda useless to our customers. Sorry about having to be circumspect, An NDA along with a host of other things prevents me from saying exactly what the application is. Essentially, JavaScript controls certain timed events (that have to be accurate down to at least the second) that make it difficult to control with ajax/postbacks etc.
My question is this: how hard is it to convert an ASP.NET application to SilverLight assuming that most of the code is really C# business logic and not asp.net controls? I just got finished listening to Deep Fried bytes and the MS people make it sounds like this really isn't that big of a deal. Is this true for web apps, or mainly Win32 ones?
I know the asp.net front end is fundamentally different from SilverLight, but there is a bunch of C# code I would like to not have to rewrite if necessary. The replacement of the javascript code to silverlight I am assuming is trivial (i know bad assumption, but I have to start somewhere) since it deals with timed events, so I am not really concerned with that. I need to come up with a solution on how to mitigate this problem, and I am hoping this is a middle ground between: do nothing and watch us get pounded by our clients, and rewrite the whole application in something more secure than a web page with only front end validation. Has anyone tried to convert ASP.NET code to a SilverLight project?
If the bulk of your application is on the back-end, you should still be able to keep the majority of the code intact and only replace the front-end. However, Silverlight requires an understanding of WPF, which is dramatically different than the HTML/JS that your app currently uses. I'd say if your UI is pretty thin, it should be pretty easy to port to Silverlight, but the more business logic is in the UI, the harder it will be.
How heavily do you use the class libraries, and things that might be considered 'dangerous', like pinvoke, file system access and System.Diagnostics.Process?
Porting code from ASP.NET to Silverlight is not an easy task. As Nate points outs it depends on how much of ASP.NET application is AJAX based, and how much is based around server controls.
Silverlight is a state full client side technology, meaning everything is running on the client inside the browser. ASP.NET is a server technology, and is built around a request/response model. Since these two are completely different paradigms it's not a straight port.
However, since ASP.NET is just HTML and HTTP POST of form data people have done experiments where they have added a Silverlight application directly on top of an ASP.NET page, and manually built the HTTP POST request by hand sending back the exact data the ASP.NET application work. It's almost like doing "screen scraping" for your own application. This could work, but wouldn't be optimal. You wouldn't get a performance increase as your ASP.NET application would have to go through a full page cycle on every request.
A better alternative is to start out wrapping any functionality the user has in the APS.NET application as web services. You can add these services alongside your ASPX pages, and gradually port the application over. The UI you would build from the ground up based on these services.
Good luck!