I have been using DOJO in Case manager. Do we really need to use DOJO for customization. The coding is similar to Javascript. Is the any relation between DOJO and javascript. What is the difference
Dojo (or more formally Dojo Toolkit) is a framework for developing JavaScript applications similiar to React or Vue.js.
It is (or least was) the framework of choice by IBM for the Web UI development for their Enterprise Content Management/Digital Business Automation (at least for IBM Content Navigator, Case Manager, FileNet and the IBM Content Collector for SAP UIs).
It provides reusable general components (Widgets) for UI and in the case of the Case Manager specialized Widgets to work with the Case Manager system (such as the data model etc).
While customizing and extending Case Manager you write JavaScript with some syntax for class/module loading specific to the Dojo Toolkit.
So there is really no difference between using JavaScript or the Dojo Toolkit.
As for the question if you have to use the Dojo Toolkit, the answer must be yes, although sometimes you will get away with vanilla JavaScript, but most of the time you will need to use the Dojo Toolkit (or the JavaScript libraries provided by IBM Case Manager).
At least for the IBM Content Navigator there is some ongoing effort to integrate React respectively replace the Dojo Toolkit with React. But I doubt, that this will happen anytime soon, especially for Case Manager.
Related
Hello Gurus / AEM Experts.
I have a situation here and need your advise as to will it add value in performing responsive testing for AEM components.
Currently Our AEM application dev team uses AEM 6.2 for there component development. What I understand from them is they are using Bootstrap and developing the custom components. It could be a Tile , Button , Image , Hero component.
I belong to the testing team and do you see is it necessary to test the responsive design of the components ( using tools like Galen Galen Framework | Automated testing of responsive design )
My understanding is that the out-of- box components created in AEM are already comply to responsive design. Will that imply to the custom components.
Looking for your valuable inputs based upon which We could devise the next steps.
Thanks
Will that imply to the custom components.
Short answer: no, unless the devs have made those custom components responsive.
It depends on project requirement. In my current project custom components are responsive and we are doing responsive testing. We have used Galen for the automated testing of look and feel for responsive design.
I've been reading about Durandal and Aurelia every time I read something new on Javascript. I hear developers asking to upgrade from Durandal to Aurelia, or similar, on so many blogs. Although I do have an idea, I am confused about what the two really are and how they are related, or if at all they even are related.
Here's how I see it. Durandal is a lightweight SPA framework that allows you to leverage the best of other JS libraries and utilities to build an app. So it's not really a whole package in itself (unlike Angular), but can use different external JS libs - such as Knockout for binding, jQuery for DOM, Sammy for routing, etc.
Aurelia, on the other hand, is where the confusion comes in. Is it also an SPA framework? Or is it limited to being a client-side (front end) framework only? To add to my confusion there is a Durandal blog that talks only about Aurelia. I know from the internet that Rob Eisenberg worked on Durandal before he started working on Aurelia. So is Aurelia an upgrade of Durandal, or something completely unrelated?
I still have some questions but I'm guessing the structure of my question so far will be only asking for opinionated answers. So before this question is closed, any description, links and references in regard will be amazing. I'll be sure to update and add useful links here too.
According to Rob Eisenberg:
"Aurelia is just a vNext of Durandal. On occasion we've even called it Durandal Aurelia. Much like XBox 360 vs. XBox One. The web is significantly evolving, so we're evolving Durandal into Aurelia to match."
Aurelia, on the other hand, is where the confusion comes in. Is it
also an SPA framework? Or is it limited to being a client-side (front
end) framework only?
Yes, it is a SPA framework. Actually, it is a framework for building Javascript clients, it means you can develop apps for Browser, Desktop and Mobile. Take a look at this video https://channel9.msdn.com/Events/Seth-on-the-Road/DevIntersection-2015/Rob-Eisenberg-on-Aurelia
Different from Durandal, Aurelia comes with the full package, everything you need is there. However, it is perfectly pluggable and extensible, and you can combine any other technologies if necessary.
Here is description provided by the official site www.aurelia.io
What is Aurelia?
Well, it's actually simple. Aurelia is just JavaScript. However, it's not yesterday's JavaScript, but the JavaScript of tomorrow. By using modern tooling we've been able to write Aurelia from the ground up in ECMAScript 2016. This means we have native modules, classes, decorators and more at our disposal...and you have them too.
Not only is Aurelia written in modern and future JavaScript, but it also takes a modern approach to architecture. In the past, frameworks have been monolithic beasts. Not Aurelia though. It's built as a series of collaborating libraries. Taken together, they form a powerful and robust framework for building Single Page Apps (SPAs). However, Aurelia's libraries can often be used individually, in traditional web sites or even on the server-side through technologies like NodeJS."
Some of the greatest advantages of Aurelia (in my opinion) are:
Powerful Data-binding. Different from others frameworks like Angular, Aurelia uses new features of Javascript. So, all data-binding stuffs are usually faster in Aurelia (source http://blog.durandal.io/2015/12/04/aurelia-repaint-performance-rules/)
Simple Conventions and Simple Syntax. It is really easy to develop in Aurelia. There are a lot of features ready to use. If you want to overwrite some convention, usually 1 line of code is enough. (see http://aurelia.io/docs.html#/aurelia/framework/1.0.0-beta.1.0.3/doc/article/getting-started)
Hope it helps!
I am working on enterprise-level business applications, and now is the time to start thinking about the non-desktop experience.
We have a common component code-base that is using dojo, and are trying to get as much code re-use as possible.
I am really struggling to determine if I should re-use the same code base, or have separate code bases for desktop and mobile.
A big factor in my decision making is the viabliity of dojox/mobile.
It seems pretty cool, and uses the dojo infrastructure which is a huge win, but the fact that it is in dojox scares me a little.
Some questions:
Is dojox/mobile something that can be relied on long term?
Is it a smart idea to try to swap out dijit components for dojox/mobile components depending on what has.js can tell me?
Will dojox/mobile be a part of dojo2.0?
I would add that in Dojo 2.0 the plan is to converge as much as possible the desktop (dijit) and the mobile (dojox/mobile) widgets which should help in your use-case. See: http://mail.dojotoolkit.org/pipermail/dojo-contributors/2013-June/029041.html
You can rely on dojox/mobile. DojoX will indeed disappear from the Dojo Toolkit in 2.0, but most matured (and probably maintained) modules will be pushed to the dijit/dojo library. I quote the reference guide:
In the future (Dojo 2.0), the DojoX package and namespace will
removed. Sub-Packages and modules will be either integrated into the
Dojo Core, Dijit or separated as their own stand-alone package. For
the 1.X code stream though, in order to ensure backwards
compatibility, all these packages are contained within the dojox
namespace and package.
If we look at the explanation of Mature, we can read the following:
This package or module is considered mature and is being actively
developed and maintained by committers within the Dojo Toolkit. It is
expected that it will persist into the foreseeable future.
Source
And if you look at the link above, you will notice that dojox/mobile is categorized as mature.
Another reason you can rely on it is that IBM (which can be considered a pretty big company and committer to the Dojo toolkit) also relies on dojox/mobile for their mobile product called IBM Worklight. If they rely on it, then there's no reason you couldn't.
I don't think it will be easy to start from the same code base and swap out dijits for dojox/mobile components. Usually mobile app development requires an entire different strategy than web applications. You will probably have to split certain things into multiple views and some dijits may not have a mobile alternative.
You can probably re-use most of your utilities and business logic, but I think you will have to start from scratch again if you want to write your view(s). But I'm not really an advanced mobile developer.
I am coming from desktop dev background, wpf/SLight, and looking at switching to MVC application. Given I am absolutely rubbish at making stuff "pretty" what would be the best toolkit/widgets to invest in to help me on my way?
Looking for ease of use; UI look and feel; price?
I have experience with following control toolkit.
JQuery with JQuery UI : http://jqueryui.com/ Free and open source. Lot of community support, Lot of plugin to extend. you have more control over plugins and code. Very light. I have extensively use several mvic projects and I do recommend.
MVC controls toolkit. : http://mvccontrolstoolkit.codeplex.com/ - Free and open source code plex projects that you can use your mvc application.
DEvexprss mvc extension. http://mvc.devexpress.com/ : Commercial product with all necessary control for mvc application. Learning curve is bit high. But you can get very nice look for your application easily. Customization is difficult. They have good support from you technical issues. I have use for projects.
Kendo UI : http://www.kendoui.com/ commercial product from Telerik. I haven’t use in commrical project this but seems good.
One of the most popular UI frameworks is Twitter Bootstrap (FREE). It is built on top of jQuery and has lots of pretty widgets that are easy to use.
Another framework I like to use is KendoUI from Telerik (Price depends on what you need). It is very declarative so you simply need to add attributes to your html elements and it will take care of styling for you.
I am a newbie to extjs and kind of new to javascript world also. I have developed applications in jsp/servlet, JSF etc.
We are planning to use extjs along with Sencha Architect to develop UIs for our application.
Being new I have several questions for which I am searching answers
Q1. How should we use Sencha Architect in multi developer environment in terms of versioning. Shall we checkin the Architect project into svn and ask each developer to work on same project.
Q2. What should be the structure of Sencha Architect project (Basically how to make sure each developer is working on his/her individual module without affecting others component).
Is there any best practice for this.
Q3. What is the best practice for developing an application which contains several pages along with navigation. Should we create a single html file (with lot of javascript to modify the body) or should we have multiple html?
yes, it should certainly be in source control. you will want developer-specific settings to not be in source control however.
the best way is to create an application "shell" with menu bars, and load in modules/plugins and have them register with the application, adding their own menus etc.
definitely a single page application. security remains on the server though (for example in your REST API). security is irrelevant on the client as they have control over source code. you should just hide functionality that a user should not use.
How to load different views into viewport?