Re: [teiid-designer-dev] other model types
by Steven Hawkins
Now we have:
Barry - include them all
and
John - include them only if there is some ui reason
So they should be included then, because Designer is a ui and used to use those values for something?
Just to make sure my assumptions are correct, if there is additional values you guys want to track, then they will be set as properties on the model in the vdb.xml rather than going into a separate model manifest (such as the old entries for model, path, uuid, or update time)? And if that is the case then it seems like you will want model entries in the vdb.xml for these other model types.
----- Original Message -----
From: "John Verhaeg" <jverhaeg(a)redhat.com>
To: "Steven Hawkins" <shawkins(a)redhat.com>
Cc: "teiid-designer-dev" <teiid-designer-dev(a)lists.jboss.org>
Sent: Thursday, March 25, 2010 4:22:53 PM GMT -06:00 US/Canada Central
Subject: Re: [teiid-designer-dev] other model types
On Mar 25, 2010, at 3:33 PM, Steven Hawkins wrote:
> We need to separate a couple of things out here.
>
> My current understanding is that the vdb.xml file is becoming a replacement for both the ConfigurationInfo.def file and MetaMatrix-VdbManifestModel.xmi. The old ConfigurationInfo file did not contain any model type information - that was in the VdbManifestModel. The proposed schema for vdb.xml does contain model type - but only allows PHYSICAL, VIRTUAL, and FUNCTION.
>
> Runtime uses this information in the following ways:
> 1. model type - available of our managed ModelMetadata, which
> a. drives UI - such as show physical models in a display relating to connector bindings.
> b. (Teiid 7.0 new) allows us to determine function models so that they can be loaded into the query metadata.
> 2. the model entry in the old ConfigurationInfo.def and in the new vdb.xml contains visibility information which we use to
> a. hide virtual or physical metadata from users.
> b. determine whether the actual model resource is retrievable through system procedures. This is legacy behavior. It does not seem like a very good idea to even allow this in general. The only "models" that a client is really interested in retrieving are XSDs and that may no longer be needed given Ted's update of web service.
>
> There are additional properties that we look at, but are specific to PHYSICAL models (dynamic vdb importer settings, multisource enablement, etc.).
>
> So to re-rephase. Designer previously used the MetaMatrix-VdbManifestModel.xmi to track models of types more than just PHYSICAL, VIRTUAL, and FUNCTION. Does it still need/want to do that in the vdb.xml?
Thanks for the clarification; that helps a lot. I can't think of any reason to keep these other than some purely UI reason like wanting to show model-type-specific icons in a VDB editor or view.
Thanks,
JPAV
14 years, 1 month
Re: [teiid-designer-dev] Potential Designer Source Bindings Strategy
by Barry Lafond
> Just an initial thought with only one read through. Would it be a good idea to implement "entire redeploy' strategy described in the last paragraph to see if there is a performance issue?
A) I too am concerned with performance. One thing Jacobs asked me yesterday was whether we needed to actually put the models in the VDB. We have to work with Ramesh on this, but my understanding is they don't use the models. To execute queries, the connector info and "query metadata" needs to be present and that means indexes to view models and their associated/dependent source models.
RAMESH TODO: Clarify "required" VDB content.
B) In discussions with Ramesh a couple of weeks ago, he was receptive to providing hooks for our "hidden" VDB concept, so I'm hoping there is some wiggle room here.
RAMESH TODO: Clarify ability to manage a special/simplified VDB.
C) There are "export" methods in Teiid API that I'm guessing will allow us to just copy/paste connectors between Teiids. If not, we have to do a little more work, but its doable.
D) I'm still struggling with the concept of a "SandBox" Teiid. If a user has multiple Teiids and there are Connector Types that don't reside on ALL Teiids, then as a user, I'd have to work a little harder, switching between "SandBoxes" as I try to create source models, wire them to different Teiids for the purpose of "Preview Data ". I think the Hidden VDB concept is still the cleanest paradigm. User need only Import/Create Sources. Create View models. Assign/change/swap (DND) models to connectors deployed on any Teiid and the Preview Data just works. I can also have a source model bound to connectors on multiple Teiids. As long as we decorate (via Model Explorer AND Execution/Connectors/Teiid View) this connectivity we should be good to go.
> Lastly, I was also thinking maybe for physical models only, we could additionally include the option to preview the import/actual source to help verify against results coming from Teiid.
E) As long as we're successful in replacing our JDBC calls at import time with DTP's version, I think we should be able to preview the actual source.
Barry
That would make sense to me.
> For each Teiid server registered within the Designer, an associated
> VDB will be created. These VDBs will be hidden from the user and will
> not appear in their Eclipse workspace. These VDBs will be deployed
> (unbeknownst to the user) to their associated Teiid server and will
> contain all the models from the workspace that have source bindings
> with connectors installed on that server. These local, hidden VDBs and
> their associated deployed VDB must stay in sync. The class in charge
> of this will be the SourceBindingsManager (SBM).
Another thing I'm concerned about is the "for each server" clauses that appear throughout. First, just a clarification issue - to avoid confusion with the JBoss container (AS/EAP), I'd propose that we get used to calling the Teiid runtime engine just "Teiid".
Secondly, we're assuming the user has an available "sandbox" Teiid available to which they're allowed to deploy connectors and VDBs that they're testing, presumably the one bundled with JBT/JBDS, knowing this assumption is a bit tenuous. Making that same assumption for all Teiids configured seems to be reaching too far; we probably need the user to pick which Teiid is their sandbox instance, and use that consistently unless they explicitly direct us to use another one.
Thirdly, considering the user really needs to provide us not only the Teiid to which we'll deploy these hidden workspace VDBs, but also must only use connectors available on that particular Teiid (or somehow auto-copy connectors from other Teiid instances to the sandbox Teiid), the potential for confusion to the user as to what we're trying to accomplish seems high. The only thing they wouldn't be doing beyond a "normal" use of Designer is creating the hidden VDB. I'm worried this is starting to look like much more of a hack that it first appeared. What I'm now wondering - and I haven't digested this enough myself yet - is whether we should just punt the whole hidden VDB idea, and make the user create one in all cases. I'm thinking maybe the only real issue here is when they right-click on a model to preview, for instance, that we then ask them for the name of a VDB that we create on-the-fly containing the model being previewed and, in the case of a virtual model, any of!
its dependencies. We, of course, would attempt to have good defaults for the sandbox Teiid, VDB name, connectors, etc. I'm thinking that if we manage the relationships between the workspace models and their associated VDBs, the user could still drive the whole experience of preview/execution from the workspace, and we'd just do some simple, more intuitive things like auto-synchronizing the VDB containing the model(s) being previewed/executed.
Lastly, I was also thinking maybe for physical models only, we could additionally include the option to preview the import/actual source to help verify against results coming from Teiid.
Thoughts?
Thanks,
JPAV
_______________________________________________
teiid-designer-dev mailing list
teiid-designer-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/teiid-designer-dev
14 years, 1 month
other model types
by Steven Hawkins
Quick question.
The current xsd for the vdb.xml file allows for PHYSICAL, FUNCTION, and VIRTUAL model types.
What about the other legacy types (which were stored in the old manifest model)?
TYPE
VDB_ARCHIVE
UNKNOWN
CONFIGURATION
METAMODEL
EXTENSION
LOGICAL
MATERIALIZATION (a subtype of physical?)
Outside of matrerialization, the only information related to these models that was used at runtime was the ConfigurationInfo.def model visibility entry to determine if the corresponding .xmi file could be retrieved.
Steve
14 years, 1 month
Re: [teiid-designer-dev] Potential Designer Source Bindings Strategy
by John Doyle
----- "John Verhaeg" <jverhaeg(a)redhat.com> wrote:
> On Mar 24, 2010, at 4:06 PM, John Doyle wrote:
>
> > Just an initial thought with only one read through. Would it be a
> good idea to implement "entire redeploy' strategy described in the
> last paragraph to see if there is a performance issue?
>
>
> That would make sense to me.
>
> > For each Teiid server registered within the Designer, an associated
> > VDB will be created. These VDBs will be hidden from the user and
> will
> > not appear in their Eclipse workspace. These VDBs will be deployed
> > (unbeknownst to the user) to their associated Teiid server and will
> > contain all the models from the workspace that have source bindings
> > with connectors installed on that server. These local, hidden VDBs
> and
> > their associated deployed VDB must stay in sync. The class in
> charge
> > of this will be the SourceBindingsManager (SBM).
>
>
> Another thing I'm concerned about is the "for each server" clauses
> that appear throughout. First, just a clarification issue - to avoid
> confusion with the JBoss container (AS/EAP), I'd propose that we get
> used to calling the Teiid runtime engine just "Teiid".
+1
>
> Secondly, we're assuming the user has an available "sandbox" Teiid
> available to which they're allowed to deploy connectors and VDBs that
> they're testing, presumably the one bundled with JBT/JBDS, knowing
> this assumption is a bit tenuous. Making that same assumption for all
> Teiids configured seems to be reaching too far; we probably need the
> user to pick which Teiid is their sandbox instance, and use that
> consistently unless they explicitly direct us to use another one.
Do you think it would be a workable solution to enable a user to configure connections to multiple Teiids, but have only one connection alive at a time? All the UI would then be synchronized to that Teiid and we could do our 'hidden' work safely.
>
> Thirdly, considering the user really needs to provide us not only the
> Teiid to which we'll deploy these hidden workspace VDBs, but also must
> only use connectors available on that particular Teiid (or somehow
> auto-copy connectors from other Teiid instances to the sandbox Teiid),
> the potential for confusion to the user as to what we're trying to
> accomplish seems high. The only thing they wouldn't be doing beyond a
> "normal" use of Designer is creating the hidden VDB. I'm worried this
> is starting to look like much more of a hack that it first appeared.
> What I'm now wondering - and I haven't digested this enough myself yet
> - is whether we should just punt the whole hidden VDB idea, and make
> the user create one in all cases. I'm thinking maybe the only real
> issue here is when they right-click on a model to preview, for
> instance, that we then ask them for the name of a VDB that we create
> on-the-fly containing the model being previewed and, in the case of a
> virtual model, any of its dependencies. We, of course, would attempt
> to have good defaults for the sandbox Teiid, VDB name, connectors,
> etc. I'm thinking that if we manage the relationships between the
> workspace models and their associated VDBs, the user could still drive
> the whole experience of preview/execution from the workspace, and we'd
> just do some simple, more intuitive things like auto-synchronizing the
> VDB containing the model(s) being previewed/executed.
>
> Lastly, I was also thinking maybe for physical models only, we could
> additionally include the option to preview the import/actual source to
> help verify against results coming from Teiid.
A container DS is not supposed to used outside of the container. There are ways you can hack access, but it's an anti-pattern. With the DTP plugins I'm working on the user will be able to configure a DTP connection to the source DBMS and view the data through the same UI that they will use to query Teiid. I think this is a pretty good solution, and a nice new feature that we'll get for free.
>
> Thoughts?
>
> Thanks,
>
> JPAV
14 years, 1 month
Re: [teiid-designer-dev] other model types
by Barry Lafond
I created a VDB and added all of our model types (except Function & Materialization)
The actual "modelType" values are:
PHYSICAL
VIRTUAL
TYPE (.xsd)
EXTENSION
LOGICAL
But I think the values you have below are from our "ModelType" class. So I don't have any reason to not include them all.
Barry
----- Original Message -----
From: "Steven Hawkins" <shawkins(a)redhat.com>
To: "teiid-designer-dev" <teiid-designer-dev(a)lists.jboss.org>
Sent: Thursday, March 25, 2010 9:55:45 AM GMT -06:00 US/Canada Central
Subject: [teiid-designer-dev] other model types
Quick question.
The current xsd for the vdb.xml file allows for PHYSICAL, FUNCTION, and VIRTUAL model types.
What about the other legacy types (which were stored in the old manifest model)?
TYPE
VDB_ARCHIVE
UNKNOWN
CONFIGURATION
METAMODEL
EXTENSION
LOGICAL
MATERIALIZATION (a subtype of physical?)
Outside of matrerialization, the only information related to these models that was used at runtime was the ConfigurationInfo.def model visibility entry to determine if the corresponding .xmi file could be retrieved.
Steve
_______________________________________________
teiid-designer-dev mailing list
teiid-designer-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/teiid-designer-dev
14 years, 1 month
Re: [teiid-designer-dev] Potential Designer Source Bindings Strategy
by Barry Lafond
> Can we have a deployed VDB on Teiid that doesn't have any models (maybe marked inactive)? If yes, we can create the VDB when we create the associated Teiid server object. Then the deployed VDB lifecycle would be the same as the Designer's Teiid server object. Trick would be to make sure this deployed VDB exists the first time the connection is established. Remember servers can be created without connecting to them.
BML - Have to check with Ramesh, but I think we have some flexibility
> Can you query a model with a connector that is in a VDB that has another model which doesn't have a connector? If yes, we can add/remove models to the hidden VDB as models are created/removed in the workspace.
> It would be much simpler for us to manage the local VDB and redeploy it in its entirety each time a change is made but their might be performance issues associated with that. But this might be the only way to get the indexes updated.
BML - We have two functionalities we are trying to provide here 1) Source Binding management and 2) Preview Data
1) Source Binding management requires TEIID + VDB (CONNECTOR NAMES & MODEL REFERENCES)
- it does not require MODELS or INDEXES
2) Preview Data requires VDB (INDEXES + CONNECTOR NAMES + SOURCE BINDING)
- it does not required MODELS
So, potentially, we could manage a "loose" hidden VDB. At no time does it required MODELS (clarify with Ramesh). Source binding management only requires the CONFIG.XML in the VDB contain "Source Binding" info. Until a user actually executes Preview Data, we technically wouldn't have to zip up the INDEXES with the VDB.
Barry
_______________________________________________
teiid-designer-dev mailing list
teiid-designer-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/teiid-designer-dev
14 years, 1 month
Re: [teiid-designer-dev] VDB configuration
by John Doyle
----- "John Verhaeg" <jverhaeg(a)redhat.com> wrote:
>
On Mar 23, 2010, at 1:39 PM, John Doyle wrote:
>
JDoyle-I think we would benefit from a more nuanced view of 'user' and 'task', that's kind of my central point. What's needed for a new user and what might be efficient for a knowledgeable long-term user are not necessarily the same thing. What's the efficient way to change a name or binding is not necessarily a good way to remove a model. I work in eclipse all day, and on some occasions I fire up vi and mvn to make a one line change when I ||'d and I should have &&. It's not a question of the UI being a PITA or not, we're not going to make a perfect UI, but we can shoot for one that satisfies more modalities.
>
> But you've just validated my point. If you want a super-quick change without the need for the UI, then you won't use the UI, you'll just open up your favorite text editor and change it directly. In other words, you're not going to open up Eclipse either just so you can get to some text editor.
JDoyle- Sorry, if it weren't in a archive I would agree with you, but I'm not going to unzip it, edit and rezip, I would use eclipse.
>
Regarding the "perfect" UI, of course we won't be perfect, but it is the point of the UI to be THE efficient way of doing things, without having to spend brain cycles on remembered syntax, dependent information, etc. Much of people's use of text editors from the command line is indeed because the UI is a PITA. They may not call it that because it still is useful and actually used for much of their work, but it still falls short in several areas. The real distinction between when I use command-line vs. the UI is always going to be driven by the speed of the UI startup; that's the only modality that should come into play.
JDoyle- We're getting a little esoteric here but seriously, your don't recognize this as your personal preference?
If Pages or Word started just as easily and quickly as Notepad AND they were as easy to use and noise-free as Notepad, Notepad wouldn't exist. The former we'll never be able to do much about (and in fact usually contribute towards making worse), but the latter we should definitely be able to address. The UIs can be better, and we should strive for that from the outset rather than putting in a stop-gap solution that bypasses the whole point of the UI. And don't lose sight of the repercussions behind the "direct" editing you're suggesting - it's also very, very dangerous unless you really know what you're doing AND complete all the side-work that must go hand-in-hand with those changes, such as adding/removing models, updating indexes, etc.
JDoyle-It's not a stop gap, it's another option. Believe me, I'm not against good tooling. I've been working with Hibernate Tools lately and have no time to learn what needs to be in a hibernate.config.xml or a reveng.xml, I use the UI to create them. That said, if I need to edit the username and pw for the DB connection, I'm going to edit the xml in my eclipse project. And as for the side effects, isn't this what the validation is for? Why can't validation happen and the indexes be updated on notification that the file has changed? These seem like technical challenges to me.
>
>
JDoyle-It seems to me that if we are moving to a world where the server doesn't need the tooling, then our artifacts are going to have to get a lot more user fiiendly, or what a user will be able to accomplish w/o tooling will be very limited. I know that the plan for bindings is to simplyfy to just a name, and I think we should push the rest of the artifacts in the same direction.
>
Whether the server team decides to ensure the artifacts are easy to directly manipulate or not is up to them, but the whole point of having tooling is so they don't have to worry about that. We want the tooling to not be an absolute requirement because of exception scenarios where we don't want the lack of tooling to be a show-stopper, such as a server admin without access to tooling correcting a simple problem in a configuration or the tooling not being available until a few days/weeks after the runtimes are. But we and the users always still want the tooling; if not, we're wasting out time. It doesn't take much experience manipulating the multitude of XML and other text-based configuration files on a server to know we're not wasting our time.
JDoyle-I'm not arguing against the current tooling, I'm suggesting an addition. And as far as text based configuration files go, they don't undermine the value of good UI, here again Hibernate Tools are a good example. JBoss's success has been fed by (and limited by) it's use of text based configuration. Anyway, I acknowledge this suggestion as DOA.
>
If the startup time of the UI really is the tipping point that creates this modality, then maybe we have an argument why the parts of our file that don't have other external implications, or dangerous impact in the case a value is entered incorrectly (the connector and binding properties I'd assume), should go in a separate file that is intended to be directly manipulated via a simple text editor. Did we not get enough feedback on this? Should we keep all of the information in that was in the VDB manifest in a separate file? But even if that's the case, then I expect the "direct manipulator" of the other information to manipulate it in the most direct way possible - via the command-line; there's no reason to assume he'd take the time to wait for the tooling to start, find the correct VDB in the tree, open its editor, and finally open the correct text editor tab just so he can make that "quick fix".
>
Thanks,
>
JPAV
>
>
14 years, 1 month
Teiid Tools - Designer, CDK, etc.
by John Verhaeg
The Designer team has been disconnected from the whole Eclipse CDK plug-in effort until fairly recently (our own fault due to poor communication issues). Now that I'm aware of the effort, I think we need to make some changes. At a minimum, the CDK efforts needs to be pulled into the radar of the other Eclipse tooling efforts (JBT and possible JBDS). Since this is an Eclipse tool, it "belongs with" all of our other Eclipse tools in JBT regarding building, testing, packaging, and delivery. Even from a community standpoint, having this project hosted via SourceForge somewhat hides it from that community, not to mention the JBT developers concerned with delivering a suite of tools that need to adhere to a number of guidelines to achieve a necessary level of quality and consistency. Then there's also the consideration of what level of integration we may want with other tools without our suite. Finally, we've also envisioned other possible tools for Teiid that would not fall under the umbrella of either Designer or CDK.
Therefore, I propose that we change several of our Designer components to be more generically "Teiid Tools" components. We'd want the following:
A new URL at www.jboss.org/teiidtools.html
Either a new JIRA project (something like TEIIDCDK) or changing the existing TEIIDDES project to something like TEIIDTOOLS
As with the JIRA change just described, a similar change to the mailing lists
A new home for the CDK code, either in its own project that gets pulled into the JBT build/testing/packaging framework, or within the JBT SVN.
A new Teiid Tools project page that incorporates documentation, downloads, etc., for Designer, CDK, and whatever other Teiid-related tools we invent.
Sanjay to be made a committer on the appropriate SVN.
A discussion with the JBT team concerning the CDK, when to include it in a JBT/JBDS release, etc.
Thoughts?
Thanks,
JPAV
14 years, 1 month
Re: [teiid-designer-dev] VDB configuration
by John Doyle
Some responses inline, but you guys have convinced me of one thing, this is clearly not in scope for any of the upcoming releases. :)
----- "John Verhaeg" <jverhaeg(a)redhat.com> wrote:
>
> On Mon, 2010-03-22 at 13:21 -0400, John Doyle wrote:
> > I've been working on the VDB UI to stub out the changes for Teiid 7 and wanted to float an idea. How about adding an additional tab to the VDB editor view that showed the configuration.def file in a raw XML view? This seems like a pretty standard eclipse paradigm and I think plays into the way the typical JBoss user expects to interaction with their tools.
>
>
I'm also completely against this.
>
First let me speak from a general GUI design viewpoint: The whole point of the GUI is so the user doesn't have to deal with the raw file directly. The GUI should make it easier, not harder, to work with the contents of that file. The very existence of the file within the VDB should be something the user doesn't need to know, at least from a client standpoint. I understand its format and presence are by necessity public so that the server can move closer to a world where the tooling is not required to use the server, but the whole idea of having tooling in the first place is to make things easier for the user, especially those new to the technology. If the tooling is such a PITA that users want to go around it by working on the file directly, then a) we've failed as develops of useful tooling and b) they'll do so from the command line and outside of Eclipse anyway.
JDoyle-I think we would benefit from a more nuanced view of 'user' and 'task', that's kind of my central point. What's needed for a new user and what might be efficient for a knowledgeable long-term user are not necessarily the same thing. What's the efficient way to change a name or binding is not necessarily a good way to remove a model. I work in eclipse all day, and on some occasions I fire up vi and mvn to make a one line change when I ||'d and I should have &&. It's not a question of the UI being a PITA or not, we're not going to make a perfect UI, but we can shoot for one that satisfies more modalities.
As others have already pointed out, we would additionally need to add all kinds of support for editing this file, such as code completion, and deal with synchronization issues. I'd also argue just having the tab present makes it confusing as to the "correct" or "preferred" way to maintain this information, similarly to the same confusion added by other components within Eclipse that follow this paradigm. Using the plug-in manifest editor as an example, the only time I use the text editor tab within in the manifest editor is when a) I have to change something that isn't supported by the GUI, such as localization, or b) I "think" I'm going to save time by directly pasting something into it that I inevitably realize breaks something because of some silly syntax error that I never would have encountered had I used the GUI to begin with.
>
Now to something much more specific to this file: Unlike other text-based files that a user may edit to configure something, much of the content within this file is populated as a direct result of a completely separate action performed by the user that alters the VDB in some external way, such as defining a connector or binding that also needs to be present in the local execution management view, or adding/removing a model to the VDB that involves validation, building and adding of indexes, adding dependent models, etc. So either editing the XML would have to somehow trigger all this activity and the user responses involved in these side actions, or we'd have to now additionally deal with environments where this file's contents are frequently, i.e., normally, not in sync with the other contents within the VDB. I guess you could boil all that down to the same synchronization issues I mentioned in the paragraph above, but these are some major freaking usability issues.
JDoyle-It seems to me that if we are moving to a world where the server doesn't need the tooling, then our artifacts are going to have to get a lot more user fiiendly, or what a user will be able to accomplish w/o tooling will be very limited. I know that the plan for bindings is to simplyfy to just a name, and I think we should push the rest of the artifacts in the same direction.
>
Thanks,
>
JPAV
>
>
> _______________________________________________ teiid-designer-dev mailing list teiid-designer-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/teiid-designer-dev
14 years, 1 month
Re: [teiid-designer-dev] VDB configuration
by Barry Lafond
I know the current JBoss Tools & Eclipse paradigm is all about hand-editing config files. But I'm not crazy either.
The only "editable" part of our "config" data really boils down to a "name" for each connector.
If/when we get into the "role" management, that will change, but I don't think the the potential complex nature of this would be a candidate for hand-editing.
Barry
----- Original Message -----
From: "Daniel Florian" <dflorian(a)redhat.com>
To: "Ramesh Reddy" <rareddy(a)redhat.com>
Cc: "teiid-designer-dev" <teiid-designer-dev(a)lists.jboss.org>
Sent: Tuesday, March 23, 2010 7:55:54 AM GMT -06:00 US/Canada Central
Subject: Re: [teiid-designer-dev] VDB configuration
I'm not crazy about it. I'm not sure if the typical user of Designer cares about that file or even knows one exists inside a VDB. But you can correct me on that one. It seems silly to have that tab if you can't edit it. And if you do allow editing, as stated below, it complicates the editor quite a bit. Not only the framework to sync editors would be needed, but editor validation and a way for the user to overwrite with an auto-generated file may also be needed. I'm just not sure the cost/benefit is worth it right now.
----- Original Message -----
From: "Ramesh Reddy" <rareddy(a)redhat.com>
To: "John Doyle" <jdoyle(a)redhat.com>
Cc: "teiid-designer-dev" <teiid-designer-dev(a)lists.jboss.org>
Sent: Monday, March 22, 2010 1:41:28 PM GMT -06:00 US/Canada Central
Subject: Re: [teiid-designer-dev] VDB configuration
I like it. The only issue is whether you want to let the users edit it
or not. If you do, then syncing is the issue.
Ramesh..
On Mon, 2010-03-22 at 13:21 -0400, John Doyle wrote:
> I've been working on the VDB UI to stub out the changes for Teiid 7 and wanted to float an idea. How about adding an additional tab to the VDB editor view that showed the configuration.def file in a raw XML view? This seems like a pretty standard eclipse paradigm and I think plays into the way the typical JBoss user expects to interaction with their tools.
>
> ~jd
> _______________________________________________
> teiid-designer-dev mailing list
> teiid-designer-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/teiid-designer-dev
_______________________________________________
teiid-designer-dev mailing list
teiid-designer-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/teiid-designer-dev
_______________________________________________
teiid-designer-dev mailing list
teiid-designer-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/teiid-designer-dev
14 years, 1 month