Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [xtext-dev] Fwd: vorschlag und screencast fuer https://bugs.eclipse.org/bugs/show_bug.cgi?id=241897 [Content Assist] Implement template proposals for Xtext CA

see comments below

2008/12/15 Sven Efftinge <sven@xxxxxxxxxxx>:
> Hi all,
> attached Michael's ideas on template proposals (Could you please send such
> things to the xtext-dev list in future).

ok

> It's in german but I think as the screen cast and the code is english it's
> not hard to understand it.
> @Michael
> My Feedback:
> Looks pretty cool!  :-) Also thanks for pointing me to screencast.com.

i like it too, peter suggested it to me :)

> One thing I don't like is:
>
> arguments=waere eine emf URI mit fragment anteil um auf die EReference
> zu zeigen fuer welche 'LinkingCandidates' berechnet werden sollen.
>
> URIs are much too long and inconvenient.
> As we know for what language a Template is written and we also know what
> EPackages are used in a language I think it would be sufficient in most
> cases
> to just write something like ${event.CrossRef(Transition.event)}.
> If it's not sufficient due to duplicate EClass names in different EPackages,
> we have to prefix it with some additional information (nsURI).

you are right this is much user friendly. i suggest a dedicated
URIConverter to normalize it to a proper  EMF URI because it must work
with Resource#getEObject(String uriFragment);

> What is the purpose of the identifiers (event, state)?

this is the identifier of a TemplateVariable, pls have a look at the
template EBNF described in
org.eclipse.jface.text.templates.TemplateTranslator.

> Will the templates configured via extension point be accessible globally?

user code must implement IProposalProvider#getTemplates(String contextTypeId);
the rest is out-of-scope of the TemplateProposal extension mechanism
and yes i have used the standard eclipse extension point
'org.eclipse.ui.editors.templates' for the fowlerdsl.ui example as
shown in the following snippets:

@Override
public Template[] getTemplates(String contextTypeId) {
  return Activator.getDefault().getTemplateStore().getTemplates(contextTypeId);
}

@Override
public TemplateContextType getTemplateContextType(RuleCall ruleCall,
EObject model, String prefix,
			IDocument document, int offset) {
  	return Activator.getDefault().getTemplateContextRegistry().getContextType(Activator.ALL);
}

and
<extension point="org.eclipse.ui.editors.templates">
	<contextType name="templatesContextTypeAllName"
	  class="org.eclipse.xtext.example.FowlerDslTemplateContextType"
	  id="org.eclipse.xtext.example.fowlerdsl.ui.templates.contextType.all">
	</contextType>
	<include file="templates/templates.xml"
			translations="templates/templates.properties" />
</extension>


> Will we have a preference page per language?

yes, we can  reuse the standard eclipse
org.eclipse.ui.texteditor.templates.TemplatePreferencePage

> Cheers,
> Sven
>
> We don't need to put this into M4. I don't like adding last minute features,
> so let's keep it for M5.
> Begin forwarded message:
>
> From: "michael clay" <michael.clay@xxxxxxxxxxxx>
> Date: December 15, 2008 12:33:40 AM GMT+01:00
> To: "Sven Efftinge" <sven@xxxxxxxxxxx>
> Subject: vorschlag und screencast fuer
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=241897 [Content Assist]
> Implement template proposals for Xtext CA
> hi sven,
>
> anbei der vorschlag und screencast (prototyp) fuer die 'Template
> proposal' erweiterung
>
> 1. zeigt einen prototyp von xtext templates und CrossRef
> TemplateVariableResolver
>
> http://www.screencast.com/t/aA4kfJOL
>
> 2. fuer die template proposal erweiterung schlage ich vor das
> 'IProposalProvider' interface um die folgenden 2 methoden zu
> erweitern:
>
> /**
> * Returns the context type that can handle template insertion at the
> given region
> * in the viewer's document.
> * @return the context type that can handle template expansion for the
> given location, or <code>null</code> if none exists
> */
> TemplateContextType getTemplateContextType(RuleCall ruleCall, EObject
> model, String prefix, IDocument document,int offset);
>
> /**
> * Returns the templates valid for the context type specified by
> <code>contextTypeId</code>.
> * @param contextTypeId the context type id
> * @return the templates valid for this context type id
> */
> Template[] getTemplates(String contextTypeId);
>
> Ich glaube es ist besser das bestehende zu erweitern anstatt ein neues
> interfaces anzubieten da es lediglich
> um die erzeugung von 'ICompletionProposal' geht und daher kein
> unterschied zwischen 'normalen' ContentAssist  'ICompletionProposal'
> und Template 'ICompletionProposal' besteht = im prinzip koennte man
> sogar schon jetzt, ohne aenderung, einfach TemplateProposals
> (ICompletionProposal implementierung) zurueckgeben (dafuer mehr
> aufwand auf seiten des users). die erweiterung um diese 2 methoden
> unterstreicht den Template proposal support von Xtext und macht das
> ganze komfortabler zum einsteigen.
>
> zu beginn wuerde ich die template proposal einmal nur fur 'RuleCall'
> anbieten da ich bei den anderen Grammar types keinen sinnvolen
> verwendungszweck sehe. du vielleicht?  also mal klein anfangen und
> dazulernen.
>
>
> 3. CrossReference TemplateVariableResolver
>
> fuer templates mit CrossReferences habe ich mir einen
> CrossReferenceVariableResolver ueberlegt (und schon implementiert :)
> den man wie folgt ,mittels standard eclipse extension point
> 'org.eclipse.ui.editors.templates', konfigurieren kann z.B.
>
> <template name="transition" description="template for event
> transitions"
> id="org.eclipse.xtext.example.fowlerdsl.ui.editor.template.transition"
> context="org.eclipse.xtext.example.fowlerdsl.ui.templates.contextType.all"
> enabled="true">
> ${event:CrossReference('http://example.xtext.org/FowlerDsl#//@eClassifiers[name=''Transition'']/@eStructuralFeatures[name=''event'']')}
> =>
> ${state:CrossReference('http://example.xtext.org/FowlerDsl#//@eClassifiers[name=''Transition'']/@eStructuralFeatures[name=''state'']')}
> </template>
>
>
> erklaerung: TemplateVariableResolver (TVR) unterstuezen folgende
> variable (escape) definition
>
> identifier:type(arguments)
>
> identifier=event
> type=CrossReference (dieser und moegliche weitere werden von Xtext
> mitgeliefert)
> arguments=waere eine emf URI mit fragment anteil um auf die EReference
> zu zeigen fuer welche 'LinkingCandidates' berechnet werden sollen.
>
>
> lg
> m
> p.s. ich bin die kommende woche auf urlaub ..wenn der vorschlag so ok
> ist koennte ich ubernaechste woche damit fertig sein..also vor M4.
>
>
> _______________________________________________
> xtext-dev mailing list
> xtext-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/xtext-dev
>
>


Back to the top