It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 9 years ago.
Can someone please direct me to a resource containing an advanced backbone.js example?
by advance I mean multiple pages with nested views, complex layouts etc.
I have browsed the web, gitHub repository, blogs and even purchased the "recipes with backbone" book. All of the samples are at a level of simple SPA (yes I know backbone is for that, but I know it can do much more) level, a todo list calendar, adding and deleting notes etc.
Is there something a bit more advanced and complex that I can learn from? I'm no expert in backbone
but for me the best way is to learn by sample
While it's not a complete example (it doesn't do any server-side communication, yet), I've been building a larger example app at http://bbclonemail.heroku.com
This project serves two purposes for me: providing a more in-depth example app, and providing a playground for new ideas that I have which often end up in my Backbone.Marionette add-on (go to http://github.com/derickbailey/backbone.marionette).
There are also several good examples listed in my http://backbonetraining.net/resources page, including a Wine Cellar application, a backbone 'store', and a handful of sample projects on github from various people.
DocumentCloud
http://www.documentcloud.org/public/search/ and perhaps https://github.com/documentcloud/visualsearch in particular
Tzigla
http://tzigla.com/ source here http://tzigla.com/assets/board.js
QuietWrite
http://www.quietwrite.com/ source here http://www.quietwrite.com/assets/app.js
Diaspora X^2
https://github.com/bnolan/diaspora-x2 with source in Coffee
InterMine Lists Client
Peek into the source, it is packaged by Brunch and it is a learning experience for me too:
https://github.com/radekstepan/intermine-lists-client
Here is my github, I've started to build out a framework to help people use backbone and Jquery to build mobile development projects. But you can use the same ideas, with Node.js and Express. Really any Javascript project.
https://github.com/DarrenHurst/BroadStreet
Have you checked the todo-example? Is it complicated enough?
http://documentcloud.github.com/backbone/#examples-todos
Here is an interesting sample app organised in modules containing models, collections and views.
demo: http://githubviewer.org/
sources: http://github.com/tbranyen/github-viewer
I wanted to get inspired with this Backbone Contact Manager and I found it interesting the way it manages the views, only by model an collection events.
The article also has some tips at the end.
Related
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
I'm starting to architect a new Windows application that will require a fairly rich client interface, but I have no idea what client API I should go with (WPF, Silverlight, WinRT, HTML5, other?). I'm actually rather disturbed that there is so little guidance from MS to help people make this decision.
Whats the MS support strategy for the different client APIs? Whats the longevity for each? I dont want to write a full client application in a currently known and supported API (WinForms or WPF) only to have MS pull support for it in two years, and be forced to re-write it. But I really cant write it in WinRT because mass corporate deployment wont be in place for at least 2 years. So am I forced to go with a web based approach, like Silverlight instead? Whats its support/longevity story? Do I go HTML5 instead? If I go that route, whats the benefit of using the Microsoft stack instead of just going the open source stack?
It feels like I'm in a total catch 22 here, and I cant find any good guidance from Microsoft. From the sounds of things it would be stupid to write software in WPF because its being dropped (soon?), but I cant write it in WinRT because corporations wont deploy it for a couple years. This whole thing just feels completely skitsofrantic to me.
Thoughts or ideas?
Taking your experience into account, and also the fact that you said 'Windows Application' (not web application) I would definitely go with WPF. Keep in mind that regardless of using a different set of underlying APIs, WinRT still keeps the core concepts of WPF: XAML, Bindings, Styles, Triggers, DataTemplates and so on. So, while it is true that you cannot copypaste code from WPF to WinRT and press F5, there is a significant amount of work that would be compatible between these technologies (namely ViewModels that are view-agnostic), while HTML, Winforms and other frameworks have completely different ways of doing things, and require a different mindset to work with.
In regards of what will Microsoft do.. I wouldn't be too worried, because evidence shows that even older technologies such as VB6 still remain "runnable" in current versions of OSes, and I don't think there will be a need to rewrite the whole application in 2 years even if Metro becomes a standard. Metro cannot replace desktop traditional applications, which still prove to be the best option for data intensive applications.
And, if it ever comes the time when all of us are really pushed into WinRT, it's gonna be immensely easier for those who made SL / WPF applications already written using MVVM and XAML, than for those who did HTML or winforms.
Whatever you end up choosing, make sure you separate as much as possible your application's functionality from the UI. This will definitely make it a lot easier when a UI framework change is required.
This is just my personal opinion, and I would like to hear what other people have to say about this subject too.
Edit: Another really important aspect is that if you need to really make an animation-intensive UI, or take a step away from traditional battleship-gray UIs, you're gonna end up suffering a lot from winforms incapabilities on this, or HTML/Javascript hell where all browsers render things differently, not to mention the amount of code required in these technologies to achieve things that require 3 lines of XAML in WPF / SL / WinRT.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'm new to backbone.js and am working my way through some tutorials. I've found a couple that seem good, but there are some inconsistencies in how they implement so I'm looking for a little guidance on best practices.
Here are the tutorials I'm learning from:
http://www.jamesyu.org/2011/01/27/cloudedit-a-backbone-js-tutorial-by-example/
http://coenraets.org/blog/2011/12/backbone-js-wine-cellar-tutorial-part-1-getting-started
My questions are:
The first tut makes use of Backbone.Controller but not Backbone.Collection. The second does the opposite. Which is the best practice for the "C" in backbones spin on MVC?
The first tut defines urls in the Model, whereas the second defines it in the Collection. Which is the better practice?
The second tut makes use of Backbone.Router, while the first one does not. Which is best practice?
Alternatively if someone can suggest a better intro tutorial that follows best practices I'd be happy to learn from there. Unfortunately because of the inconsistencies between these two, I'm concerned I might be learning some bad habits out of the gate.
Thanks in advance.
Backbone.Controller was renamed to Backbone.Router last year. I guess you were reading an old tutorial.
BackboneTutorials.com is a decent tutorial for getting started.
Build a small app as you learn and you'll know what Backbone does for you.
The best way to learn Backbone is to go through the annotated source code. Each and every line is commented and explained.
Use the dev version instead of the minified version when building your app. This helps in debugging.
If you are into reading books, check out Addy Osmani's Backbone Fundamentals, a free e-book. The book is awesome, but quite verbose. You can use it as a reference.
See this question on Quora for the definitive list of resources;
Don't worry too much about what's 'V' and what's 'C' and backbone's spin on MVC.
The framework does an excellent job of separating code that interacts with the server and the code that performs the core client logic. Templating and updation of DOM Elements is left to you. It's pretty minimalistic in that sense. Backbone provides Events that make the different parts interact with each other.
this is a good question. Though, Backbone isn't taking position on how you should organize your code.
So, the real answer is: it depends.
It depends on the need of your application and how you're used to program.
If you want an overview of some best practice, I'd refer you to the Backbone Boilerplate project: https://github.com/tbranyen/backbone-boilerplate
This project is pretty solid, and really helped me out when starting.
Then, to answer your question (this may feel opiniated, and it is indeed):
1: Backbone is mostly an MV* framework (Model-View-Whatever). Controller logic mostly live into Backbone view, and this is OK for front end developpement as logic is often really tied to the UI (as we are mostly coding interfaces). Backbone isn't coming built in with controller, but if you prefer this type of organization, just build your own.
2: Urls depends on your need. If you're fetching a full collection, set it up on the collection, if you're only fetching (or probably saving) one model, set it on the model. These too live well together.
3: About Router, if you're building multiple pages/sections on your app, use them. But beware of not using routes as action as you would do in RESTful APIs, this will most of the time brings problem eventually (user press back button, etc). So, use routes if you want to manage pages.
Hope this help !!
I will answer from experience:
Q: The second does the opposite. Which is the best practice for the "C" in backbones spin on MVC?
A: There is no Controller in current Backbone http://backbonejs.org/ - "C" happens either in View (most cases) or in Router (see below).
Q: The first tut defines urls in the Model, whereas the second defines it in the Collection. Which is the better practice?
A: There are cases when you don't need collections. In case when you don't, your model absolutely needs a URL. When you do have a collection, URL you specify for Collection will apply to its models.
Q: The second tut makes use of Backbone.Router, while the first one does not. Which is best practice?
A: Rule of thumb - you want to use Router in 2 cases: 1) when you want to have history, and 2) when you want to have permalinks. Otherwise you don't really need router.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
After years /decades of using tasks managers: Lotus Notes, Outlook, Palm (that was a good one), etc.. and now using Appigo, after using Toodledo, a friend of mine and me (both programmers) got tired of how far are all those from our personal GTD style and we decided to build one, something that we can customize as much as we can moving forward. We will do it open source open to public.
Appigo and Toodledo a great inspirations from a functional and technological point of view. We like the server on the cloud, the clients on browser and mobile platforms.
We have been thinking this for a while but when we saw Grails and did some of the tutorials, coincidentally on the task manager subject, we said ‘great, we can use this technology to build ours, this sounds cool’. (at least for the web part and the model, the core part).
Following Appigo strategy also, we plan to use Google App Engine for hosting the back-end.
On the mobile side, since we do not have time for hard core objective-c and stuff and we have a decent experience on Javascript frameworks we decided to use the now popular HTML5/Javascript approach and we think we decided for Sencha but any other Framework may be fine (Dojo, jQuery, etc).
Not surprisingly, our mobile and web clients will communicate with the server primarily using REST and we plan to have a server-side MVC (Grails) and a client-side MVC (like Sencha or Dojo propose)
We do not want to bother too much about databases, we love the Grails idea of creating a model-driven objects and storage.
Our project will be open source and hosted on github for anybody to use it.
Ok, here is the actual question:
Do you guys know good books or sample apps or articles that can help us go through this end-to-end. Of course we could go alone, but we will greatly enjoy going through some books, tutorials first to glue of these things together, decide good patterns to use, learn tips, experiences..etc. We do not have experience with Grails. (but a lot of java and javascript web development), of course I can find books about Grails but we want something end to end, with a good sample focusing on practices and patterns.
Basically a book or article that somehow touches part of this topic “good practices and experience building something like a task manager that runs on Google cloud platform, has the server side done with Grails and the browser and mobile clients using robust HTML5 javascript frameworks”.
Can anybody point us into this?
Thanks!
I have done a couple of engines that are build using grails + the google app engine. My experience is that you are going to have to build up the knowledge thought actually doing the work.
It's very easy to start out but once you get about knee deep there are some very interesting problems that can crop up.
Now that being said the main resources that I have found useful are the following:
http://shop.oreilly.com/product/9780596522735.do
http://www.amazon.com/Groovy-Action-Dierk-Koenig/dp/1932394842
http://www.manning.com/gsmith/
https://developers.google.com/appengine/docs/java/overview
The link above gives a good java over view. But you will need to be able to distill that down to groovy.
http://www.grails.org/plugin/app-engine
and finally www.google.com
but i found that most of the blogs out there are dated to earlier version of grails. And a lot of the issues they were seeing have been fix in 2.0 or are no longer issues at all.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I've been slowly and a bit painfully working my way up the datastore/JDO learning curve in GAE. Recently I've found a framework called Objectify that is supposed to be somewhere between the very-simple Datastore native API and the complex JDO. I've been reading up on it and it does seem attractive.
What I want to know is, if anyone has much experience with Objectify... How mature is it? Is there much of a user community? Is it ready for heavy-lifting primetime? Could it be abandoned?
There doesn't seem to be much discussion of Objectify here or on the web in general, which makes me nervous about entrusting my project to it.
I've looked into objectify a bit and wrote an initial post about it at http://borglin.net/gwt-project/ . There are actually at least 5 different low-level wrapper frameworks at this point (objectify, Twig, SimpleDS, siena, slim3).
I'm currently working on a interview-style comparison between objectify, Twig and SimpleDS together with the authors for each framework. They will answer a bunch of technical questions and I will do some code scenarios with each framework.
In the mean time, you might want to check out these threads:
http://groups.google.com/group/google-appengine-java/tree/browse_frm/thread/4467986eaf01788b/c6d007863a616a1b
http://groups.google.com/group/google-appengine-java/browse_thread/thread/f20d922ffecb310c
http://groups.google.com/group/google-appengine-java/browse_thread/thread/79078132130a3dfe#
For all who are looking for the interview-style comparison between objectify, Twig and SimpleDS as mentioned by Andreas Borglin, it is available here: http://borglin.net/gwt-project/?page_id=604
I've just ported from JDO and the low-level API to Objectify, and I'm sold. Automatic use of Memcache, much easier (and shorter) queries, fewer surprises. I like that it doesn't hide the nature of the datastore - it just makes it easier to use.
You might also want to check out the recent announcement of the Twig final release 1.0:
http://groups.google.com/group/google-appengine-java/browse_thread/thread/aafbeb679a6e6790
It gives a good overview of what Twig is capable of. A point of interest is the ability to do non-blocking async queries which is only possible with Twig at this time.
Objectify is Ok but there is nothing better yet. Twig is relatively new, As of 09/21/10, took a look at documentation, examples, discussion groups of both and looks like it has some ways to go before getting mainstream. Not many claimed features have out-of-box working examples. I love the succinct documentation from Twig as opposed to the Verbose yet somewhat clear documentation from objectify. Objectify seems to want me to do lot of work, e.g. no managed owned relationship support etc. But given everything that it gives on top of plain JDO/JPA and also given JDO/JPA does not give much, I will say Objectify is the best choice for now.
You can read this article. It provides a very good comparison between Objectify and JDO
http://borglin.net/gwt-project/?page_id=491
It is a late reply but i diged into this issue as you. As i wanted to use lucene and compass at that time for full text searching and then i found you can use objectify in full text searching in this project
http://code.google.com/p/fulltext-search-in-objectify/
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 9 years ago.
Has anyone got experience with the white framework?
www.codeplex.com/white ?
I'm thinking about using it for the next project for basic smoke tests of our windows client. I'd like some advice on articles or your own experiences. Thanks.
I recently used white to build a few (20+) UI tests for a fairly complex WinForms app with plenty of UserControls, dynamically created and 3rd-party controls.
Here are my impressions:
Very easy and intuitive to work with.
Little or no quality issues.
It's a young project so there are
some missing features, but they've
got the basics covered.
Occasionally, if a control didn't have a known AutomationID, I was forced to use keystrokes to navigate to and manipulate a control ("tab, tab, enter" for example) which was kind of a bummer, but still very easy to do in white. This usually only happened with 3rd-party or dynamically generated controls.
White's recorder is helpful (and will actually generate code for you) but does often get confused by complicated or unusual controls. For that reason I'd recommend that you...
...keep UISpy nearby so you can see the AutomationID of the controls you're working with.
And finally, if you're like me, you're hoping to set up some automated tests. This can be tricky since an automated test will usually be run by a CI tool such as CruiseControl which runs as a Windows service, which therefore has no active graphical environment (Windows session)...which white requires. The suggested way around this is to use a virtual machine. This is where I lost steam, as my tool chain had just grown too large for my purposes: CruiseControl->NAnt->NUnit->white + virtual machine.
Anyway, hope that's useful.
I evaluated it recently, but had to reject it because it would not support the third party controls (janus grid) we were using.