Wow, this is totally confusing and the dojo 1.8 documentation seems a complete clusterf**k around build layers. Anybody have a clue what's going on there?
In the build script example profiles, the example amd.profile.js has profile.layers["dojo/dojo"] and the tutorial follows this same syntax.
Besides the tutorial, in the 1.8 build documentation there is no mention of this kind of structure, but of profile.dependencies.layers[n].
The documentation also references non-AMD syntax and, just to add another "layer" of confusion, there's also a profile.dependencies.layers[n].dependencies.
Which should I be using? Is this actually documented anywhere with any consistency or clarity?
I have learned that the Dojo 1.8 Reference Guide contains obsolete information regarding build profiles, but that the Dojo 1.8 Build tutorial is current:
http://dojotoolkit.org/documentation/tutorials/1.8/build/
That tutorial recommends this blog post for more information about layers and build optimization: http://www.sitepen.com/blog/2012/06/11/dgrid-and-dojo-nano-build/
Related
I came across docToolChain (http://doctoolchain.org/) for generating Docs. Wanted to know if this can support other programming languages such as Python, Go etc? Or will it only support Java?
yes, it does - depending on your needs :-)
When we incremented the version of docToolchain from 1.x to 2.0, the biggest feature was that the technology is now hidden behind a wrapper.
You still need java installed (v8-v14), but you don't have any code any more in your repository.
But regarding Python - it is quite likely that you want to use restructuredText as your markup language.
Until now, docToolchain focussed on AsciiDoc (based on ruby) as the markup language for your projects documentation.
There is now a feature coming up: jBake, the static site generator used by docToolchain is already able to render markdown.
But there is now also a PoC which shows that it can also render restructuredText with a little help of a small python script:
http://doctoolchain.org/multi-markup-demo/demo/asciidoc.html
PS: I am the maintainer of docToolchain, so my answer might be biased
I've stumbled upon CGAL and it seems amazing.
Anyone know of any simple ways I can test some of it's magic out without knowing any prior C++ or programming? Or a really thorough guide?
Just to get you an understanding of my general tech level(unrelated to CGAL) I know printf.. prints.. stuff.. but I have no idea how to put that into practice. And I've managed to install npm modules by slamming commands into cmd and run a module afterwards.
If there's no easy beginning to get a taste of this, other tips is also welcome if I have to take a longer route to understanding this.
What I want to achive is my input is pointcloud data scans -> magic/CGAL/ -> 3D models is my output
You can try the 3D polyhedron demo that contains most of the functionalities of CGAL.
You can compile it yourself by compiling the code in demo/Polyhedron from a release or use the pre-compiled windows demo available: demo + dlls to be extracted in the directory of the demo.
Also here is a WIP version of a tutorial that should be integrated in the official documentation soon.
I'm a starter to learn Codeception and I found that officical guide didn't tell me anything about the step object.
The change log of version 2.1 says
all support classes moved to tests/_support by default. Actors, Helpers, PageObjects, StepObjects, GroupObjects to follow PSR-4 naming style
So anybody can tell me how to use step object in the latest version? Or give me a simple example about that? Thanks a lot.
Here should be what you are looking for:
http://codeception.com/docs/06-ReusingTestCode#StepObjects
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
Does Objective C have a documentation framework similar to JavaDoc where documentation can be generated from the source code?
Doxygen! You can use it for many languages, including Objective-c
Good news for all! :D Finally after waiting a long time Apple has introduced a parser comments for our projects. According to the new features in XCode 5:
Project documentation from framework API reference documentation and
structured comments in your own source code are displayed in the quick
help panel and in code completion popover views. Doxygen and HeaderDoc
structured comments are supported formats.
and from the Clang 3.2 release notes:
Clang parses the comments and can detect syntactic and semantic errors
in comments. These warnings are off by default. Pass -Wdocumentation
flag to enable warnings about documentation comments.
If you want to see an example of this new feature I recommend you take a look at the following article: Documentation in Xcode 5
Doxygen is quite popular among Obj-C developers.
You could have a look to HeaderDoc wich is the apple documentation framework similar to Java.
Appledoc has become very popular. . . version 1 was based on Doxygen, whereas version 2 was written from the ground up.
It doesn't quite have all the features of Doxygen (charts, enums, C++ classes, etc), but what it does offer is beautifully formatted docs in HTML of IDE integrated format.
Also interesting to note is the following:
The CocoaPods tool includes Appledoc documentation for the libraries that it installs. Quite handy.