I have an application which is running with dojo 1.2 having support for InternetExplorer8 only
so my problem is that I want to upgrate dojo version to 1.7 and InternetExplorer9/otherborwsers compatible,
so which API do I need to change? I am using all three dojo,dijit,dojox.
is there any solution or not ?
Thanks in advance....
There has been so many changes that I do not even know where to start...
You will probably have to rewrite a lot of code, but it is, I guess, a necessary pain to get to something much better.
You might want to write on some paper your custom widgets architectures, what they use etc, then try rewriting them in AMD with dojo1.7 or dojo 1.8 rc1
I would recommand a complete rewrite (not necessarily a complete rethink though).
Dojo 1.7+ are way much better than 1.2 in perfs, size, widgets available, power and flexibility, it is totally worth it.
Related
I'm using Vuetify Vue3 for a project. There are some components missing that are available in other fw. Does this cause messup in the project by installing extra fw for one component?
You can indeed have several frameworks at the same time, but it may drastically impact your performance and lead to messy code because of the difference in APIs.
If you are meaning, CSS like a UI framework (Vuetify, Bulma, Bootstrap etc...), the answer is the same. Doable but quite heavy.
Nothing stopping you from going crazy by using all of them!
Technically, you can use at the same time, but if you mean CSS frameworks sometimes it can lead to conflict between classes.
It is not recommended and best practice to do that because it can cause a conflict and also can make your application heavy.
But it is not forbidden and you are free to try.
In casting my eye around for a good, stable, javascript UI framework I've been drawn to Dojo. In particular, the Dijit set of UI components look really good, and are very good as far as accessibility is concerned.
My question is this: is it worth learning Dojo 1.10 (or at least dabbling and familiarising myself with it) before 2.0 comes out? Or is 2.0 going to be a "throw the baby out the with bath water" complete rewrite?
I could probably learn TypeScript as that would be a useful investment of my time. I'm just eager to start doing something productive in Dojo as I really think 2.0 is going to see a major resurgence of interest and it looks like something I'll want to commit to for 5, 10 years or more (hopefully!). Dojo seems to have stood the test of time well since it came out, and there's no reason to think that 2.0 won't be as stable, either (from what I can tell).
Thanks.
You could get familiar with Dojo Toolit 1.10 and later get updated with the new version.
In my opinion some concept behind Dojo will be remain very similar in the new version, for example:
Modules/Amd, Ajax Deferreds, Promises DOM Basics.
As mention in the Ken's comment usefull source of onformation on dojo 2 can be found here:
dojotoolkit.org/community/roadmap
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
i read about the Google Closure Compiler and i will try to use it to make my web application better. But i think it is doing the same things like the dojo shrinksafe.
Has anyone tried to use the Google Closure Compiler for a complex dojo project?
Thanks
Benjamin
Yes, Google Closure Compiler works fine with Dojo projects. Because Closure is derived from Dojo, it has similar concepts (modules, loaders, the build, and so on) so it is potentially possible to use some advanced features of Closure Compiler with Dojo, which go beyond simple minification.
We (Dojo) will evaluate what we can reuse and leverage from Closure and how we can improve interoperability. Obviously it will include all tooling too.
Closure will probably work with any valid javascript code. I fed it an extremely packed, obfuscated version of a complex Prototype project of mine and it spit out a perfectly working version. So even if your code has already been shrinked by Dojo, you can probably use Closure on top of it. You should, however, choose one of the two.
As of Dojo 1.4 (not yet released, but the code is in the subversion trunk of Dojo), you can now use Closure Compiler as an option for the Dojo build process. It takes a bit of setting up. Instructions on how to use Closure Compiler with the Dojo build system.
Dojo 1.6 is compatible (after some minor modifications) with Closure Compiler in Advanced mode.
http://dojo-toolkit.33424.n3.nabble.com/file/n2636749/Using_the_Dojo_Toolkit_with_the_Closure_Compiler.pdf?by-user=t
Stephen
I happen to have a 12,000 (26,000 if you include dojox/dijit imports) line dojo 1.3.2 application I am about to release.
Well I used the standard dojo build system to throw it all into one lovely big one megabyte file. Then I introduced it to the google closure compiler, the compilation went very well reducing the package down to 350 kb, 100kb less than yahoo ui, and 150kb less than shrinkwrap. I, of course, did it all in advanced mode like a man.
So far so good, then it was time to load it up! The results were mixed. The site did seem to work, but I did get quite a few pesky errors telling me that various things behind the dojo prefix could not be found. I wasn't able to work out exactly what was going on as I didn't have closure addon for firebug ready, but I didn't notice issues the actual operation of the site - though I posit if I looked hard enough I would have found them.
So I thought to myself it appears the closure compiler is renaming dojo name space in my compiled.js to make them inconsistent with dojo.js. It seemed like an ideal solution was to combine dojo.js.uncompressed.js with my blob.js.uncompressed.js using the closure compiler. This resulted in a 51kb reduction in the size of the dojo library so far so good! Bad idea dojo didn't much like this at all and refused to load! It just downloaded then just sat there in protest of google's world domination.
I have done some further research into this matter, from what I read dojo 1.4.0 does support closure in 'simple' mode, but this is rather pointless because as I read closure simple mode provides a similar amount of compression to yui.
Anyway, those are my thoughts, I have looked at closure a little, it looks like a very nice library. The css layout looks drastically simpler than dijit's, this is something I am very fond of, I've often found it easier to rewrite dijits than try and theme them correctly. It seems to be missing some elements of the dojo library I am rather fond of such as dijit._Widget, dijit. _container/contained and of course the famous dojo.declare(). I suppose I could rebuild these, but why should I?
Addition:
Oh it also appears to be lacking a good RPC, cometed framework, and publish/subscriber framework. Unless I am mistaken. Don't get me wrong I want to like closure, I'm not a dojo apologist by any stretch of the imagination, I just like these parts of dojo. The addition of require and provide does make this a serious contender from my perspective. The lack of a meaningful system of this nature drove me away from jquery.
I use Intellij Idea 7 for Java dev. My dev is 'limited' to all J2SE features plus light JSP, Servlets, and super light usage of JPA. No J2EE, no massive use of random frameworks, etc.
Is it worth upgrading to ver 8? "Worth it" to me means better "core functionality" in terms of speed (ESPECIALLY startup speed), memory utilization (seems like it starts having serious problems with four or more projects open), and auto bug-finding.
More frameworks supported and more languages supported (other than perhaps Haskell and C++), and more refactorings don't interest me at this time.
A while back, I installed a preview version of 8 and it seemed -exactly- the same as 7, as far as my needs were concerned.
Anyone loving the upgrade to 8, and if so, why?
Thanks
It also seems to be easier to configure a new project over top of a complex collection of existing code.
For example, something that you would naturally configure into 5 or more modules.
There is a really beautiful go to/create test wizard that is bound to ctrl-shift-T. Worth the upgrade by itself
The best way to tell is to check out the list of new features and decide for yourself. I haven't discovered any single feature so far that by itself is worth upgrading - the simplified UML view is quite nice, as is the improved Maven integration. The UI feels a bit more streamlined and faster. It seems like most of the attention has gone into non-Java features like better Flex support (which I am really thankful for as I don't like FlexBuilder but I haven't had a chance to use yet).
IntelliJ 8 has a configure plugins feature that allows you to disable plugins with dependencies. Nothing trial and error couldn't replicate, but it is nice.
Startup is only marginally slower. But indexing once opened is a lot faster than before, even unnoticeable for most projects, except after a commit to Subversion. It seems a commit to subversion triggers the indexing twice.
I am working on the Diana-EAP build - but 8 has git integration built in. The EAP has better git integration than the 8.0.1 release - it looks like that is something they are really focusing on.
Definitely not! Seems that the variables defined in our custom taglibs are no longer able to be used in the jsp (worked in 7.0.4). All red. No auto complete.
Oh, and the new settings menu is horrendous!
Some benefits of IntelliJ IDEA 8:
IDEA 8 supports Subversion 1.5 new functionality - e.g. merge tracking, which may be useful especially if your team (like ours) uses a lot of development branches and thus merging is frequent.
One detail I appreciated about IDEA 8: As you probably know, IDEA has had changelists for pretty long now, built on top of any underlying version control system - this is a really useful feature. So, now that Subversion itself supports changeslists, IDEA's changelist implementation has been changed so that it is perfectly compatible with Subversion's native changeslists. (For example, you'll be able to work with any changelists created in IDEA also when using svn command line tools directly.)
Edit: in your case, perhaps it is not worthwhile to upgrade. For me, at least, startup and file indexing seems to be somewhat slower in 8 than 7. [But for me personally the upgrade was definitely worth it, because it solved a long-standing VCS problem with IDEA 7 - it could hang "waiting for VCS sync to finish" for an hour or whatever after hitting Ctrl-K.]