[
https://issues.jboss.org/browse/TEIIDDES-926?page=com.atlassian.jira.plug...
]
Dan Florian commented on TEIIDDES-926:
--------------------------------------
Conversation with Barry on 7/8/11
working on extension point and plugin today danflo @ 8:09
cool blafond @ 8:09
ext pt pretty simple ... danflo @ 8:09
a name, a collection of one or more paths to mxd files, and an optional class name of a
handler (hope to have default base classes) 8:10
sound good? missing anything? 8:10
I think so blafond @ 8:11
SF and RestEasy will need to be 2 initial contributors 8:11
right danflo @ 8:12
Do you expect multiple mxd files for one contribution? or is that 2 contributions? blafond
@ 8:12
was thinking for one contribution. for instance, one plugin can register 2 different
namespaces. danflo @ 8:12
k blafond @ 8:13
not sure that makes sense but never know danflo @ 8:13
right blafond @ 8:13
How do we handle users creating new MXD's in their workspace? They pulled into the
registry in a different way? 8:14
this is also a design I'm throwing around: per contribution there is an optional
handler for each mxd (rather than one optional handler per contribution) danflo @ 8:15
need to talk over that scenario but you said that we don't need that for 7.5 8:15
ok ^^ blafond @ 8:16
right, but want to make sure we have a design in our heads 8:16
I've thought about that … do we make them "add" a new mxd to a registry or
do we just discover them using resource change events on project open/close, delete, etc.
and there might be other approaches. danflo @ 8:17
ya. not sure. Sure would be nice to have a "non-workspace" location that can be
used to persist a user's "personal/enterprise" resources blafond @ 8:18
Do we make them "Define" one the first time they 1) Create New MXD or 2) Import
MXD into workspace (or discovered)?? 8:19
otp danflo @ 8:20
all good questions … kind of leaning toward not discovering them and having a view that
shows the mxd registry where they can add, delete, edit, import, etc. but need to talk all
of it through later with ya danflo @ 8:25
I'm leaning in that same direction. Thinking that Model Extensions are NOT
project/vdb/".workspace" centric so we need another paradigm blafond @ 8:26
right danflo @ 8:27
Not sure if any other JBoss project has a feature that works like this or not. blafond @
8:27
I'll ping Fitz 8:27
remember all that is for post 7.5 danflo @ 8:27
right blafond @ 8:28
If it was me, I'd set up DTP connection profiles/drivers in this way. Right now
it's per .workspace
Create persistance and loading mechanism for XML-based Model
Extension Definitions
----------------------------------------------------------------------------------
Key: TEIIDDES-926
URL:
https://issues.jboss.org/browse/TEIIDDES-926
Project: Teiid Designer
Issue Type: Sub-task
Components: Import/Export, Modeling
Affects Versions: 7.4
Reporter: Barry LaFond
Assignee: Dan Florian
Priority: Blocker
Fix For: 7.5
Attachments: example_extension_tags.txt, modelExtension.xsd,
ModelExtensionsPlan.txt, salesforce.mxd, SimpleExtensionsExample.zip
The New Model Extension framework requires reading (loading) and writing XML-formatted
Model Extension Definition properties.
These property definitions will replace the old "Extension Model" EMF
construct.
Attached are:
- salesforce.mxd a sample XML-formatted Model eXtension Definition file
- modelExtension.xsd a backing schema file
- example_extension_tags.txt : XMI file snippets of annotations and tags from an
extended Relational Model
--
This message is automatically generated by JIRA.
For more information on JIRA, see:
http://www.atlassian.com/software/jira