Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Eclipse 4 » Feature request(Extending model and services)
Feature request [message #905220] Thu, 30 August 2012 00:16 Go to next message
Rushan Gilmullin is currently offline Rushan Gilmullin
Messages: 61
Registered: June 2011
Member
E4 contains cool concept - MPartDescriptor. It allow to describe the parts one time and in one place, without runtime-configuring code. But the advantages that give this concept is not realized in full.

Carefully 3 month before Juno relise I begin work on my Eclipse Workbench equivelent (UWorkbench). I didn't know e4, I have know about it only after Juno relise. Now this project utilized, becouse it is not needed when e4 is coming. I have mentioned it becouse want to say how working with content was implemented in UWorkbench.

First, I want to say, that the UWorkbench model is very, very similar to e4 (despite the fact that I did not know about e4 when develop it). It contains shared elements and it contains MPartDescriptor equivalent. It's called ComponentType, which is template for one type components. And there are yet one model element - ContentType. This element contains two things:
1. reference to concrete ComponentType (MPartDescriptor in e4 case)
2. content filter - the custom rule that takes the content descriptor (Input URI in e4 case) and return true if the given content descriptor relates to this ContentType and false otherwise.

So, using the ContentType we bind the concrete content (definging by content descriptor) to concrete ComponentType. In other words, it analog to file assotiation in OS with difference only that the content descriptor is more generic and abstract concept then file. Now, we can do things such:

1. Open the given content in appropriate editor.
2. Implement Open With command
3. Check when opening givent content - is there this content was opened in given editor and if was opened, then simple switch to it without opening the new instance of MPart.

We only do:
partSerice.openContent("some_content_uri")
to open the "some_content_uri" by default editor (that set in ContentType of this content)

Or:
partSerice.openContent("some_content_uri", partDescriptor)
to open the "some_content_uri" with the given partDescriptor.

If the "some_content_uri" is ipened already in partDescriptor, the method simple activate the part, containing "some_content_uri". Else it will create the new instance of part and load to it the "some_content_uri".

This feature can be implement in different way. Not necessary do as in UWorkbench - by defining the ContentType object. It is possible forexample to provide interface that map the input uri to MPartDescriptor:

interface ContentAssociation {
MPartDescriptor getDescriptor(String inputURI);
}

and then

partSerice.setContentAssociation(contentAssociation);

[Updated on: Thu, 30 August 2012 00:18]

Report message to a moderator

Re: Feature request [message #905325 is a reply to message #905220] Thu, 30 August 2012 07:08 Go to previous messageGo to next message
Thomas Schindl is currently offline Thomas Schindl
Messages: 5434
Registered: July 2009
Senior Member
If I get that right what you describe here is the concept of editors
which I'll be working on in 4.3 (I've not yet started).

Tom

Am 30.08.12 02:16, schrieb Rushan Gilmullin:
> E4 contains cool concept - MPartDescriptor. It allow to describe the
> parts one time and in one place, without runtime-configuring code. But
> the advantage that give this concept is not realized in full.
>
> Carefully 3 month before Juno relise I begin work on my Eclipse
> Workbench equivelent (UWorkbench). I didn't know e4, I have know about
> it only after Juno relise. Now this project utilized, becouse it is not
> needed when e4 is coming. I have mentioned it becouse want to say how
> work with content was implemented in UWorkbench.
>
> First, I want to say, that the UWorkbench model is very, very similar to
> e4 (despite the fact that I did not know about e4 when develop it). It
> contains shared elements and it contains MPartDescriptor equivalent.
> It's called ComponentType, which is template for one type components.
> And there are yet one model element - ContentType. This element contains
> two things:
> 1. reference to concrete ComponentType (MPartDescriptor in e4 case)
> 2. content filter - the custom rule that takes the content descriptor
> (Input URI in e4 case) and return true if the given content descriptor
> relates to this ContentType and false otherwise.
>
> So, using the ContentType we bind the concrete content (definging by
> content descriptor) to concrete ComponentType. In other words, it analog
> to file assotiation in OS with difference only that the content
> descriptor is more generic and abstract concept then file. Now, we can
> do things such:
>
> 1. Open the given content in appropriate editor.
> 2. Implement Open With command
> 3. Check when opening givent content - is there this content was opened
> in given editor and if was opened, then simple switch to it without
> opening the new instance of MPart.
>
> We only do: partSerice.openContent("some_content_uri")
> to open the "some_content_uri" by default editor (that set in
> ContentType of this content)
>
> Or:
> partSerice.openContent("some_content_uri", partDescriptor)
> to open the "some_content_uri" with the given partDescriptor.
>
> If the "some_content_uri" is ipened already in partDescriptor, the
> method simple activate the part, containing "some_content_uri". Else it
> will create the new instance of part and load to it the "some_content_uri".
>
> This feature can be implement in different way. Not necessary do as in
> UWorkbench - by defining the ContentType object. It is possible
> forexample to provide interface that map the input uri to MPartDescriptor:
>
> interface ContentAssociation {
> MPartDescriptor getDescriptor(String inputURI);
> }
>
> and then
>
> partSerice.setContentAssociation(contentAssociation);
>
>
Re: Feature request [message #905379 is a reply to message #905325] Thu, 30 August 2012 09:21 Go to previous messageGo to next message
Rushan Gilmullin is currently offline Rushan Gilmullin
Messages: 61
Registered: June 2011
Member
Thomas Schindl
If I get that right what you describe here is the concept of editors
which I'll be working on in 4.3 (I've not yet started).


I am very happy to read this. I will wait 4.3.

I want to explain in addition what I mean above.

interface MUriType {
	//The desctiptor that used to open the files of this type
	MPartDescriptor getDescriptor();
	void setDescriptor(MPartDescriptor descriptor);
	
	//the expression (regex or other expression) that match input uris ot this content type
	String getFilter();
	void setExpresson(String exp);
}

//Using
MApplication app = ...;
MPartDesctoptor javaEditorDescriptor = ...;
MPartDesctoptor textEditorDescriptor = ...;

MUriType javaUriType = MBasicFactory.INSTANCE.createUriType();
javaUriType.setDesctiptor(javaEditorDescriptor);
javaUriType.setExpression("*.java");
app.addUriType(javaUriType);

MUriType textUriType = MBasicFactory.INSTANCE.createUriType();
textUriType.setDesctiptor(textEditorDescriptor);
textUriType.setExpression("*.*");
app.addUriType(textUriType);

//the expressions evalutated in direct order - first the javaUriType, then textUriType. So, when we search the UriType for
//file "SomeJavaFile.java", first matched the javaUriType and search stopped. When the UriType for file "SomeText.txt" is searched,
//javaUriType match fail, and the second, more generic criteria is matched.

//Open the uri with service
EPartService partService = ...;
// open the java file with default editor (that defined in java uri type)
partService.openUri("SomeJavaFile.java");
//open the java file with text editor
partService.openUri("SomeJavaFile.java", textEditorDesciptor);

[Updated on: Thu, 30 August 2012 09:27]

Report message to a moderator

Re: Feature request [message #905540 is a reply to message #905220] Thu, 30 August 2012 15:36 Go to previous messageGo to next message
Rushan Gilmullin is currently offline Rushan Gilmullin
Messages: 61
Registered: June 2011
Member
I have one question about juno. How views are implemented? When we select from menu Show View, we show selected view using MPartDescriptor? There are ShowViewHandler in org.eclipse.e4.ui.workbench.swt, it seems this handler is used to show view and it work with MPartDescriptor.

But how implemented the views that presented in initial laout of perspective? By MPart's? So one view need to be defined two time - one in MPart (when we define it location on page) and second - as MPartDescriptor if we want it be openable from menu. Is it true? If true, it is not very comfortable.

[Updated on: Thu, 30 August 2012 15:37]

Report message to a moderator

Re: Feature request [message #909198 is a reply to message #905540] Thu, 06 September 2012 18:11 Go to previous message
Brian de Alwis is currently offline Brian de Alwis
Messages: 242
Registered: July 2009
Senior Member
Right now there are two implementations of Show View: one for pure E4 apps and the other for E3.x based apps. They don't mix at the moment as E3.x and E4.x don't mix. The E3.x view list is generated by the ViewRegistry.

Brian.
Previous Topic:Looking for (open source) projects based on Eclipse4
Next Topic:Non singlton workspace
Goto Forum:
  


Current Time: Fri Oct 31 04:13:33 GMT 2014

Powered by FUDForum. Page generated in 0.02800 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software