For ages, our company uses Dojo as the interface library of choice. The applications created have a very desktop-like look & feel and are very suitable for business areas and banking.
However, I see a trend towards user interfaces that are more like Google+:
page-based instead of internal scrolling
not many modal popup windows but rather edit-in-place and drop-out things
loading additional list items via scrolling to the bottom of the page
all that kind of user interaction. Basically, a light and more web-centric usability approach.
Unfortunatelly, I don't know of an library that really helps in building such interfaces - I know jQuery UI, Sencha, Cappucino, Sproutcore and the like, but they do not quite fit.
Does anybody know of some new ui component library for sites like Google+?
A lot of the interface patterns used in Google+ are in Google Closure Library.
You can use the following book about Google closure : Closure: The Definitive Guide for reference.
Related
I am developing a mobile based web-application, in which I need to integrate Google maps. I need to fill latLng info from Google maps. Is it possible to get the GPS location and use it in my application?
The browser is able to share the location with you thanks to Geolocation API, but you have to be aware of that, user when asked if he permits accessing the geo-data, might not agree. There is no way of forcing the locations to be shared with you.
Because it is part of Web browser API - there are JavaScript methods to be used.
The core of it is in very descriptive names of methods:
geolocation.getCurrentPosition(function(position) {
console.log(position);
});
Check this great tutorial of how to implement the solution on your own. It's really good, well explained and covers edge cases.
It covers much more code, so there is no point of copy-paste all of it here.
Hope that helps!
I don't get completly the architecture of Titanium Alloy. Maybe someone can explain it better or draw me a picture? :)
What I understood is that it is a mvc architecture but not in the "basic" way... The Model is only a blueprint for the intern SQLite database. The Backbone Model also can be extended to check for correct input and duplicates. To synch with the extern the Controller is used. At least all the examples I found did that. And the View is basic with Titanium Style Sheets.
Unfortunately you have a very terse, incomplete understanding of what Alloy is, what it does, and how it does it. Fortunately for you though, there's is extensive and complete documentation that covers all this in guide form. Answers to all these high level architecture questions and more can be found here: http://docs.appcelerator.com/titanium/latest/#!/guide/Alloy_Framework
Well Alloy is indeed a framework that is based on the MVC architecture, maybe what you need is to get some insight on the design goals of MVC and how they can be achieved using the separate roles for each unit of software. Here is a very good article I would recommend: http://blog.codinghorror.com/understanding-model-view-controller/
The fact that you can specify view structures using only xml files and styling using only static properties means that Alloy is a very well implemented MVC framework as it does not allow you to mix the responsibilities of each role.
My 2 cents of understanding Alloy:
controller.js
Here place only code that handles ui element events such as clicks, taps and so on. Your controller should pick up an event and call a method belonging to some external common.js module that you should require using require(). It is fully supported in Alloy.
view.xml
Here you only specify the tree structure of your ui elements. This means what component belongs where and to which other component.
style.tss
Here you should specify anything that has to do with colors, position, layout etc.
I'd like to tap your experience regarding the use/deployment of a JavaScript powered framework to implement a GUI frontend for different backend tasks.
The framework would have to provide a managable way of displaying arbitrary data fetched from a database (data can be provided in every thinkable way JSON, XML etc.) and allow the manipulation of that data by means of a clean and RESTful API. Prebuilt widgets (tables/lists/dashboard) and UI (drag'n'drop/sorting) would be nice to have but aren't mandatory.
The requirements are:
Open Source (obligatory)
clean and RESTful API to fetch, display and manipulate data
Ability to extend the functionality thru plugins
Standards-compliant (IE does not have to be supported)
Thorough documentation and/or helpful community
I've figured that jQuery's UI framework comes very close to the ideal, though it lacks a decent support of general structures to master a full-fledged application.
I'm interested of what you guys would recommend.
Thanks in advance.
After years of using several of the available frameworks I now use Yahoo's YUI3 (3 - not the older 2) if I can - for "serious" apps. For HTML page enhancements I'm indifferent and may sometimes prefer jQuery.
http://developer.yahoo.com/yui/3/ (BSD license)
What I like about YUI3 are the very "deep" concepts behind it for serious "enterprise level" software development. Regardless of what framework one uses, EVERYONE seriously developing in JS should have viewed (and understood!) the videos on Yahoo Developer Theater, especially the presentations by Douglas Crockford.
http://developer.yahoo.com/yui/theater/
I just started a new GWT project for a client and I'm interested in hearing people's experience with various GWT MVC architectures. On a recent project, I used both GXT MVC, as well as a custom messaging solution (based on Appcelerator's MQ). GXT MVC worked OK, but it seemed like overkill for GWT and was hard to make work with browser history. I've heard of PureMVC and GWTiger, but never used them. Our custom MQ solution worked pretty well, but made it difficult to test components with JUnit.
In addition, I've heard that Google Wave (a GWT application) is written using a Model-View-Presenter pattern. A sample MVP application was recently published, but looking at the code, it doesn't seem that intuitive.
If you were building a new GWT application, which architecture would you use? What are the pros and cons of your choice?
Thanks,
Matt
It's worth noting that google has finally written out a tutorial for designing using the mvp architecture. It clarifies a lot of the elements from the google i/o talk listed above. Take a looK: https://developers.google.com/web-toolkit/articles/mvp-architecture
I am glad this question has been asked, because GWT desperatley needs a rails-like way of structuring an application. A simple approach based on best practices that will work for 90 % of all use-cases and enables super easy testability.
In the past years I have been using my own implementation of MVP with a very passive view that enslaves itself to whatever the Presenter tells him to do.
My solution consisted of the following:
an interface per widget defining the methods to control the visual appearance
an implementing class that can be a Composite or use an external widget library
a central Presenter for a screen that hosts N views that are made up of M widgets
a central model per screen that holds the data associated with the current visual appearance
generic listener classes like "SourcesAddEvents[CustomerDTO]" (the editor does not like the real symbols for java generics here, so I used thoe brackets), because otherwise you will have lots of the same interfaces who just differ by the type
The Views get a reference to the presenter as their constructor parameter, so they can initialize their events with the presenter. The presenter will handles those events and notify other widgets/views and or call gwt-rpc that on success puts its result into the model. The model has a typical "Property[List[String]] names = ...." property change listener mechanism that is registered with the presenter so that the update of a model by an gwt-rpc request goes to all views/widgets that are interested.
With this appraoch I have gotten very easy testability with EasyMock for my AsynInterfaces. I also got the ability to easily exchange the implementation of a view/widget, because all I had to rewrite was the code that notified the presenter of some event - regardless of the underlying widget (Button, Links, etc).
Problems with my approach:
My current implementation makes it hard to synchronize data-values between the central models of different screens. Say you have a screen that displays a set of categories and another screen that lets you add/edit those items. Currently it is very hard to propagate those change events across the boundaries of the screens, because the values are cached in those models and it is hard to find our whether some things are dirty (would have been easy in a traditional web1.0-html-dumb-terminal kind of scenario with serverside declarative caching).
The constructor parameters of the views enable super-easy testing, but without a solid Dependency-Injection framework, one will have some UGLY factory/setup code inside "onModuleLoad()". At the time I started this, I was not aware of Google GIN, so when I refactor my app, I will use that to get rid of this boilerplate. An interesting example here is the "HigherLower" game inside the GIN-Trunk.
I did not get History right the first time, so it is hard to navigate from one part of my app to another. My approach is not aware of History, which is a serious downturn.
My Solutions to those problems:
Use GIN to remove the setup boilerplate that is hard to maintain
While moving from Gwt-Ext to GXT, use its MVC framework as an EventBus to attach/detach modular screens, to avoid the caching/synchronization issues
Think of some kind of "Place"-Abstraction like Ray Ryan described in his talk at I/O 09, which bridges the Event-Gap between GXT-MVC and GWTs-Hitory approach
Use MVP for widgets to isolate data access
Summary:
I dont think one can use a single "MVP" approach for an entire app. One definetly needs history for app-navigation, a eventbus like GXT-MVC to attach/detach screens, and MVP to enable easy testing of data access for widgets.
I therefore propose a layered approach that combines these three elements, since I believe that the "one-event-mvp-system"-solution wont work. Navigation/Screen-Attaching/Data-Access are three separate concerns and I will refactor my app (move to GXT) in the following months to utilize all three event-frameworks for each concerns separately (best tool for the job). All three elements need not be aware of each other. I do know that my solution only applies for GXT-projects.
When writing big GWT apps, I feel like I have to reinvent something like Spring-MVC on the client, which really sucks, because it takes a lot of time and brain-power to spit out something elegant as Spring MVC. GWT needs an app framework much more than those tiny little JS-optimizations that the compiler-guys work so hard on.
Here is a recent Google IO presentation on architecting your GWT application.
Enjoy.
-JP
If you're interested in using the MVP architecture, you might want to take a look at GWTP: http://code.google.com/p/gwt-platform/ . It's an open source MVP framework I'm working on, that supports many nice features of GWT, including code splitting and history management, with a simple annotation-based API. It is quite recent, but is already being used in a number of projects.
You should have a look at GWT Portlets. We developed the GWT Portlets Framework while working on a large HR Portal application and it is now free and open source. From the GWT Portlets website (hosted on Google code):
The programming model is somewhat similar to writing JSR168 portlets for a portal server (Liferay, JBoss Portal etc.). The "portal" is your application built using the GWT Portlets framework as a library. Application functionality is developed as loosely coupled Portlets each with an optional server side DataProvider.
Every Portlet knows how to externalize its state into a serializable PortletFactory subclass (momento / DTO / factory pattern) making important functionality possible:
CRUD operations are handled by a single GWT RPC for all Portlets
The layout of Portlets on a "page" can be represented as a tree of WidgetFactory's (an interface implemented by PortletFactory)
Trees of WidgetFactory's can be serialized and marshalled to/from XML on the server, to store GUI layouts (or "pages") in XML page files
Other important features of the framework are listed below:
Pages can be edited in the browser at runtime (by developers and/or users) using the framework layout editor
Portlets are positioned absolutely so can use scrolling regions
Portlets are configurable, indicate when they are busy loading for automatic "loading spinner" display and can be maximized
Themed widgets including a styled dialog box, a CSS styled button replacement, small toolbuttons and a HTML template driven menu
GWT Portlets is implemented in Java code and does not wrap any external Javascript libraries. It does not impose any server side framework (e.g. Spring or J2EE) but is designed to work well in conjunction with such frameworks.
I have a problem that I feel is best implimented in a stand alone windows application, but needs to pass data to a web page that is already open.
Is it possible to pass the data directly to the web page?
If so, what is the best way to go about it?
(Its my first question, so go easy on me!)
This is not going to be an easy problem to solve, but I think it's possible by hosting the web-page in a browser embedded in a .NET application. This Code-Project article might help
Also this article talks a bit about accessing the DOM through a C# application.
Have you got any requirements on language? And can you add a bit more detail about exactly what you're trying to achieve?
EDIT 1: Watij is a web-application testing framework for Java. You can use it to fill in text-boxes, click buttons etc. I think it might fit your needs and, if it doesn't, it's open-source, so you might be able to hack it to work. There is a whole family of Wati* products - Watin for .NET, Watir for Ruby, etc.
Getting access to external web pages are not permitted due to security credentials.
But you can open and write to a web page via winInet APIs.
Please go through the article
http://www.informit.com/library/content.aspx?b=Visual_C_PlusPlus&seqNum=107