I'm looking for a maven plugin that would generate ActionScript3 classes from Java classes in order to access them by object remoting.
I've seen FlexMojo but it uses the GraniteDS generator which create some problems when it comes to map Enum objects (which can be fix through a workaround that is describe here : http://dev.c-ware.de/confluence/display/PUBLIC/Flexmojos+generated+AS3+model+with+Enum+support+using+BlazeDS?focusedCommentId=7634946&#comment-7634946 if you've googled your way here this might be useful) when working with BlazeDS.
Everything that I found so far are people who explain how to generate VO classes on flex side using Flash Builder 4, but this solution can not be used in an industrial development environment.
Take a look also on http://flex-annotations.aixcept.net/examples/actionscript.html
I also found this one, and while it is not a maven plug-in it could possibly be turned into one:
https://sourceforge.net/projects/cleartoolkit/
It was created by the guys who authored the book "Enterprise Development with Flex". Look for the utility DTO2Fx.
Related
There are plenty of good addons, developed for vaadin 7 and vaadin 8 non compatible with flow. Searching for solution i found - vaadin docs on MPR (multiplatform runtime) - where LegacyWrapper class is available which provides integration for legacy components into flow engine. The MPR is available for Prime (paid) subscription users only, so does the LegacyWrapper class as well.
Could anybody please give any hints how to make a simple wrapper implementation for using legacy components into flow layouts. I believe, supposed CustomLegacyWrapper class should inherit from vaadin.flow.component and contain (as a composition, maybe?) vaadin.ui.AbstractComponent. How the baseline solution might look like?
Thanks in advance.
I've got an answer to my question on the vaadin forum from one of the contributors that there is no simple workaround for my purpose, integration of old components into flow engine is one of multiplatform features and its not possible to implement it in easy way.
I am doing an assignment (implementing an algorithm), and I wanted to try, this time, implementing tests first. However, I simply do not know where to put them! Do I need to create a new project?
All the tutorials I have found mentioned what to write, but not the general method of proceeding when building a test suite.
I expected Monodevelop to have some kind of predefined structure (like a big "add test suite" button), but I could not find anything for FSharp.
Monodevelop seems to have many tools to deal with tests in a clean and principled way (it does have a big "run tests" button), therefore I thought I would structure my project so that Monodevelop "sees" my tests, so that I could use the tools from the graphical interface. It seems the most common way to write tests is to use NUnit, what if I use something else, like FsCheck?
I have stumbled upon a Github project called FSharpKoans, it seems to suggest that I should create a project called "MySolution.Test" inside a solution, is this the standard way?
What should be the type of the project then, is it a separate console application?
Thanks.
Yes, creating a separate "X.Test" project is the standard way of adding tests in .NET, F# is no exception here.
For testing framework, pick one that Monodevelop supports well if what you're looking for is IDE integration - NUnit sounds like a safe choice. You could conceivably use any framework in F# tests, so I would think what Monodevelop supports should dictate your choice here.
FsCheck is not a testing framework, it's a library for property-based testing that can be used in conjunction with any testing framework. You might want to look into it as it advocates a particularly interesting approach to testing, but it's by no means the only way or the required way of doing testing in F#.
Is it possible to use js generated from Kotlin sources in JVM to manipulate java objects and its own js objects?
Kinda create dynamic environment for development in distributed environment.
So new versions of classes can be dynamically loaded/modified on running remote servers while development. And then after it's done release versions to be compiled statically for max performance.
How hard would it be to implement?
The current implementation of Kotlin does not have any support for invoking Java methods from JS-generated code. This could in theory be accomplished using Nashorn, but we (the Kotlin team) do not currently have any plans to work on that. If you're interested, you're welcome to contribute, but this would be a fairly long and difficult project.
My scenario: trying to port a small part of an application created by our company from native code (ObjC for iOS / Java for Android) to C-Sharp. The project will interact with our webservices. Goal of this project is figuring out how feasible it is to port our whole app to Mono.
To create URLs, I'd like to use String.Format(). I thought it'd be a wise idea to put this 'service layer' inside a Portable Class Library (PCL) since I don't expect this code to change across platforms. Sadly, it seems the String library is not available for PCLs.
So my question is the following:
I think the main advantage of PCLs over "normal" libraries is that they shouldn't need a recompile for different platforms. Is this assumption correct?
This experience makes me think that for the moment PCLs are rather limited. Should I try to stick with PCLs and work around these kinds of issues, or might it be better to stick with a "normal" library for now? --- I'll assume the "normal" library has more functionality exposed.
You can use PCLs currently across many platforms, but it does require some small hacks to your setup.
These hacks are listed in http://slodge.blogspot.co.uk/2012/12/cross-platform-winrt-monodroid.html
Once you've got those working then the functionality available is quite broad - and it definitely includes things like String.Format
For the situations where the PCL profile is not broad enough, then you can use several techniques for extending them - see http://blogs.msdn.com/b/dsplaisted/archive/2012/08/27/how-to-make-portable-class-libraries-work-for-you.aspx . The technique I generally use is to use MvvmCross Plugins - which are basically PCL interfaces with platform specific implementations. But these plugins are generally at the level of 'make bluetooth work' rather than at the level of String.Format
I do lots of PCL work across WinRT, WP, WPF, MonoTouch and Mono for Android - see http://slodge.blogspot.co.uk/p/mvvmcross-quicklist.html for lots of links to PCL work.
It's true that Xamarin have recommended not using PCLs for a couple of years, but that situation has now changed and the official support for PCLs is under way - see http://slodge.blogspot.co.uk/2013/02/the-future-is-portable.html
From a development perspective - especially from the point of view of using refactoring and testing tools - I don't hesitate to recommend you use PCLs now... especially for operations at the String.Format level. However, each project is unique... so it's not always the right answer.
One important note: right now it's better to not reuse the PCL binary files across to the MonoTouch platform - for now, build your portable libraries against the specific MonoTouch library platform. See http://slodge.blogspot.co.uk/2013/01/almost-portable-binaries.html?m=1
Perhaps you want to look at the efforts other who have got PCLs working to a considerable degree with monotouch and monodroid.
For example see http://www.slideshare.net/cirrious/mvvm-cross-going-portable . You'll also find instructions on how to setup PCL support for MVVMCross here http://slodge.blogspot.co.uk/2012/09/mvvmcross-vnext-portable-class.html .
Xamarin has recently committed to providing far greater PCL support rather than some of the workarounds that people have been having to make, but it is worth the effort.
I have a library that I created which I would like to use the included classes across a few different projects while maintaining the library code independently. I would also like to be able to easily share it with other developers and have them easily implement it. At this point it doesn't need to be a static library.
What is the best method to do this? I have seen other devs put their classes in a brand new XCode project then import that, but what is best practice?
I think the best practice is to create a project with a static library target. Other developers can include it as a subproject in their projects.
Second best would be to simply make a directory of source files that can be included in a project on an as-needed basis. This is useful for general purpose utility code where a particular project may not want all of it.
In both cases, the library code should belong to its own git repository and included in a project as a git submodule.
If it will ever become a static library, it's best to make it one now, rather than waiting until it is "ready"; by the time you decide to switch it over, a few projects will already be using it, and converting each of them to use it will be a pain. Just do it the right way from the beginning.
If you want to distribute the library without source, you will want to use lipo to build a universal library that contains both ARM and x86 code. Unfortunately, Xcode doesn't make this as easy as it could be, but it's not too difficult with some light shell scripting.
As far as I know you should create a new project and that project to any other project you want use library in. Then link the projects and you can access it. The other way which I have done also, copy the library classes directly to the new project and access the library through importing the needed classes. In my case i found creating a project and linking it with the new project is the easiest. although copying the classes isnwhat we all do when using external libraries such as cocos2d. As far as sharing it with others, just upload it to github another place of your choice so it can be used by other dev's. I hope this helps you.t
I don't know how mature the code is, but since you specifically mention wanting to share it with other developers, you may want to investigate CocoaPods.