Is there a way to prevent access to certain libraries in dart? The reason why is I want to allow a scripting language in my application. It looked like dart would make that easy, by just limiting what libraries one could import and defining my own libraries. Is this a viable option? For example, I would want to completely remove access to dart:html so that why the scripts can't mess with the DOM.
There was a discussion recently about this feature request https://code.google.com/p/dart/issues/detail?id=16373
This is for isolates spawned from Dart code.
I don't know about it when hosting Dart in your application.
See also this question Embedding Dart into application
Related
Hello Dart Community,
I am curious to know the practicality of using a javascript library (say a visualizing js like D3.js, etc) within your dart app?
I currently am building an app that tries to take data and do some analytics. To do this, I would like to visualize the data clearly.
I know there is js dart interop. https://www.dartlang.org/articles/js-dart-interop/
Does this have a good enough functionality to be used in communicating with a robust JS library? What is the catch?
Thanks!
This is used a lot. Just take a look on the questions here on SO dart-js-interop. It's not too comfortable currently but thre is work going on to make a better developer experience.
There are Dart packages that provide wrappers for d3.js. I have no idea how well they work though:
https://pub.dartlang.org/packages/charted
https://pub.dartlang.org/packages/d3d
https://pub.dartlang.org/packages/d3
At least the code can give you and idea how to use d3 from Dart.
I'm prefer using wrappers to use js libs to avoid use dart interop in all places in project.
The worse functionality using JS libs is when lib is a JS polymer component. You may be would to generate wrapper with custom_element_apigen.
For other js libraries you can write wrapper with your forces. You can use some wrapper generator too but I never have this experience.
I'm starting to study Dart. It seems a nice language and in some aspects a real improvement over JavaScript. Since it claims to come with "batteries included" and to be meant for "structured web apps", though, I fail to understand how to actually structure a web app with it. Almost all the tutorials concentrate on language features, but Dart is quite simple and with many familiar bits, so that's the easy part.
Recently I fell in love with AngularJs. Now routing, two way binding, nested scope, clean separation of concerns... This actually means "structured" to me. But all the Dart examples I find are about selecting HTML elements and attaching listeners to them. This is old-style jQuery-like web programming and quite frankly the opposite of what I think of when I read "structured".
I don't want to compare a language and a framework and I know that Angular Dart is out, but I fear I'm missing something of vanilla Dart, because if it's all about a shorter syntax for lambdas, class based OOP vs prototypical OOP and the like, I don't see how it's supposed to be a game changer: there are many other languages that provide an alternative JS syntax (à la CoffeeScript) and compile to it, and they don't come at the price of losing a perfect integration with existing JavaScript libraries and tools.
Sure, it has optional static typing, which may be great, but this comes more to a matter of preferences. I'm a full time Python and Ruby developer and I'm perfectly fine with dynamic languages. Is this what they mean by "structured"?
Thanks for any clarification that will eventually come.
I work on AngularDart and have some experience structuring web apps.
When building a web app in Dart you would pick a web app framework, for example AngularDart or polymer.dart. Web app frameworks have a lot of opinion which is something that doesn't fit in the core libraries. In that respect, "vanilla Dart" is fairly vanilla.
Since I'm most familiar with Angular, I'll discuss the Angular + Dart combination. However, the rest of this post is also true for polymer.dart.
Angular provides a lot of structure to your app. We've been able to provide a similar structure for both Dart and Javascript. The concept of directives, data binding and dependency injection exist in both.
Dart provides more structure and we've been able to use that structure while building AngularDart. e.g. the directive API is defined in terms of annotations which means that IDEs understand them and can help you code.
There are a number of "structure" features in Dart. One of my favourites is tooling. With types and annotations comes better tooling support.
Types in Dart are most useful when combined with tools. Auto-complete is great but for large web projects, static analyze is even better. For example, in AngularDart, since directives are annotated classes, we can assert that the annotation is correct. Even more interesting is the potential to build tools. In AngularDart, we have a tool that extracts and analyzes all directives. This type of tooling is possible in Javascript but easy and supported by the language in Dart.
libraries, packages
integrated dependency management with pub package manager
class based instead of prototype based
scopes of variables as one would expect in a modern language
static syntax check
better tooling support like code completion
May someone give us all an approach-outline for designing a plugin-architecture core in Dart.
How would it be possible in Dart to add, update and remove plugins in the running application core?
Some answers are already given in the discussion groups of Dart - https://groups.google.com/a/dartlang.org/forum/#!topic/misc/O3BA_9FXcp4.
I move the thread here, because stackoverflow is more appropriate for questions like this.
My initial thought is that each plug-in would run inside its own isolate, which would require a well-defined protocol that the plug-in would conform to in order to interact with the main application isolate. Ideally, the nitty-gritty details of the protocol would hidden behind a nice API that plug-in developers would use.
I'm currently starting to integrate "Delphi Web Script" in my application basically only as a scripting engine (interfacing with functions, classes, etc.); awesome software for the standard delphi open source quality in my opinion, but just for curiosity,
What's exactly the "web part" of the project?
How is intended to be used?
It was used somewhere with some success commercially?
Thanks!
As ain said, the original use was for PHP-like, ASP-like server-side web-page generation, but it was also capable of general purpose use, which is what I used it for. And as I did not use the "web" side of DWScript, most of the "web-oriented" features haven't been ported over (only the HTML Filter was ported actually).
The Web functionality is still available in the SourceForge repository, if someone wants to tackle the port. Though, they may be outdated beyond simple renamed methods and classes, as since DWSII, the script engine has gained various features. For instance, it is now capable of multiple thread-safe executions of a single compiled script, while the old codebase is built around the limitation that a compiled script can be executed by only one thread at a time.
On the other hand, there are some new features that could simplify the porting, the simple WebServer demo recently added uses RTTI to expose TWebResponse & TWebRequest f.i. (was manually exposed in DWSII). On the down side, that's only possible with recent Delphi versions.
AFAIK the main focus of the original author of this scripting engine was to make it possible to embed Pascal scripts into HTML pages, just like ie PHP does it. Hence the name "Delphi Web Script". While the focus of the current maintainer, Eric Grange, is on using it as a general purpose scripting engine, it should still be possible to use it for web purposes as well - for that you use the "filters" feature of the library. Check out the dwsHtmlFilter unit for HTML filter.
Besides the obvious differences between JavaScript and Java, what are the relevant differences in using either SmartClient or SmartGWT?
SmartGWT is the GWT wrapper for SmartClient, which, as you say, means that you're able to write your SmartGWT app using java.
From my experience the only difference that matters when you're programming is that the GWT wrapper is a bit more restrictive than using the js components directly. For example, programmatically scrolling a TreeGrid from java is hell, since the body of the underlying table (that you need to get at in order to scroll the blasted thing) is not exposed through SmartGWT, while it of course is easily reachable from js.
Overall I wouldn't base the choice between the js components and the gwt wrapper soley on these differences, but I would look at other factors in your project. Which techniques are you most comfortable with? How much custimization are you planning on doing?
In my case, code maintainability.
We are a Python house. But for client-side code we opt for GWT, initially with GXT, but now with SmartGWT.
We don't like Java, but we don't like JS much more, Order, maintain libraries for several widgets, extends objects to give custom functionality, etc. between doing this in JS or Java, the option was obvious, Java side. We write reusable components here, and now we write very minimal code for client side, only reuse components and use REST to comunicate with ours Python backends.
We know that SmartGWT is more verbose than SmartClient, but, with Netbeans autocompletion (some coleagues here use Eclipse) we have direct access to every method, documented, instead to go to the showcase or google every time that we need to test and try new functionality.
SmartGWT provides you the advantage that you may use powerful editors.
You can debug your own code easily (however it's not very helpful for diving into the smartclient code itself).
You have all the auto completion stuff of eclipse/netbeans at hand. When starting to work with SmartClient/Gwt it helps you find the things you are looking for because the editor can list you classes or the available methods and some basic documentation what the class/method actually does. Saves you a lot of time crawling through the docs
Banang : API's to access ListGrid / TreeGrid body are now exposed in Smart GWT.
We chose to use Javascript (no SmartGWT) ... I prefer it that way, although some of our team members (newer to Javascript) would have preferred the SmartGWT way. Both have their pros and cons :
One of the advantages of using SmartGWT, is that you get to have compile time errors since everything gets compiled first by the Java compiler, before it gets rendered to Javascript.
One of the drawbacks of SmartGWT, is that it doesn't expose the full underlying Javascript Smartclient API. This means, if you want to do more advanced stuff, you might end up needing to do it in Javascript anyways.
Another drawback of SmartGWT, productivity wise, is that every single change you do and want to test, needs to go thru the painful Java EE compile/deploy process, whereas if you do it in Javascript, you can alter client side code faster by changing .js files directly without the need for the whole compile/deploy process.
SmartGWT is based on java code and when compiled it transforms it into java script, is a
heavy since it transforms java code into js
SmartClient is a framework based on js, you can use its components in an xml page and you manipulate them in Js, and it’s light
le showcase de smartclient
I recommend smartClient