Thread: [jdee-devel] jdee project file
Brought to you by:
paullandes
Menu
▾
▴
jdee-devel
|
From: Thomas F. <tfi...@fc...> - 2008-11-23 11:08:56
|
Hi I quick question, how does the jdee project file contribute to the functionality in jdee? For example, I tried using the class wizard, but it asked some questions or required me to do some stept manually, which could be automated. Specifically, I remember it asked: - what package the class should belonged to - then required me to save the class manually My thinking is that the project file already has the source root directory, so the function should ask for the class name, with an optional package name prefix. And should then intelligently figure out where the class should be stored in the source directories, based on the source root directory specified in the project file. So the question is how does the project file contribute to how the jdee functionality works? regards thomas |
|
From: Phillip L. <phi...@ne...> - 2008-11-24 18:34:27
|
Thomas Finneid <tfi...@fc...> writes: > I quick question, how does the jdee project file contribute to the > functionality in jdee? It allows you to configure different projects in different ways. > > For example, I tried using the class wizard, but it asked some questions > or required me to do some stept manually, which could be automated. > Specifically, I remember it asked: > > - what package the class should belonged to > - then required me to save the class manually > > My thinking is that the project file already has the source root > directory, so the function should ask for the class name, with an > optional package name prefix. And should then intelligently figure out > where the class should be stored in the source directories, based on the > source root directory specified in the project file. Hmmm. Well, it does this for me, using jde-package.el which is part of JDEE. As I said earlier, it works backwards from the way you are asking. You put a java file in the correct directory and it adds the package statement for you. Perhaps this is not the default. > So the question is how does the project file contribute to how the jdee > functionality works? I think that part of the problem here is that the options are too hard to configure. It would be nice if JDEE lead you through the process of creating one; something like a "new project" wizard. Phil |
|
From: Paul L. <la...@ma...> - 2008-11-25 06:18:33
|
Thomas Finneid writes: > I quick question, how does the jdee project file contribute to the > functionality in jdee? I think others have answered this well, but basically it sets up variables like source and library [class] paths. > For example, I tried using the class wizard, but it asked some > questions or required me to do some stept manually, which could be > automated. Specifically, I remember it asked: > > - what package the class should belonged to You haven't configured environment correctly. It should only confirm the correct package. > - then required me to save the class manually Buffer saves are never assumed in Emacs--it's a design paradigm/philosophy. > My thinking is that the project file already has the source root > directory, so the function should ask for the class name, with an The class name comes from the buffer file name minus the file name extension. > optional package name prefix. And should then intelligently figure > out where the class should be stored in the source directories, > based on the source root directory specified in the project file. Using C-x C-f to open (create after save) a new file and tacking on ".java" seems as economical, particularly the way it fits in with the typical way other packages create new source files. You could keyboard macro out something that does most of this and save it off somewhere. You could also write a two or three line function to give you your special behavior and call it a configuration. > So the question is how does the project file contribute to how the jdee > functionality works? Read the documentation. -- Paul Landes la...@ma... |
|
From: Thomas F. <tfi...@fc...> - 2008-11-25 08:57:32
|
Paul Landes wrote:
>
> I think others have answered this well, but basically it sets up
> variables like source and library [class] paths.
Thats what I have assumed as well, but it did not seem to work...
> You haven't configured environment correctly. It should only confirm
> the correct package.
... so I will start from the beginning with the configuration, again,
and se if I get it right this time.
> > - then required me to save the class manually
>
> Buffer saves are never assumed in Emacs--it's a design
> paradigm/philosophy.
Why is that?
In java one always have to specify package and class anyway, so as long
as that is confirmed it should be ok to let emacs automatically store it.
> > My thinking is that the project file already has the source root
> > directory, so the function should ask for the class name, with an
>
> The class name comes from the buffer file name minus the file name
> extension.
hmm, interresting.
The way I see it is that as a java programmer using an IDE, I should not
have to think of the IDE's own orinternal way of doing things, to get my
task done. Rather, the IDE should adapt to how the programming platform
is designed.
So in java things are oriented around classes, packages, configuration
files etc. For example, when I need a parameter class, the only
questions I should need to answer to create and save the class is
[packagename.]classname
the IDE should do the rest, such as finding the correct directory,
saving it etc.
> Using C-x C-f to open (create after save) a new file and tacking on
> ".java" seems as economical, particularly the way it fits in with the
> typical way other packages create new source files.
Not really, because thats only one part of the complete functionality I
am looking for.
I would like to have something like
insert-class-at-point().
where the following scenario represents the entire functionality I am
looking for
- (user wants to add a non exitent parameter class at point
in source code: class: RequestArgument
public void processArguments( [cursor]
- user: M-x insert-class-at-point
- func: ask for [packagename.]classname:
[com.stuff.]services.RequestArguments
- func: create buffer
- func: insert class template with package names, class name etc
- func: locate correct directory for class
(based on info from project file and user input)
- func: save buffer
- user: edit new class code
- user: save
- func: switch to original source buffer and insert class name at point
- func: add correct import statement in original source file
- user: continues editing parameter
... processArguments( RequestArguments req, ...
I think its perferctly legitimate for the jde to have something like
this pre-fabricated, so the user dont have to do it.
thomas
|
|
From: Phillip L. <phi...@ne...> - 2008-11-25 13:48:34
|
Thomas Finneid <tfi...@fc...> writes: > The way I see it is that as a java programmer using an IDE, I should not > have to think of the IDE's own orinternal way of doing things, to get my > task done. Rather, the IDE should adapt to how the programming platform > is designed. > > So in java things are oriented around classes, packages, configuration > files etc. For example, when I need a parameter class, the only > questions I should need to answer to create and save the class is > > [packagename.]classname > > the IDE should do the rest, such as finding the correct directory, > saving it etc. Files and classes have a one-to-one mapping in java. So long as you only have to specify one, I can't see that it matters that much. Emacs has many (many) different ways of defining new files already. For example, using ido.el with file completion is far quicker than netbean's new class navigator. > Not really, because thats only one part of the complete functionality I > am looking for. > > I would like to have something like > > insert-class-at-point(). Something like jde-open-class-at-point? > > where the following scenario represents the entire functionality I am > looking for > > - (user wants to add a non exitent parameter class at point > in source code: class: RequestArgument > > public void processArguments( [cursor] > > - user: M-x insert-class-at-point > - func: ask for [packagename.]classname: > [com.stuff.]services.RequestArguments > - func: create buffer > - func: insert class template with package names, class name etc > - func: locate correct directory for class > (based on info from project file and user input) Well, it does this, except you navigate the file system to tell it what the package name is. Netbeans does more or less the same thing. > - func: save buffer As Paul L, says buffer saving is by consent; Emacs will ask you any time you need to save for something to work or to prevent data loss (compiling or quitting). > - user: edit new class code > - user: save > - func: switch to original source buffer and insert class name at point > - func: add correct import statement in original source file > - user: continues editing parameter > > ... processArguments( RequestArguments req, ... > > I think its perferctly legitimate for the jde to have something like > this pre-fabricated, so the user dont have to do it. So do I. Like the refactor support in netbeans. Again, personally, I would get the user to select the directory, so that they can use the file selection system of their choice. Phil |
|
From: Thomas F. <tfi...@fc...> - 2008-11-25 21:02:14
|
Phillip Lord wrote: > Thomas Finneid <tfi...@fc...> writes: >> The way I see it is that as a java programmer using an IDE, I should not >> have to think of the IDE's own orinternal way of doing things, to get my >> task done. Rather, the IDE should adapt to how the programming platform >> is designed. >> >> So in java things are oriented around classes, packages, configuration >> files etc. For example, when I need a parameter class, the only >> questions I should need to answer to create and save the class is >> >> [packagename.]classname >> >> the IDE should do the rest, such as finding the correct directory, >> saving it etc. > > Files and classes have a one-to-one mapping in java. So long as you only > have to specify one, I can't see that it matters that much. Emacs has > many (many) different ways of defining new files already. For example, > using ido.el with file completion is far quicker than netbean's new > class navigator. From an emacs point of view I agree with what you are saying, but from a java developers point of view, my focus is packages and classes, so that would be the easiest to relate to. Then I would not need to use any other file selection tools because its in the package or class name, anyhow. >> Not really, because thats only one part of the complete functionality I >> am looking for. >> >> I would like to have something like >> >> insert-class-at-point(). > > Something like jde-open-class-at-point? Unfortunately not, this one opens the symbol definition. What I was thinking of was what I described blow, something that creates a class for me and inserts the symbol at point. >> where the following scenario represents the entire functionality I am >> looking for >> >> - (user wants to add a non exitent parameter class at point >> in source code: class: RequestArgument >> >> public void processArguments( [cursor] >> >> - user: M-x insert-class-at-point >> - func: ask for [packagename.]classname: >> [com.stuff.]services.RequestArguments >> - func: create buffer >> - func: insert class template with package names, class name etc >> - func: locate correct directory for class >> (based on info from project file and user input) > > Well, it does this, except you navigate the file system to tell it what > the package name is. Netbeans does more or less the same thing. what does this? jde-open-class-at-point? is shows s predefined symbol not creates a new one, as I was looking for. thomas |
|
From: Phillip L. <phi...@ne...> - 2008-11-26 17:11:13
|
Thomas Finneid <tfi...@fc...> writes: >> Files and classes have a one-to-one mapping in java. So long as you only >> have to specify one, I can't see that it matters that much. Emacs has >> many (many) different ways of defining new files already. For example, >> using ido.el with file completion is far quicker than netbean's new >> class navigator. > > From an emacs point of view I agree with what you are saying, but from > a java developers point of view, my focus is packages and classes, so > that would be the easiest to relate to. It's easy to mistake your point of view for all java developers point of view. My feeling is that most java developers just conflate in their mind the directory structure and the packages; both netbeans and eclipse use the folder icon (which is a metaphor for a directory on the hard drive) to represent the packages at source level. > Then I would not need to use any other file selection tools because > its in the package or class name, anyhow. My point is simple; some of the file selection tools, like ido are really, really quick. Re-implementing these does not make sense. >>> Not really, because thats only one part of the complete functionality I >>> am looking for. >>> >>> I would like to have something like >>> >>> insert-class-at-point(). >> >> Something like jde-open-class-at-point? > > Unfortunately not, this one opens the symbol definition. What I was > thinking of was what I described blow, something that creates a class > for me and inserts the symbol at point. Yes, you are correct. I checked the code; currently, it fails if the class does not exist. It would be nice if it offered the option of creating the class or .java file depending on how you think about it. JDEE already has the functionality to create a new class, with a template, and put point in the middle of that new class. Phil |
Thanks for helping keep SourceForge clean.
X