I have setup openfire server and I am able to connect converse.js client. It is working fine.
I however do not want to use the converse.js UI. Is there a way to only use converse api without the Backbone UI part.
I tried removing the Backbone part but it is not working.
I understand it uses strophe internally but converse have readymade functions
Firstly, it should possible to use Converse simply as an engine, or API and I've done some work to make this usecase feasible. Specifically by splitting Converse out into plugins. However, I haven't used it myself like that yet, so it's rather theoretical still at this point.
Backbone is however is critical, because it's used for more than just Views. Backbone Models and Collections are used to model data and relationships between objects. So you can't remove it.
As mentioned, Converse is made up of plugins. The plugins that are included in the final build (created by running make dist) are all listed in src/converse.js.
You can create customized builds by editing this file and removing plugins that you don't want.
So for example the converse-chatview.js plugin contains Backbone Views for rendering chat boxes. So it can be removed. Similarly the converse-controlbox.js is a View that renders the control box can also be removed.
Other plugins to remove would be converse-minimize.js and converse-dragresize.js, both which are UI-focused.
However, here comes the fly in the ointment. converse-muc.js, which provides support for groupchats contains boths views and models, and is not yet split up. So if you need to support groupchats, then you'll need to include that plugin and its views in turn depend on converse-chatview.js, so it will also be included (even if you remove it from converse-config.js).
What needs to happen is that converse-muc.js needs to be split into two files, converse-muc.js and converse-muc-views.js (this will probably happen in a future release). Then you could remove the latter from your build.
So, sorry if this is not a super satisfying answer.
What you can also do is write your own plugins, and in those plugins you can override or change any of the Models, Collections or Views from other plugins (if your plugin depends on them, and is therefore loaded after them). This however requires you to study the code somewhat, to develop a decent understanding of what needs to be done.
EDIT: For more info on the plugins and how they work, take a look at pluggable.js which is the underlying library and the relevant converse.js documentation.
Related
Over the last week I tried to create a single page application without using the template provided by Oracle. My goal is to load the modules by clicking on simple headers or divs.
I know that OJ-Module and the CoreRouter are needed, but nothing I’ve tried so far has worked.
Maybe someone can give me some hints on this.
Thank you
I am trying similar methods and it is the best way of getting hang od the syntax, variables and the structure.
I created projects of all the 4 templates in different folders. Each one serves as a reference on how to implement a specific set of features like CSS, behaviors in my new app, created out of the blank template.
I also created a demo project. This project contains the specific element from cookbook I am trying to understand (one or two at a time and not more) and then implement the learning in the blank template, which I started filling already. The demo project keeps getting erased and recreated in my case.. You can choose to retain different demo projects if you need.
Most important will be the understanding of concepts like the busyContext, dataBinding, ResponsiveUI, Require, AMD, ojModule, inter-module interactions and the creation of events, views and viewMdels. Once you get past the initial hiccups, the APi docs are a great assistance in helping you programmatically control the entire behavior of the application features.
BTW: Do not remember the css variables. I think it is a bad idea to maintain so much material in your mind, which could otherwise be easily referenced in a document. You only need to know which documents have what content..
So I've been doing a lot of learning on Backbone, Sass, RoR, Bootstrap, etc. and I am extremely frustrated that no sources I've found (including in Tuts+ and Code School) mention any way of putting it all together...I have no clue how to style a web page if all of the contents I want in the page are being built through backbone...so if I want to click on the "About" page on a website, have all that page's Backbone contents styled correctly when appended to the DOM.
Secondly, I'm not sure how I should be creating these web pages for a website; should I be creating the whole page in Backbone and then keep that on the server until someone clicks on, for example, that "About" page and then have the whole page loaded into the view? Or am I totally misunderstanding one of the ways you can use Backbone? Along with this then, how am I supposed to communicate Backbone to a Ruby Server? just using Ajax?
I'm looking for sources and anyone who can help me understand this stuff in clear terms!
Thanks so much,
-Stu.
Presuming that you want to build a single page app it is important to understand each one responsibilities:
Rails
Create a full stack application that runs on server
Create a consumable API
Manage assets pipeline
...
Backbone
To manage your frontend javascript application
Decouple data from the views using Models
Connect an API over a RESTful JSON interface
...
Keep in mind this is a oversimplification of both...
Rails will handle the backend, retrieving an API to be consumed by Backbone. The Rails assets pipeline will deliver all files that Backbone needs, including the css that will style you app.
It might be somehow confusing since you will hear concepts that eventually will clash between them, like in both ends will have Models, Views and Router, but they will live live independently from each other, one will work on the server-side (Rails) and the other on the client-side (Backbone).
To give an example:
Rails would render:
domain
|-index.html
|-js/*.js
|-css/*.css
`-api/*.json
Backbone would use the DOM (index.html) and the js scripts to execute logic, append the views into the DOM and Read/Write data using ajax through the API.
Another confusing thing would be views, since Rails will generate those for you, and backbone will also have their own views, so the usual setup:
In the client-side, Backbone will be have at least the following parts:
Router — it will orchestrate your app, binding an event a route, let's say /#about page and create a view and pass the respective model:
Model — it will request data from the API and dispatch an event when done
View — it will use a template to render the model data
In this case Rails would manage the page assets and provide the API, Backbone would have it own router, models, views and templates to render the page on the client-side.
This also means that the way you combine both it could be only answered regarding the project specificities, and there a lot of ways to use both.
That said, IMHO it's really important to first understand how a full Backbone app works,
then use something like backbone-rails gem, to see how both can be managed in a consistente way.
I know what you mean--there's a lot of random tutorials out there for Backbone but not a lot that put it all together. To a certain extent that's just how it is, unfortunately, but I'd say once you're past learning the basics from Code School and others, the hands down best resource for how to actually build complicated apps is:
BackboneRails: http://www.backbonerails.com/
It covers the stack you're talking about mostly. The first few screencasts are free and then subsequent ones are paid but well worth it. Building on the skills I've learned from BackboneRails and I've built several fairly complicated apps that turned out great. Good luck!
We have a website written in the traditional Jquery selector-callback spagetti code. We are planning to begin migration to backbone to help clean things up.
We use mustache and use the same templates for rendering in php server-side and javascript client-side. But there are some mustache alternatives (handlerbars/dust) that we are interested in but can't explore because there is currently no php alternative. We are considering moving all server-side rendering to node so we can use the same logic/code for client and server rendering. We would be porting all our php view classes to javascript/backbone and just use php as our data/controller layer.
In parallel, we are preparing to develop a sencha touch website/app which would normally be written using the sencha/ext approaches in javascript.
The actual templating will be very different between the sencha and main site, but much of the view models could probably be the same.
There are three approaches I can think of:
use backbone as the main view models including inside sencha
use sencha everywhere using the sencha/ext classes/approach in the main site
keep them separate and either deal with duplication or try to abstract out the essential logic to other classes.
One advantage of the ExtJS route is you can use the same models, stores, etc and just have separate views, grids, whathaveyous for mobile/non-mobile. Then you can just serve up the same JSON/XML from PHP. The JsonStore/XmlStores will be the same on each platform. Been a while since I've used ExtJS so cannot offer more concise example.
I am in the process of choosing ScriptSharp for coding all my javascripts. I already use JQuery and it is great that there is built-in support for this.
But what about YUI? I need it in particular for the editor control..
How can I code the part for the editor control within Script# framework? Is there a place to enter custom javascript when a certain library is not supported or something similar?
Are there any future plans to add YUI to ScriptSharp?
It would be interesting to have YUI support, but there aren't specific plans to add support for it right now, at least not at the top of the priority list.
However, if folks in the community want to get it going and contribute, I can help with questions that come up.
The general idea is you create an import library (there is an Import Library project template when you install Script#), which defines a c# API corresponding to the OM that you program against. The C# API consists of classes and stub methods that define the signatures (think of this as a header file of sorts). There are a few metadata attributes to customize generation of script that references those APIs to get various transforms to happen ... so you can create a working, and often times more natural c# interface that then maps to runtime script constructs and APIs you are targeting.
When I see the sample at http://yuilibrary.com/ I see a bunch of parallels to jQuery, so I imagine building support for it is likely possible at a technical level.
The best way to understand how to do this would be to look at the sources of mscorlib.dll (represents the core script objects) Script.Web.dll (represents the DOM) and Script.jQuery.dll (represents core jQuery API). All of these are in the Script# repository on github ... https://github.com/nikhilk/scriptsharp ... if you haven't already seen them.
We are creating an import library for OpenLayers (http://openlayers.org) and I can say it is incredible easy to do. We started just doing what NikhilK says, inspecting the source code. The results are just great. YUI is a very well designed and documented api, so I think it would be stratightforward. You could just create the import clases you need for your project.
I am developing an rich Javascript application, using jQuery and some plugins. The application I am developing is becoming rather large and unwieldy. My main problem is managing views: I need to switch between views, some of which share the same components (like embedded views or partials). Currently my "screens" are all contained in various divs, and I am switching between them by hiding one and showing another. This makes navigation quite complex.
My question is: Is there a lightweight Javascript library that can help?
Following requirements:
No generation; I want to change the code on the deployment server, so frameworks requiring some special compilation are out of the question (like Sproutcore or GWT)
Model binding is not a necessity; I am getting the values from various forms and submitting them via Ajax requests
Want everything loaded upfront (i.e. not fetching screens with AJAX)
Must work with IE7
mootools, you can select what components you need from the framework.
http://mootools.net/core/
It turns out that what I was looking for all along was Dojo.
Dojo provides as part of its library the dijit subset library, which covers all the needed UI metaphors, including containers.
Also, as required, it does not involve any compilation as do many of the other Javascript (MVC) frameworks, and it supports IE from version 6.