[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
AW: [platform-ui-dev] Towards a new approach to New, Import, and Project refactoring : discussing bug 102527
|
Hi Philippe,
I like your ideas about Wizard pipelines and Triggers.
Triggers could be the glue which binds together Wizards and other tasks.
Such services would not only be valuable in a development environment, but
in a rich client environment as well.
But in order to handle all the triggers and that the system does not go
wild, a trigger/rule management system would be essential.
Cheers
Arne
-----Ursprüngliche Nachricht-----
Von: platform-ui-dev-bounces@xxxxxxxxxxx
[mailto:platform-ui-dev-bounces@xxxxxxxxxxx] Im Auftrag von Philippe
Ombredanne
Gesendet: Mittwoch, 27. Juli 2005 03:11
An: 'Eclipse Platform UI component developers list.'
Betreff: [platform-ui-dev] Towards a new approach to New, Import, and
Project refactoring : discussing bug 102527
I would like to advocate for, and have a discussion on how to :
- re-visit the new and import story,
- add support for project refactoring,
- support those refactoring with wizard pipelines,
- and trigger project refactorings based on project's context changes.
The enhancement request I posted is :
https://bugs.eclipse.org/bugs/show_bug.cgi?id=102527
I think it's a good time, as I assume that planning might be taking
place for the future :-)
Just a quick summary of my thoughts here:
*New, Import and Refactor project are ONE
-------------------------------------------------------
New, Import and Refactor project are three facets of the same story:
what they do, and how they are presented in the UI is important but is
just an implementation detail IMHO ;-) . There is an opportunity to
review them as such.
They apply a transformation to a project to go from one state to another
:
- New & import : from no project to some project, plus some other
artifact
- Refactor : from one project state to another project state.
* Wizards pipelines
----------------------
Projects state changes are akin to a pipeline of transforms applied to a
project.
State changes are done commonly with wizards, and often sequences of
wizards:
- adding some project nature & builder
- configuring some stuffs (i.e. classpath)
- adding some files (from templates for samples or external imports)
- performing some other actions.
Pipelining needs the ability to :
-- invoke and finish a wizard,
-- pass data between loosely coupled wizards in and out.
Having a way to define pipeline wizards that can be composed (and
re-composed) with a loose coupling could support most of the use cases.
* Triggers
---------------
Refactorings could be triggered by the user in the UI (menus, buttons,
...) or based on some change in context for a project. For instance,
adding a new Java file to a project should trigger a refactoring of the
project to support Java.
The most similar available mechanism seems to be
activities/capabilities. In a sense triggers would also support
progressive disclosure.
What do you think?
--
Cheers
Philippe
philippe ombredanne | nexB - Open by Design (tm)
1 650 799 0949 | pombredanne at nexb.com
http://www.nexb.com
http://sf.net/projects/easyeclipse
http://eclipse.techforge.com
_______________________________________________
platform-ui-dev mailing list
platform-ui-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-ui-dev