How much effort would it be to update the framework to the newest material design standards eg used in material-ui?
Specifically I'm looking into updating text-input fields to the outline textfield design. Is there a way to easily "import" the newest material design standards on bulk without touching every single component?
I think it's a great deal of work indeed: You'll need to fork the ra-ui-materialui package, upgrade the dependency to material_ui, and fix all the things. And you can trow away your work just after that, since material-ui is again going to break BC with V4.
This has been discussed in the react-admin repository:
Material-ui 3 is a BC break over material-ui 1, so upgrading that dependency would be a BC break for react-admin, too. We'd have to release react-admin 3.0. Since the latest stable (2.0) is not that old (May 2018), we'll wait a few more weeks before breaking BC again.
I advise you to use material ui v1, or to wait a few more months until the react-admin core team makes the switch to material ui v4.
Related
I am looking for a javascript solution which can unordered list to a treeview with checkboxes.
So far the best one I have seen is Dynatree. However, looking at the page and the fiddle , I learned that there is a designated successor named Fancytree.
I am planning to implement the solution in a production environment.
Which is the best library to use?
As of today (nov. 2013) Dynatree is the stable version.
While the core functionality in Fancytree is already pretty stable too, there still may be some changes to the API and markup. I am planning to release Fancytree early next year.
So if you want to be on the save side, use Dynatree.
If you are fine with core functionality, want to help to test and improve this open source project and are ready to modify your code every now and then: use Fancytree.
(Disclaimer: I am the author of both.)
Update 2014-05-01
Today I released v2.0.0
Dynatree is EOL. Last commit was on 19 Aug 2016.
I will support Dynatree for a while, but no new features will be added.
It is recommended to migrate to Fancytree. It's easy: see also the migration hints.
Src
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 was doing a bit research and I came across this comment.
I have been working with Sencha products since Ext2. Throughout all
these years I have been rewriting my code numerous time just to adapt
to their freaking changing coding pattern.
From the troublesome Class.superclass.method.call() to the new
me.callParent(), till the recent adoption of initialize & removal of
initComponent in ST2, I would suggest you to go for the newest release
since whatever in the past will not be reuse again. Learn the new
coding style, don't waste time on the old structure. It won't help you
much, considering our web is changing very fast and ST1 and ST2 is
pretty disjoint as well.
While 1.1 is good old solid (much like Ext), v2 is much fun to work
with with the auto loader.
I'm ok with change, but I don't feel like revising my application every 6months or so.
My question is: how often does Sencha bring out a new version? (Can be EXTJS or Touch).
I did already try to find it on the website of Sencha but I think previous versions are banned to the dark ages or something.
There isn't a public road map available but like any software that is still growing, expect newer versions to be released. With the mobile space changing at a rapid pace, the Sencha team has to address those changes and meet the needs of their customers. It shouldn't be a deterrent from using Sencha products. In fact, with the release of ST2 and many adoptions from Ext JS4, they have not only simplified their path/direction but made it easier for us developers.
A very quick google for ext js wiki.
A very quick google for sencha touch wiki.
I have to evaluate Sencha Touch for building native Ipad html5 based apps. I was wondering which version should I start with v1.1 or v2.0?
I bought this book and created a simple html5 app (with Panels, proxies, MVC, toolbars) and integrated it with Java Spring and freemarker templates. All worked perfectly , the book was excellent and the onine documentation was great. This was with version v1.1.
Then Sencha announced that v2 is out with lot of improvements especially in performance. This made me think whether I should start again with 2.0 or just continue building on my prototype with v1.1 and wait till v2.0 gets more mature and has more documentation.
I have been working with Sencha products since Ext2. Throughout all these years I have been rewriting my code numerous time just to adapt to their freaking changing coding pattern.
From the troublesome Class.superclass.method.call() to the new me.callParent(), till the recent adoption of initialize & removal of initComponent in ST2, I would suggest you to go for the newest release since whatever in the past will not be reuse again. Learn the new coding style, don't waste time on the old structure. It won't help you much, considering our web is changing very fast and ST1 and ST2 is pretty disjoint as well.
While 1.1 is good old solid (much like Ext), v2 is much fun to work with with the auto loader.
I built two native Cordova (formerly PhoneGap) apps on iOS lately and the performance is pretty good so far.
IMHO, Sencha Touch 2 is easier to learn and work with. While it was just released as final, there are so many improvements and enhancements to the framework that even with a few bugs here and there I don't see why you wouldn't want to go this route. The documentation is pretty well baked, sporting lots of examples and guides. I think you'll find that you can accomplish quite more with ST2 than ST1. Cheers!
I would go with Sencha Touch 2 all the way. The API is a vast improvement over 1.1 and you are getting much better performance as well, ease of use and improved MVC structure.
Here is an App I recently built using Sencha Touch 2 and was featured in the Sencha touch app gallery: http://www.sencha.com/apps/flosports/
This app was also packaged to native for both iOS and Android using phonegap 1.4.1 and it worked pretty well.
We are in mid of a project where we have used an extended Dojo 1.1.1 to meet the customer requirement and add richness.
But there are quite some bugs and performance problems with this version of Dojo and
we are looking ahead to migrate the Dojo version to overcome both the issues, but the migration cycle seems to be quite painful and may not be yield expected result.
The concern we have is with the various extension which we have created with the version of Dojo for components that were provided in 1.1.1 and the impact on them after migration.But, the advantage we see are equally important.
As per Dojo , they have kept some level of compatibility with version 1.1.1 but i have not seen any discussion around this anywhere.
Has any body else previously done
migrated between Dojo version?
Will the components like Grid will
work as expected or will i need to
carry out a refactoring exercise?
Do we have any commercial support
available as the forum seems to
deprecated?
Any help or suggestions are welcome
Dojo has had a policy of freezing and supporting public APIs since 1.0. Migrations prior to 1.0 were extremely painful. Now, it should be much better, provided you use only public APIs. Code written for stable JS APIs in Dojo or Dijit in 1.1 should largely still work. Exceptions are noted in the release notes, which you should explore (good luck finding them... unfortunately the site is a bit of a mess)
If you wrote any custom widgets, you're probably in for some extra work. dojox.grid was not particularly stable at that point, and it has also seen a major rewrite since then (there is an old 'compat' layer you may wish to use)
Regarding for forum, like the note says, you can either use the active dojo-interest mailing list or post questions here at SO. There are some firms which offer commercial support, but that's outside of the scope of Dojo as an open source project. (try googling 'Dojo commercial support' or asking on dojo-interest)
I have done 5 dojo migrations now (from 0.2 -> 1.4) over the last few years. Although the API does not change, you will often have coded in workarounds that no longer work after upgrading. Things I have noticed:
quality in 1.4 is VERY good and worth
upgrading to (even from 1.3)
although
the API does not change, little
things that are not public often
change slightly (diji.Tree
itemNodeMap -> itemNodesMap in 1.4)
build options are usually added each
release but not always publicised -
strage really as they are always
useful improvement
since you are 1.1.1, you should change all your set attribute calls to 'attr' - this could take a while to do.
As for commercial support, you could try Sitepen