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.
Related
Is there a benefit to implementing micro-formats (or itemscope) in the html for a web app? So far it only looks like it is useful for seo and my web app is behind a login screen, so I will not have to worry about that. Are there any plugins or browsers which automatically process the information.
Or as unor proposed, is there a benefit in adding structured data to non-public sites?
If you generalize the question like unor proposed:
Is there a benefit in adding structured data to non-public sites?
It has got a definit advantage! For someone with visual disability it is easier to navigate through sites if micro-formats are implemented. If there is a possibility that someone with a screen reader will use the application it worth the effort. Not to mention that it is a one-time task with a long term positive effect. I think it is a good thing to proactively thrive to serve all kind of user.
Answer to the original question: browsers do not have to process those information, but some advanced technology could use it in the browser like preload. There was a research at my University about which pages to reload and those were using this feature. (Eg: in free time of the processor the browser plugin preloaded home to enhance the browsing experience.)
We have been using Worklight to develop hybrid apps to securely integrate with server generated pages. Our approach has been to use WebViews for Android and iOS platforms. Lately we have some folks who prefer using iFrame approach instead, primarily for ease-of-programming reason.
Are there security related concerns of using iFrame instead of WebView in hybrid mobile apps?
The security risks of using iFrames is well known, see for instance the discussions on this stackoverflow question.
Adding to that you have to trust that the iFrame support on each platform (iOS / Android) is properly implemented and consistent.
However, I would not recommend using iFrames on a hybrid app unless you really have to. My reasoning is that a hybrid app is already based on a WebView, so iFrames would be adding one extra layer to it, which adds unnecessary complexity (that also impacts performance and memory footprint)
Not only that, but the iFrame behavior and performance is not as polished as the WebView itself and the platform support is not as consistent, as described by this Phonegap article
Finally, this is a far less common use case and it might be harder to find support to resolve styling, performance and behavior issues with the JavaScript library communities like JQuery Mobile and Dojo Mobile.
Again, this is my personal opinion on the subject.
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 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.
(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.