[teiid-designer-dev] VDB configuration

[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 at 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 at lists.jboss.org https://lists.jboss.org/mailman/listinfo/teiid-designer-dev 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/teiid-designer-dev/attachments/20100323/3c36df51/attachment-0001.html