|
On 04/20/2017 10:10 AM, Mikaël Barbero
wrote:
On 04/20/2017 09:30 AM,
Mikaël Barbero wrote:
Let's push the idea with a .java files:
I create a new file Test.java in a
project.
If it's a
project without Java nature
do nothing
and return
OR
propose to
add Java nature to project?
fi
Definitely the 2nd one.
if Test.java
is not in a source folder
do
nothing and return
OR
propose
to make parent folder a source folder or to move
to existing source folder? if parent is project,
propose to create a source folder or move to
existing source folder?
fi
In this case, it seems like an
heuristic of reusing some source folder in the parent
hierarchy if existing, or creating a new source folder
for the parent project would cover that vast majority of
cases. Then, for those who are in trickier state, they'd
have to go to JDT project settings (which isn't
difficult).
I don't think it's user friendly to use an heuristic to
move the file to a location different from where the user ask
to create the java file.
I think there is some misunderstanding: I'm not at all suggesting to
move to another place, I'm suggesting that
* if there is one of the *parent* folder that's already configured
as a JDT source folder, use this as parent folder and assume the
relative path between file and source folder is the package
* if there is no parent folder configured as a JDT source, assume
the folder is the source folder and set no package.
We already know it, so we can pre-fill the name field, why
don't you want to let name change it in case they did a typo?
Because as the file already exists at that time, if we let user
change the name, we leave room for user creating a Java error. In
such case, I think it's better to force the classname to be the
filename and let user refactor later if they need to.
Java imposes constraints about where Java files can be put
(and JDT adds some more, e.g.g, source folders), and I have
the feeling that inferring the file stats (name, location)
from the Java information (package names, compilation unit
name) offers a better UX than inferring the Java information
from the file stats. When I develop some Java code, I think in
terms of Java types, packages and not files... That's also why
I love my IDE, why I use "Open Type..." dialog and not "Open
Resource...", etc.
That's because you're a Java and Eclipse native ;) People coming
from other tools, or from nowhere, without big experience about the
language think more in term of files/resources. The proposed
workflow would IMO help them.
Note that as I'm looking more and more at other languages and file
format (am I becoming polyglot finally?) , I now tend to prefer
workflows which are language independent and start to abandon Open
Type in favor or Open Resources, because overall, Java constraints
mentioned above make it pretty easy to browse a Java project with
resources-based approach.
|
