Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[wtp-dev] WTP Cross-Project Requirements

The following is a list of "cross project" requirements I'm aware of from my
discussions with various WTP teams. Mostly they are requirements on
the base Eclipse platform, but one against VE project.

It is not intended to be a list of every defect, but just major
areas that are nontrivial effort and/or date and/or packaging
sensitive. The purpose of this list is assist "Eclipse Foundation 3.1" planning.
(Though, if anyone knows of any long-range (i.e. 4.0) requirements, don't
hesitate to open feature requests for those too).

If anyone knows of any other areas I've forgotten about,
please let me know. (but otherwise, vote early, vote often :)


= = = = =

Common Command (stack) framework
This is an old bugzilla ... oft requested, but no action taken.
The work around is for unrelated components to pre-req some
common component which provides this function, causing
awkward dependancies among components not otherwise related
except for a desire to provide good Undo experience for user.  
One challenge now, though, is to do this in a
way that does not break API compatibility with/between components
such as EMF, GEF, and VE (they all have their own "common"
command(stack) framework).
In WTP, not having this common command stack at the platform level
causes, for example, some plugins to pre-req an EMF
plugin, so, by convention, all can do the same thing. This is not
as modular as our users/clients require.  

Improved flexible project support
Frankly, we in WTP need to better understand limitations here
and provide specific use cases. (We're probably a month or two
away from having that complete detail).

Content-type-based editor look-up
In addition to a UI for content-based editor look-up (and UI for many
contentType based preferences), there's probably a number of extension
points that need "updating" to use content-type as well as file extensions
in their "specs".  

WebDav should be feature available from update site
The importance of this is that many "web developers" will want to use
webdav but there's no easy solution to packaging or people to improve it
(that I'm aware of) so, my thought is, if it was easily to add to dev. env.
perhaps users from community would come forward with more

JEM should be feature available from update site
Since our project needs to pre-req JEM (but not all of VE)
and since our version of JEM needs to coexist (obviously) with the
version in VE (since many users would have both installed),
it would be best to package JEM as a feature, available
from the eclipse update site, so it would both be easy for users to stay
current, and for there to be no risk conflict if users updated VE or WTP.

Improved Run/Debug Integration/ExtensionPoints
In discussions with WTP members, two specifics have been mentioned
to provide a more "integrated experience" for Eclipse/WTP users.
1). Some "run/debug on server" options should be made available (via
extension point) on normal "launch" dialog (and preferences).
To just add pages is probably not scalable, but we (I should say "I"
don't have any better suggestions at the moment.  
2. Similarly, "run/debug on server" needs some "recent history"
memory, so, for example, if a user "run's" from navigator a specific JSP
file, then later re-run's from the previously-known-as-running-man tool,
the most recently ran page should be remembered and understood to be
the intended 'run' option (not just relaunch the server).

Support for/Compliance with Unicode 4.0
As Unicode 4.0 is the most recent character spec,
and as Eclipse is intended to be general purpose platform,
it needs to be compliant. This is important since
there is a certain "ripple effect" on other spec's and
standards. For example, to be fully support
XML 1.1 requires compliance with Unicode 4.0.

Back to the top