Primarily because it had the nifty little animation as well as a publish state for the server. In short, I was trying to deviate as little as possible from the WTP version. Three pieces of data (server name, start state, and publish state) was too much to inline into the name.

It was only recently I decided their republish API was crap and all I really liked was the start / stop state. But I still like the animation that lets you know it's still starting... the movement is reassuring and makes you feel like it hasn't just forgotten about you. I'm being 100% serious. I'm not joking or just trying to justify it. There's a reason wtp put it there in the first place.

But at this point it basically goes down to the fact that my server view extensions are not compatible with being the children of several different elements. They are solitary items meant to have a changing object they refer to or work upon. There are not meant to be several instances of each view extension. To put everything into one tree would pretty much mandate I either make several instances of each extension, which just wouldnt work based on the current API.

Add to that I've got a nice list of 35 other 'suggestions' from Max, and packaging to re-add, re-implement the xpath editors, etc, and I call this pretty small on the priority level.

- Rob


On 11/13/06, Marshall Culpepper <marshall.culpepper@jboss.com> wrote:
If the only thing you want to inline into a column is the current Server status, why don't you just include it as part of the label ie....

JBoss 4.0.5.GA [started]
|- Modules


On 11/13/06, Rob Stryker <rob.stryker@jboss.com > wrote:
My point was that before, all they needed was a launch configuration, and it was nice and simple for them. Now they need a view, and that's a pain and cluttering. Two views would just be overkill.

As for why not just have one tree, I tried that months ago as well, however, the fact that I'd like to show whether the server is started or stopped in the same way the Servers View does (in columns), it's impossible to do properly.

The columns mess up the usefullness of the tree. If I have a viewer with 3 columns, and only the left most column has children (who also have children etc), the moment the children expand past the column's width, they get cut off. Thus, the tree becomes useless. In order to see any of the elements, you end up having to expand the column's width, which is just silly.

So instead I settled on two viewers one on top of the other, which I thought was the best possible answer. I've solicited feedback / suggestions before and got minimal input from anyone, so as far as I was concerned, this was the best answer possible.

If I just went with one tree, then the current server state would have to be a child of the server instead of its own column, which may be acceptable but it wasn't what I thought was the most beautiful or intuitive. In this way, the user can see a list of his servers and what state they're in first, and then get more details about whichever he wants. If server state was instead a sub-element in the tree, and hte user had 3 servers declared, then he'd have to expand each of the servers to see which were started or stopped. Then there'd be all the other stuff between server state (such as modules, descriptor xpaths, event log) etc, that it would look horrendous.

Server 1
 | -  State: Started
 | -  Modules
 | -  Event Log
 | -  Descriptor XPaths
 | -  blah blah blah
Server 2
 | -  State: Stopped
 | -  Modules 
 | -  blah blah
Server 3
 | -  State: Starting
 | -  et etc etc

Clearly this isn't optimal to quickly see which servers are started or stopped.

And finally, my server view extension API was written to accept a changing input for the second viewer. It was not written to be a child of several different elements, but rather to be stand-alone elements with a changing input.

Hopefully this gives you some insight into what was going through my tiny programmer mind.

- Rob


On 11/13/06, Max Rydahl Andersen < max.andersen@jboss.com> wrote:
On Mon, 13 Nov 2006 19:09:40 +0100, Rob Stryker < rob.stryker@jboss.com>
wrote:

> Because I was told much earlier that two views is crap, one is ideal.
> Users
> dont want tons of views opened to do somethign that was previously
> controlled by a launch configuration.

the two views argument i understand...so why not just have one tree ?

I don't understand your launch configuration point is for ? We still
have that...

/max

>
> On 11/13/06, Max Rydahl Andersen <max.andersen@jboss.com> wrote:
>>
>> >> #1
>> >> Eclipse WTP has this notion of "Adding an applicaiton" to a server.
>> Does
>> >> this also automatically
>> >> add source lookup to that server ?
>> >
>> >
>> > AFAIK no.. but this is something that might be possible to code in
>> > ourselves
>> > for our adapter (Rob would know for sure)
>>
>> If not, how do they handle the "disable breakpoints" on server feature
>> if
>> they don't somehow get info about the source ?
>> (look in the wtp server preferences)
>>
>> > #2
>> >> We have this splitted jbosserver view with what looks to me a
>> filtered
>> >> WTP
>> >> server view and specific jboss bottm part, correct ?
>> >> Why is there both a mix of jboss inc servers and jboss wtp servers
>> >> visible
>> >> in that one ?
>> >
>> >
>> > Well IMO this should be JBoss servers only as it is the "JBoss Server
>> > View"
>> > ..
>>
>> Why not just reuse the existing WTP view and have the jboss specific
>> things in another view ?
>> (just curious)
>>
>> --
>> --
>> Max Rydahl Andersen
>> callto://max.rydahl.andersen
>>
>> Hibernate
>> max@hibernate.org
>> http://hibernate.org
>>
>> JBoss a division of Red Hat
>> max.andersen@jboss.com
>> _______________________________________________
>> jbosside-dev mailing list
>> jbosside-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jbosside-dev
>>



--
--
Max Rydahl Andersen
callto://max.rydahl.andersen

Hibernate
max@hibernate.org
http://hibernate.org

JBoss a division of Red Hat
max.andersen@jboss.com




--
Marshall Culpepper
marshall.culpepper@jboss.com
JBossIDE Team Lead
JBoss, a division of Red Hat