I'm about to develop a small system to display dynamic information in public spaces across an entire building (similar to Flight Information Displays on an Airport).
The system will have two main components:
a back-office for managing the
information displayed
a front-end
which acctually displays the
information.
The back-office component is covered: it's a simple crud application with a web interface, accessed through the intranet.
I have to decide which language/technology to use for the front-end. The purpose of this component is only to access the information in stored in the back-office and display it in a big LCD monitor. No input in expected, just display the information, paging once in a while as all the information won't fit in the screen at once.
I think of a Flash movie which some-how access the back-office data through the local intranet to get the information to display.
Can you think of a better option for the front-end? Why?
Other technologies that came across my mind are:
Silverlight
Flex
JavaFX
I've had pretty good success using Silverlight and C# to access and display back-end data, running it in out-of-browser mode to avoid the display of browser chrome. WPF might also work in your situation instead of Silverlight, but Silverlight seems to be the target for most of Microsoft's recent tooling efforts (via WCF RIA Services).
The advantages for me were the fact that my company largely already has a Microsoft-based infrastructure and we already owned the tools. Up-front costs can be an issue if you go the Redmond Way. Also Silverlight and WPF have fairly healthy learning curves, though there are tons of resources and tutorials available.
Related
what is the best approach to work with ibm worklight website which has lots of content ..should it made multipgage?if it is multipage how do we access worklight context on each page
IMO there are multiple aspects you need to think about and take into account with respect to your specific scenario and needs. Since you did not describe those in detail, I will try to generalise my suggestions:
Your are not required to have an app per-se
You could also re-design your website with responsive web design in mind. This way, as your users load the website in either Desktop browser or Mobile browser apps, the website fits itself to the device's viewport size.
If you do choose to create an app
Not all aspects of your website must exist on the mobile app. Re-consider your strategy and find the right balance of what you should present to your end-users. Make it lighter
Think mobile-first; the paradigm is different and so should be your approach and design: UI Design Dos and Don'ts
As for the technical aspect, many UI framework provide ways to present "pages" within your app. Worklight can work with any of them. Read more about the challenges and solutions, here:
Building a multi-page application tutorial
Example application showcasing multi-page navigation in Worklight 6.2 using jQuery Mobile
Stack Overflow questions about Worklight and multi-page apps
Strictly speaking Worklight hybrid apps are single page apps: there is a single HTML page and we never navigate to a new "URL". However from the UI point of view the user sees what appears to be multiple pages, typically this is achieved by manipulating the DOM of the single page. For example we have a DIV for each "page" the user sees, and we navigate by showing and hiding those DIVs.
With that philosophy in mind your question about accessing the Worklight context now becomes trivial: we're on a single page, so the context is always avaialble.
As Idan says it usually simplest to implement such a single-page, multi-view app by using a JavaScript framework that manages the navigation. Many folks these days use angularJs. Using such frameworks we can decompose the app into a number of small HTML and JS files that are dynamically loaded, from the app perspective it's still a single page but from a development perspective we now have finer-grained artefacts that allow easier parallel development in a multi-person team. When you have an with many 10s of "pages" such decomposition really pays off.
I've got an app that's been started on the Microsoft stack as a smart client (notionally WCF/WS enabled) with a small client app that gets deployed and the rest of the app running in our private cloud. It's only real dependency is internet connectivity, .net 4 and a windows operating system.
I am under pressure to convert over to a browser based architecture for all future development. Based on other web apps I've worked on, I'm concerned that the way that client IT organizations can control the browser, it will cause more problems down the line than what I really want to deal with.
Do you have experience making this kind of decision? What technical factors did you consider when deciding to go smart-client vs. browser? What resources were helpful in making this decision?
My app is a healthcare app targeted at healthcare providers (eg. hospitals), so everywhere I go, I have to worry about the Healthcare CIO looking over my shoulder.
Interesting. Originally I'm from C# winform and WPF Desktop programmer, and later being assigned to do web development. Haven't touch Smart Client yet but I think it should almost be the same with Native app. Based on experience, the technical things to consider are:
Multi browser support
Especially for reporting and graphic processing, without some library / plugins / framework for your component, it will be insanely hard to keep your app multibrowser. Especially in css style and less in javascript.
Client programming(javascript)
You will lose the ability to create controls and animation using C# controls. Instead you must using javascript (jquery or other library) in exchange. Javascript is not fully OOP, and intepret language (no compile error), making it harder (maybe there is some framework like coffeeScript which I haven't yet explore). In addition, it is harder to make since it will need server request / response activity in between the process, which I will describe later.
Request / Response Client-Server Architecture
This means that most process in client will need to request for the server (request for data to display, request to modify the data, etc). It also means that you lose the ability of control event, even if you use asp.net webform (it still need some tweaks for the event to work). However I assume you already used the WCF so this kind of architecture must be that hard.
Security
Don't keep important information such as password, etc in client (hidden field, javascript variable, etc). The concept should be the same with multitenant client, however in browser, user has free access to debug your webpage.
Concurrent and Multithreading
In browser, it is easier for multitab page and concurrent process will be very highly to occur. Your code must able to handle the multi threading for client side. For server side, you can still use your WCF to handle concurrencies.
My 2 cents.
Obviously the web application has its own challenges. I hope this link can help you in some aspects: http://msdn.microsoft.com/en-us/library/ee658099.aspx
Along with those you need to focus on non-function requirements like extensibility and scalability etc. too.
This post is intended to start a deeper discussion on Single Page Applications for the web. There are questions that do not seem to have a clear answer in most resources on the subject.
They are in my mind
Authorization and authentication.
With entire web app being on the client, it may make calls to the server in any of its functions, even those that the user does not have rights to. The fact that the user cannot see a menu, does not preclude that person from invoking java script functions. This is easily handled in MVC app, for example, by using controllers that validate user rights to a specific function based on a cookie for example. However, some SPA apps just use single controller with Breeze or Web Api, which make authorization server side impossible.
Memory management on the client
For small sample apps this is not an issue, but imagine an app with 100's of screens or an app with a single screen that pulls thousands of records over the course of one day. With persistent caching one could imagine large memory issues, especially on under-powered devices with little RAM, like phones or tablets. How can a group of developers had SPA route without a clear vision of handling memory management?
Three Tier deployment
Some IT departments will never allow applications with a connection string to a database located on front end web servers. Every SPA demo I have seen is structured exactly like that, including Breeze or Web Api for that matter.
Unobtrusive validation.
It would require developers to use MVC partial views and controllers instead of just HTML files, which seems to fly in the face of SPA concepts, while it provides a very robust way to easily incorporate validation and UI to support it into web applications.
Exposing primary integer based keys in the url.
This is non-no in OWASP.
As a result, SPA applications "seem" to target areas with few security requirements and small feature sets. What do you think?
Thanks.
#Sergey - I think this is just too broad a question for StackOverflow. S.O. isn't a discussion forum; it's a place to go for specific answers. So while your questions are potentially valid, I don't think you should hold out much hope for deep substantive responses here.
May I add, in the friendliest possible way, that your sweeping, unsupported, and negative statements make you look like a troll. You're not a troll are you Sergey?
On the chance that you are in fact authentically concerned, I offer a few quick reactions, particularly as they pertain to Breeze.
Authorization. In Web API you can authorize at the method level. The ApiController base class has a User property that returns the IPrincipal. So whether you have one controller or many (and you can have many in Breeze if you want), the granularity is method level, not just class level.
Memory management. Desktop developers have coped with this concern for years. It may cause you some astonishment if you've always developed traditional web apps where process lifetimes are brief. But long-running processes are not news to those of us who built large apps in desktop technologies such as WinForms, WPF, and Silverlight. The issues and solutions are much the same in the land of HTML and JavaScript.
Layers on the backend. You've been looking at demos too long. Yes most demos dump everything into one project running on one server. We assume you know how to refactor the server to meet scaling, performance and security requirements for your environment. Our demos are concerned mostly with front-end SPA development. We do dabble at the service boundary to show how data flow through a service API, through an ORM, through to the database. We thought it sufficient to identify these distinct layers and leave as an exercise for the reader the comparatively trivial matter of moving these layers to different tiers. We may have to re-visit that assumption someday. But does anyone seriously believe that there are significant obstacles to distributing layers/responsibilities across server-side tiers? Really? Like what?
Unobtrusive validation. When most people start using the word "unobtrusive" in connection with HTML, they are usually making a point about keeping JavaScript out the HTML. Perhaps that's what you mean too, in which case SPA developers everywhere agree ... and that's why there are numerous "unobtrusive validation" libraries available. HTML 5 validation, jQuery validation and Knockout validation come to mind. All of them are in the SPA developer's toolkit and none of them "require developers to use MVC partial views and controllers". What gives you the impression that a SPA would need any server-side resources of any kind to implement validation with JavaScript-free HTML markup?
Ids as security risk. Really? This is bogus. The key value is no more a security risk than any other data value. Millions of applications - not just SPAs - communicate key values to the client, both in the URL and in the body. It's standard in REST APIs. It's standard in ODATA. And you want to dismiss them all by saying that they "target areas with few security requirements and small feature sets"? Good luck with that. I think you'll have to do better than rest your case on a link to a relatively obscure organization's entire web site.
I have built some SPA applications, ranging from small to large (over 100 scripts and views). Only a handful of them had every view accessible to the public. The rest went through a strict access structure. It was so simple to return a 401 unauthorized from the server and the client just handling the 401 to redirect it to the login screen. Mr. Ward and Mr. Papa put it right. Get out of the Demo mode and try to find solutions to the issues you come across. I have watched John Papa's SPA on pluralsight, gone through numerous articles and applications on Breeze and I have to tell you, none of my applications use Breeze to do queries from the client side, because YOU DON'T NEED TO!!
Moreover, I have only extended what I have learnt and come up with my own way of solving problems. This is not an answer to your queries, but I only can provide a short comment. No technique is perfect and there is no ONE way to do everything. My server side is locked down where it needs to be locked down, my routes on the client side are locked down (if using durandal take a look at guardRoute), my scripts are minified and my images are sprited (if there is a word like that). All in all, SPA is a great technique, you got to find solutions to the quirks!
I'm sure many of you are familiar with the IBM i5 series emulator (looks like this poop)
My company uses this religiously and there is no Biz logic in it so anytime somone in our finance dpt makes a human error it accepts it and adds it to the database. Not to mention its ugly, hard to use, not intuitive, etc....
I would like to create a frontend for this interface so that we can control the logic before its submitted to the system (we dont control the system itself) so in effect I need to make my own emulator app.
However I cant seem to find any information on how to interface with the i series, namely login, send commands, and view or gather data from the screens it would normally send back.
Any suggestions?
The problem is not the iSeries but the software package your company is running on it.
There ARE advantages to use green screens: it's fast and it's almost unbeatable at data entry, provided you get used to it.
But to answer your question, the iSeries is a J2EE enabled machine: a HTTP server comes installed and depending of the version of the iSeries, WebSphere might be already installed, or are entitled to install it. Then you can use JT400, which is the java toolkit for the os400 containing the jdbc drivers to connect the database and the necessary classes for calling programs.
If you prefer php, there is a flavor of the Zend framework made to work on the iSeries but I never tried it.
I'd recommend that you take a look at both the Attachmate Verastream Host Integrator (VHI) and IBM's Host Access Transformation Services (HATS) products. They effectively just screen scrape the green screen terminals to allow you to pull and push data and provide macro recording and editing tools to automate the process. App integration can be achieved via web services or html/jsp/servlet programming (plus .Net for VHI and EJB's for HATS). They do come with enterprise pricing however which may be an obstacle for some. They do have free trial offerings for evaluation purposes to help determine if they are an appropriate solution to your problem.
What software packages are they using? Most programs that I use in the 5250 emulator has some business logic that error checks the data before adding it to the database. Can you get us some more information so we can direct you in a better direction.
There are vendors that sell products that screen-scrape the 5250 data stream and produces a web front-end. Or you can write your own front-end in the language of your choice and just do SQL calls to the database.
THere's got to be some source code. Start by looking at the menu and menu option your users are accessing and figure that's running behind them.
Use command STRPDM to look for source code - look in different libraries (they are like folders)
You might have source code in a "member" called something like xxxMNUSRC xxxRPGSRC (rpg program source) or xxxCLSRC (cl programs), xxxDDSSRC (display/screen source, physical/logical file source)
Objects a "compiled" objects such as files (tables), screens, priter files (reports)
Stay away from Qxxx and #xxx libraries - those are system libraries.
http://systeminetwork.com/ is a good resource for iSeries related questions.
(From the point of view of a user, not how it's built or which option is selected in Visual Studio)
...What is the difference between a "website" and a "web application"?
Is there a difference?
Are there characteristics that characterise the two?
Software applications are software tools designed to help the user perform specific tasks. Web applications simply provide a software application through a web interface. Think Google Docs as a typical example, but web applications can be much simpler.
On the other hand, a website can be regarded as just a collection of related digital assets (documents, images, videos, etc), relative to a common URL.
(Note: I take the definition of a website from Wikipedia and deduce a definition of web applications from that (or, better, define differences between the two concepts). Everything in bold face is meant, put together, to build the definition of a web application.)
Starting with the fundamentals: Is a web application a subset of a website? Following Wikipedia's definition of a website, that Daniel Vassallo has layed out in his answer, a website is a bunch of documents under a common URL. This also follows the definition in the Cambridge dictionary.
A web application, on the other hand, is a bunch of web-based dynamic HTML and JS documents, together with images, CSS files and other documents, that is most probably, but not exclusively located under a single URL. The purpose of a web application comes below.
Hence we can state: If a web application is located on a single server only, without using client-side cross-domain techniques or extensive local storage (which I'd like to define here as everything beyond standard cookies and default caching), it is also a website.
Corollary: There can be web applications, that are not websites.
Hence we have to extend the definition of web application: A web application, under certain circumstances being a website, is a set of interactive documents. Interactive thereby means, that the user can do more than just follow hyperlinks to get from resource to resource. She can actively and in a well-defined manner change the state of resources. The web application is, for this task, not confined to a single server, or to the server side at all.
Now we yet have to define, where a web application ends and quite anything else starts. Therefore we state: A web application has always an entry point, that is located at a website. If it has multiple entry points, they must all together be part of the same website.
qed
I am open for any suggestion on how this epic piece of wisdom could be refined to meet the requirements of reality. ;-)
Clarification:
This answer is in no way disrespectful to the question. However, I took a semi-serious approach, by which I mean, that the provided definition may or may not fit into one's personal idea of what a web application is compared to a website, but (and that is the serious part) is based on and deduced from a (possibly random) collection of facts.
Clarification 2: This answer has nothing to do with Visual Studio.