The Module Designer is already saving a separate *.java file along with the *.vmod file - which is great, so I can edit the file in another IDE and check in the file to version control.
Haven't found an option how to import a *.java file again into Module Designer though. At least importing the "free text parts" would help a lot. Optimally it would reconstruct the entire *.vmod file (as long as the generated parts stay exactly in the syntax that the generator created/would create).
Import java file in Module Designer
Re: Import java file in Module Designer
Yes, thats something I've been missing as well...
It seems there is a reason to disallow any modifications to the constructor, however preventing developers from importing the files back is not the only way to do so. This could be also done by parsing the external java file and validating it's syntaxt tree against some rules. Accessing AST is possible I believe since java 1.6. This may also allow to warn about many other legal in java patterns but disallowed in th emodule designer - like passing UI controls to other classes via properties, constructors etc...
It seems there is a reason to disallow any modifications to the constructor, however preventing developers from importing the files back is not the only way to do so. This could be also done by parsing the external java file and validating it's syntaxt tree against some rules. Accessing AST is possible I believe since java 1.6. This may also allow to warn about many other legal in java patterns but disallowed in th emodule designer - like passing UI controls to other classes via properties, constructors etc...
Re: Import java file in Module Designer
Totally agree, it seems to be no way make edits from an external IDE stick in Voltage Module Designer. This is a shame since the internal IDE lacks quite a few features normally found in virtually any Java IDE today (refactoring, search-and-replace (sic!)...). But the drag-and-drop support of visual components is very helpful, of course.
I've just started developing with VMD, but I suppose one way to go about it is to let the default java class be responsible for the GUI parts and have additional java files take care of actual calculations and processing. They can be created in your favourite IDE, employ standard Java syntax, tested using standard frameworks and added to the project under the Additional Java Files. One caveat is that when you make changes to the file in the external editor you need to delete it and reimport it in the Additional Java Files dialog... You would expect VMD to reimport them at compile time, but it doesn't.
Well, I suppose its is early in VMD's lifetime, and I hope improvements might be on the way.
I've just started developing with VMD, but I suppose one way to go about it is to let the default java class be responsible for the GUI parts and have additional java files take care of actual calculations and processing. They can be created in your favourite IDE, employ standard Java syntax, tested using standard frameworks and added to the project under the Additional Java Files. One caveat is that when you make changes to the file in the external editor you need to delete it and reimport it in the Additional Java Files dialog... You would expect VMD to reimport them at compile time, but it doesn't.
Well, I suppose its is early in VMD's lifetime, and I hope improvements might be on the way.
Re: Import java file in Module Designer
My guess is the reason for not letting people inject their code directly could be:
1. Making it easy to work with for people new to java and the dev at all - a full size IDE may be a bit intimidating for a fresh user.
2. Protecting the modules from any dangerous or troublesome code, like enforcing only one constructor with predefined body...
3. Keeping all resources in one file - again this is for the people new to java or coding at all
4. Preventing debugging tools from touching the internals of the application
There is also the benefit of the visual designer which is easier to be used for pople who are not used to code their user interfaces.
Apart from points 2 and 4 I don't see any reason why one shouldn't be allowed to use an external IDE for the whole module dev process.
Point 2. can be enforced by some code analysis build-time or reflection run-time. Code analysis requires more work but may catch any illegal code i.e. in the constructor's body.
Point 4. may be a bit diffcult but there are ahead of time compilators for java available which produce native binaries, those are harder to reverse engineer - note java classes can be investigated as soon as they are loaded into the memory, its not straight forward but also not impossible.
VM looks like a product which if well planned could be executed by a single skilled developer, there are probably more people working on the supporting infrastructure than the VM itself
Certain features may require extra people with apropriate skillset or at least some time for the current team to learn about the requred technologies... This is not something a company runing such small project can take lightly...
The point 4 could be also resolved by providing acces to extra tools ona a basis of an appropriate NDA, however maintaining a legal team which deals with any breaches may turn to be too much comparing to the benefits. Not to mention a breach may have inrevesable consequences for such project...
Anyway, after all that serius stuff being said, a way of seamless integration with a java build system would be a great addition to the feature set of the VMD
1. Making it easy to work with for people new to java and the dev at all - a full size IDE may be a bit intimidating for a fresh user.
2. Protecting the modules from any dangerous or troublesome code, like enforcing only one constructor with predefined body...
3. Keeping all resources in one file - again this is for the people new to java or coding at all
4. Preventing debugging tools from touching the internals of the application
There is also the benefit of the visual designer which is easier to be used for pople who are not used to code their user interfaces.
Apart from points 2 and 4 I don't see any reason why one shouldn't be allowed to use an external IDE for the whole module dev process.
Point 2. can be enforced by some code analysis build-time or reflection run-time. Code analysis requires more work but may catch any illegal code i.e. in the constructor's body.
Point 4. may be a bit diffcult but there are ahead of time compilators for java available which produce native binaries, those are harder to reverse engineer - note java classes can be investigated as soon as they are loaded into the memory, its not straight forward but also not impossible.
VM looks like a product which if well planned could be executed by a single skilled developer, there are probably more people working on the supporting infrastructure than the VM itself
Certain features may require extra people with apropriate skillset or at least some time for the current team to learn about the requred technologies... This is not something a company runing such small project can take lightly...
The point 4 could be also resolved by providing acces to extra tools ona a basis of an appropriate NDA, however maintaining a legal team which deals with any breaches may turn to be too much comparing to the benefits. Not to mention a breach may have inrevesable consequences for such project...
Anyway, after all that serius stuff being said, a way of seamless integration with a java build system would be a great addition to the feature set of the VMD
Re: Import java file in Module Designer
I am starting right now looking around the Module Designer, and while i agree that an integrated simple IDE is a good choice for new programmers, for building anything serious you need at least a *file* based environment, where each file is save in its own.
Otherwise it is impossible to use anything "modern" to develop software, including source code control systems (snv, git), thirds party editors (from emacs to notepad), external IDEs, build systems.
Without all this, no real team developement, no large scale modules. But it make no sense to invest a lot in developping a dedicated IDE for CA, when a lot of goodies already exists.
If i was in the technical team, i would suggest to leave the choice to the developpers: beginners/intermediate will use the current constrained builder, the others an industry standard environment. And the constructor discussion is not a big deal: expert developers will deal with it without problems, and if you really want a system solution, generate two classes, a main class that is not intended to be modified, and a subclass containing user code. But i would not consider this worthly.
Maurizio
Otherwise it is impossible to use anything "modern" to develop software, including source code control systems (snv, git), thirds party editors (from emacs to notepad), external IDEs, build systems.
Without all this, no real team developement, no large scale modules. But it make no sense to invest a lot in developping a dedicated IDE for CA, when a lot of goodies already exists.
If i was in the technical team, i would suggest to leave the choice to the developpers: beginners/intermediate will use the current constrained builder, the others an industry standard environment. And the constructor discussion is not a big deal: expert developers will deal with it without problems, and if you really want a system solution, generate two classes, a main class that is not intended to be modified, and a subclass containing user code. But i would not consider this worthly.
Maurizio
Re: Import java file in Module Designer
Pretty much everything can be done in an external IDE, the only bits you have to do in VMD is the logic which delegates the functioality to the extrenal project.
But I'm still missing the ability to launch the VMD debugger via a CLI... I know this may be just me being picky but sicne most of my stuff is written on the train to work any unnecessary mose click turnns into a serious pain... A CLI woudl let me test the modules i.e. via gradle directly from the IDE.
But I'm still missing the ability to launch the VMD debugger via a CLI... I know this may be just me being picky but sicne most of my stuff is written on the train to work any unnecessary mose click turnns into a serious pain... A CLI woudl let me test the modules i.e. via gradle directly from the IDE.