Home » Archived » EGL Development Tools » Set compiler options in EGL New Package wizard(Anyone considered this?)
| Set compiler options in EGL New Package wizard [message #895409] |
Thu, 12 July 2012 18:29  |
 Dan Darnell
Messages: 145
Registered: November 2011
Location: Arkansas |
Senior Member |
|
|
Some of you know that one of my (very few) pet peeves about EGL is the way in which generation targets are indicated. I would rather be able to indicate with an annotation in the source code that Java, JavaScript, LanguageX generation is called for than to do this via Properties settings. I believe that generation target settings are the #1 thing that trips up developers (not just new ones either -- I still get bitten).
One way or another, this needs to be addressed. When EGL was used by people who targeted ONE environment (COBOL and then, later, Java) it wasn't a big deal to have the generation target set behind the scenes. Heck, I'm sure most people set it at the global level and never thought about it again. Now that we are routinely in a two-language generation environment (Java and JavaScript) it doesn't work any more to have these crucial settings acting invisibly behind the scenes. Imagine where we are going to be when we have single EGL projects that target three or more languages...we'll constantly be clicking around to figure out how a given source part is going to compile.
It's Enterprise Generation Language but the "generation" settings are the one thing that the EDT (and RBD) tools manage very poorly.
I am wondering if the team thinks it would be possible to add the EGL Compiler options to the New EGL XXXXXXXX wizards? A great start would be the addition of compiler options to the New EGL Package wizard. (These options are already available at the Project level.) From there, heck yeah, add the compiler options to the other New EGL XXXXXX wizards where applicable.
While the issue is being addressed, why not list the selected generators in the Eclipse Properties view (the tab that show properties in a read-only mode) so that we can easily see as we click on resources (without a right-click->Properties on each resource) the generation targets?
From there, how about something in the editor itself? If that isn't possible, at least list the generation targets in the Eclipse Outline view. Heck, just create a new "EGL Generation" view that appears by default in the EGL perspective along with the Outline and EGL Data views. Even if this view just lists the Generation targets in a read-only mode we'll be ahead of the game. Imagine a world where it is obvious to the developer how a source part is going to compile, at a glance, without any digging into Properties dialogs -- that's where we need to be!
--Dan
[Updated on: Thu, 12 July 2012 18:29] Report message to a moderator |
|
|
| Re: Set compiler options in EGL New Package wizard [message #895429 is a reply to message #895409] |
Thu, 12 July 2012 21:08  |
Richard Moulton
Messages: 92
Registered: August 2011
Location: Devon, UK |
Member |
|
|
Hi Dan,
I must confess I'm still stuck in the early stages with EGL/EDT and so I've yet to complete and deploy an EGL application to a live environment. As such I don't have the experience you've had; needing to deploy to multiple tiers and using many different languages.
Whilst using EDT I have come to realise that the (default) client, common and server packages dictate whether the generator will generate and compile just javascript (client), javascript and java (common) or just java (server) code.
Now that I understand that fact (yes, it took me a while to realise the underlying significance of these default package names) I kinda like that and in the simple two language environment I'm currently comfortable with I think that will work for me.
It's difficult for me to see past the two language environment and visualise the difficulties a third or fourth language might present, but the fact that it took me a while (although I'm getting on a bit now) for it to dawn on me that the package names were dictating the compiler options, does support your argument. It just wasn't obvious to me how EDT was deciding what to generate and compile, I only stumbled on the fact when looking at a forum question Nathan had posed.
I like your idea of the compiler information being available in the outline view, with some indication where the setting is picked up from (the part, package, project) but I'm not sure that I'd want to embed this in the code itself. However, like I said, I've not been out there implementing EGL applications so (at the moment) I'm not hitting the same challenges that you are.
Well, that's my two-penneth worth.
Richard
|
|
| |
| Re: Set compiler options in EGL New Package wizard [message #895436 is a reply to message #895429] |
Thu, 12 July 2012 21:42 |
Dan Darnell
Messages: 145
Registered: November 2011
Location: Arkansas |
Senior Member |
|
|
Hi Richard.
I think it is people like you (who are picking up EGL/EDT for the first time) that have the most to offer with regard to what struggles are found there and what can be done better. So...great feedback!
This comment of yours struck me as interesting: "...the fact that it took me a while for it to dawn on me that the package names were dictating the compiler options, does support your argument."
That the client, server, and common packages support particular generation targets is a function of the new project wizard setting those options at a package level. I just wanted to clarify that the package names are not actually playing a role. In other words, the "server" package COULD generate client code if you were to change the package setting or you created that package yourself and forgot to go in and adjust the generation target settings.
In a very small and simple project I'm working with right now in RBD I have the following packages:
com.xxxxxx.viewer.data
com.xxxxxx.viewer.ui
com.xxxxxx.viewer.ui.common
com.xxxxxx.viewer.ui.widgets
com.xxxxxx.viewer.services
com.xxxxxx.viewer.util
...and this project references others with their own package structures.
I think the EDT team was genuinely trying to help things with the client, server, and common package structure generated by the wizard but they really just kicked the can down the road a short distance because, before long, a developer does of necessity end up with more complex package structures and that is when the generation target hassle hits and package and source part naming does not necessarily indicate much about a target environment.
Anyway, again, great feedback! Keep it coming...
--Dan
[Updated on: Thu, 12 July 2012 21:49] Report message to a moderator |
|
| |
| Re: Set compiler options in EGL New Package wizard [message #895440 is a reply to message #895436] |
Thu, 12 July 2012 22:17 |
Richard Moulton
Messages: 92
Registered: August 2011
Location: Devon, UK |
Member |
|
|
Dan Darnell wrote on Thu, 12 July 2012 22:42That the client, server, and common packages support particular generation targets is a function of the new project wizard setting those options at a package level. I just wanted to clarify that the package names are not actually playing a role. In other words, the "server" package COULD generate client code if you were to change the package setting or you created that package yourself and forgot to go in and adjust the generation target settings.
Absolutely. The default package names that are generated aren't playing a role. You could change the 'server' package to generate java, javascript or any other compiler you might have.
Also, when you create a new package, such as 'client.widget' then this will adopt the compiler settings from the 'client' package.
You're right, when creating a new package you need to think about the compiler settings you want as there's no prompt or reminder.
As it stands you could use the base package as the determining factor for the compiler settings, so 'com.xxx.client' will generate javascript, 'com.xxx.server' will generate java, etc. and then all sub-packages would generate according to their parent package.
Richard
|
|
| |
Goto Forum:
Current Time: Fri Apr 19 16:29:33 GMT 2024
Powered by FUDForum. Page generated in 0.02251 seconds |
] 
Search
Help
Register
Login
Home
