Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [wtp-dev] Why Do We Need the Preference to Enable Multiple Modules per Project?
I'd imagine that currently users expect the a new dynamic web app wizard to produce a project because the wizard is titled "Dynamic Web Project"! I think the suggestion to seperate out the task of creating WTP projects into a new "module-container-project" wizard is an good one. I like the seperation of the two tasks and I like the idea of having the module creation wizards prompt the user to create a new project (default, for novices) or attach to an existing project. I'd also add a converse suggestion - the "module-container-project" wizard prompts the user for a name, a target server type and then prompts the user choose a "New XXXX module" wizard, (restricted to the subset of modules types supported by the target server. (Wasn't there a New Flexible Java Project wizard like this in M4? I can't seem to find it now in M5) I would have thought it important to introduce novice users to the distinction between modules and projects as early as possible. Doing so would encourage them to aggregate tightly coupled modules into a project, allowing WTP to provide greater sync control over the whole develop/deploy/test cycle - more control means less room for pilot error. To be honest, I have been too close to the coal face (extending WTP with new module types targetting a CapeClear (non-J2EE) server) and I didn't notice the "allow multiple.." preference at all - it does seem like an odd restriction to have enforced by default when a lot of users will come to WTP expecting multiple module support. Users may be confused and wonder why modules exist at all. Of course at the moment, having multiple modules in a project has it's restrictions - JDT doesn't readily adapt to classpath per module (as Tim pointed some out) and the current publishing implementation doesn't seem to be able to publish just one module (it publishes all of the projects modules). I had assumed until now that these were challenges that would be resolved in WTP between now and 1.0. but now I'm not so sure :-( 

John.

Stephen Duncan wrote:


I was just about to go back and suggest this.  However, I'll describe
how I think it makes sense to me (slightly different from Tim). Tim's suggestion still suggests that user's would think of a new 
dynamic web app as a module rather than a project.  I think that most
of us users would default to thinking of it as a project.  In fact,
you select new "Dyanmic Web Project", and yet you would have it create
a module.  That's confusing by itself.

Here's my suggestion, though I'm not perfectly happy with it either.

When you create a new web app project, it should be a simple
single-module project.  It should have an advanced option to create it
as a module attached to an existing "module-container project" (please
replace with some better name), with the option to create it at the
same time, just as the current wizard allows.

The gist here is that the Project that can contain multiple modules
should be its own seperate wizard, and it's own kind of Project, from
the user point of view.  I think, in the long run, that's a lot more
clear than the current behavior.  Now the module-container is clearly
what it is, rather than being a side-effect of creating the first
module in the project.

-Stephen Duncan Jr

On 7/7/05, Timothy Deboer <deboer@xxxxxxxxxx> wrote:


The other reason it is off by default is that there are several restrictions
with putting multiple modules in a project. For instance, the classpath is
shared - this means we can't validate the modules correctly, and we can't
target the modules to different servers. I vote that the default remains
off, but that we do some usability work to make it easier to switch. For
instance, we could remove the preference page and put the option directly in
the new module wizard (under an 'Advanced' setting ;-) and with a short
description), with a sticky selection so that it keeps its state the next
time the user creates a module. 
Tim deBoer
WebSphere Tools - IBM Canada Ltd.
(905) 413-3503  (tieline 969)
deboer@xxxxxxxxxx
John Lanuti <jlanuti@xxxxxxxxxx> Sent by: wtp-dev-bounces@xxxxxxxxxxx 07/07/2005 09:15 AM 
Please respond to
"General discussion of project-wide or architectural issues." 

To "General discussion of project-wide or architectural issues."
<wtp-dev@xxxxxxxxxxx> cc Subject Re: [wtp-dev] Why Do We Need the Preference to Enable Multiple Modules per Project?
Arthur, 
The flexible project preference was added to give a better "out of the box"
experience. If a new user picks up WTP, it is much easier for them to deal with the concepts surrounding one module per project. The wizards are easier to follow and it hides a lot of the complexity from them. It was our guess that most users would still be using this one 
module per project paradigm, however, we absolutely want to allow
flexibility and show off all the work we did to provide this flexibility. In this 
respect, multiple modules per project is an advanced feature for advanced
users. And what do we typically do with advanced options and settings? We hide them by default. This was the reasoning behind the preference -- to hide the complexity and confusion to someone who did not care about these advanced flexible options. 
That being said, I guess I'd like to hear feedback from others on what they
think.  I mean, if it confused Arthur, it seems like it will surely confuse
a novice user! :-) Maybe we could keep the preference, but leave it on by default instead of off? Thanks, 
John Lanuti
Software Engineer, IBM Rational
jlanuti@xxxxxxxxxx
t/l 441-7861

"You see this wandering soul, he's never gonna stop, because he loves and
he feels this world can grow. He's not afraid of feeling, he loves what he believes, he feels, and he 
grows."  - Of A Revolution
Arthur Ryman <ryman@xxxxxxxxxx> Sent by: wtp-dev-bounces@xxxxxxxxxxx 07/07/2005 08:00 AM 

Please respond to
"General discussion of project-wide or architectural issues."
To wtp-dev@xxxxxxxxxxx cc Subject [wtp-dev] Why Do We Need the Preference to Enable Multiple Modules per Project? 







While using WTP to develop some Web apps, I ran into a feature of our UI
that I find problematic, and I'd like to hear from other people about why we
need this feature. 
The feature is the Flexible Project Preference. The user now has to
explicity check a box to enable multiple modules per project. I find this problematic for several reasons: 
1. It caused a usability problem. I created a project with a Web module in
an earlier build of WTP and then worked on it with a later build which has
this preference disabled. It caused the Web service wizard to fail [1]. This
will be corrected, but it pointed out to me that this preference is causing
bimodal behavior. Our code in now more complex than it needs to be and there
is more potential for bugs and usability problems. 
2. We went to a lot a development effort to upgrade the code base to allow
multiple modules per project. This should be the WTP norm. We should promote
this feature and improve our UI to make it very easy for users. Disabling it
seems like a step backwards and an admission of failure. 
3. The initial wizards to create multiple modules were somewhat awkward,
and this may have motivated this preference. However, the wizards are very
usable now so I believe this preference has outlived its usefulness and is
now just extra baggage that should be jetisonned asap. 
I have created a bug [2] to remove this preference. Please review it and
voted for it if you agree. 
Is anyone a strong advocate of this preference? If so, please explain why
you think we should keep it. I'd like to discuss this in our telecon today. Let's move on this quickly since time is running out. Thx. [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=102244 [2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=102487 
Arthur Ryman,
Rational Desktop Tools Development

phone: +1-905-413-3077, TL 969-3077
assistant: +1-905-413-2411, TL 969-2411
fax: +1-905-413-4920, TL 969-4920
mobile: +1-416-939-5063, text: 4169395063@xxxxxxx
intranet:
http://labweb.torolab.ibm.com/DRY6/_______________________________________________
wtp-dev mailing list
wtp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-dev
_______________________________________________
wtp-dev mailing list
wtp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-dev


_______________________________________________
wtp-dev mailing list
wtp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-dev

Back to the top