RE: [platform-ui-dev] Towards a new approach to New, Import, and Project

["Philippe Ombredanne" <pombredanne@xxxxxxxxx>]

Arne you wrote:
> But in order to handle all the triggers and that the system 
> does not go wild, a trigger/rule management system 
> would be essential.
I agree.
There are some mechanism in place in Eclipse like
activities/capabilities that are similar, or actions that can be enabled
only for a certain condition/filter : they could provide a good starting
point, and that seem efficient.

Let's take an example:
One simple use case could be, assuming you have JDT and WTP installed:
1/I have a simple project.
2/I create a file with .jsp extension in that project. (trigger could be
based on creation or only when a resource is opened/edited)
3/This context triggers some project refactoring/transform (wizard
pipeline) to set the project in the proper state to support JSP,
whatever that is ;-)  

Now it should be possible to set the code properly so that having
multiple triggers (i.e. copying or importing several JSP files at once)
does not invoke the refactoring several times but just once.
If for a refactoring you have:
- a trigger context
- and end state
The code can be crafted such that triggers are activated only if the end
state is not already reached.

A way to think of it could be to define the triggering context is my
hypothetical example as:
- JSP resource has been added or edited in project
- end state: containing project is a JSP project: (some combinations of
natures, builders ).
- sub end state: Project is a Java project , associated with some
wizardy to refactor a project to Java
- sub end state: Project is a Flexible Java project, associated with
some wizardy to refactor a project to a Flexible Java project
- sub end state: Project is a Web project,  associated with some wizardy
to refactor a project to a Web project

In this mode, each sub end state ( in the case of JSP: being a Java
project, Flexible, and so on) is associated with wizardry.
Each can be invoked selectively based on what sub-state has been
reached.
If you had a Java project as a starting point,  to make it making a JSP,
you could bypass one wizard in the chain which is creating the Java
project, because that sub-state is already there.

So the rules system could be something based on breaking down an end
state in sub-states, each associated with some wizardy to perform
conditionally. 
If the condition are not met, nothing happens.
As long verifying the conditions is something that is relatively cheap (
and that could be even cached in a registry later on IF performance
issues come up) then there should be a way to avoid this to go wild.

Just throwing in some more ideas ;-)

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


> -----Original Message-----
> From: platform-ui-dev-bounces@xxxxxxxxxxx 
> [mailto:platform-ui-dev-bounces@xxxxxxxxxxx] On Behalf Of Arne
> Sent: Wednesday, July 27, 2005 3:43 PM
> To: 'Eclipse Platform UI component developers list.'
> Subject: 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
> 
> _______________________________________________
> platform-ui-dev mailing list
> platform-ui-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/platform-ui-dev
>