>

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.

>

>

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

>