Feature requests
Hi all,
I have some feature requests, and I was wondering if you could consider them.
Give grails keywords different colors (belongsTo, constraints, etc, to see difference between contraints and constraints)
Make sure only one jetty can be run at the same time, or give a warning when starting another. When pressing the 'run' button in the run configuration multiple times, multiple Jetty's are started, but since every one runs on the same port, you'll get a 'port already in use' exception.
Erik
请先登录再写评论。
hey, i strongly second the 2nd point! i think i've double started Jetty during development for more 100 times!
btw, I'd like to see another feature. it's quite contradictorily and some ppl may not like it. Groovy has a DefaultGroovyMethods that add many methods on any object. As there are too many DGM, it's a bit hard for me to find my own methods. Could the non-DGM be shown on the top? or maybe display the DGM only after pressing on a particular key.
regards,
mingfai
Hello.
As for checking for one Jetty server already running, I think, we cold implement it. But completion feature you describe depends on core IDEA API, and, I'm afraid, it will not be implemented until Idea 8.0.1 because of approaching IDEA 8 release.
With best regards,
Ilya
thank you. re. schedule, it's understandable.
re. core IDEA API, for "normal" JEE app, there are logic that
1) check the server port for the first time a configuration is to be run
2) check if a configuration is already running, prompt for "Configuration Already Run: Run configuration 'tomcat' has been already run. Do you want to redeploy it?".
for Grails application, it's not treated as a server application and those logic are not implemented. for point 1, you could detect the port by the "server.port" system property
(refer section 2.6 http://grails.org/doc/1.0.x/guide/2.%20Getting%20Started.html#2.6 Running an Application ) for point 2, i am not too sure if a Jetty could be gracefully shutdown easily. perhaps you have to kill the process if the user answer "yes" in the prompt.
http://docs.codehaus.org/display/JETTY/Howtogracefully+shutdown.
Edited by: Ming Fai on Nov 1, 2008 8:35 AM
The feature(s) that I would most like to see are anything that could help me recognize typos among the significant noise of undefined dynamic properties that are underlined throughout my code. Specific changes that would help a lot would be:
Recognize which classes are major Grails artefacts (e.g. domain classes, controllers, services) and allow dynamic properties to be associated with these artefacts rather than specific Groovy or Java classes. I can, for instance, tell IDEA that a specific domain class has a dynamic 'log' property, but I have to repeat this for every domain class, controller, service, etc. I'd like to be able to say that every domain class has this property.
Have IDEA recognize the type of injected services. Grails convention requires that services be declared simply as 'def', and IDEA does not recognize the type of any service, and can't highlight errors in calls to service methods. If JetGroovy could infer the type of services it would be a tremendous benefit.
pt 2 will help a lot in boosting our productivity. Now, I sometimes use static type because IDEA can't recognize the type of service. whoever like to see that feature, please vote at: http://www.jetbrains.net/jira/browse/GRVY-1784
besides, i'd like to see the IDEA UML feature support Groovy class. I don't know any UML tool that support visualizing Groovy.
Regarding the UML overview: isn't the dependency viewer enough? Or do you want to have a combination of Java and Groovy?
oh.. i mistakenly think the UML diagram doesn't work for Groovy. please disregard.
indeed, i wish JetBrains could build a tool as powerful as MagicDraw and bundle it in IDEA :)