]
Max Rydahl Andersen commented on JBIDE-10550:
---------------------------------------------
For me this is not really solving anything IMO - it is a fourth dumping ground of
settings.
We already got the server editor which is and always will be the primary location for
settings as long as that is where Eclipse WTP has its settings. Adding more pages to this
is better IMO than moving it to server properties.
Beyond that there is the launch configuration page/dialog which can and does have settings
already related to launches.
And finally we have global server/runtime settings like classpath/file xpath setup in the
Preferences.
For me it feels like the underlying API/code is being used to drive the UI instead of
looking at how the UI should look like and then do the proper mapping/setup in what fits
an API behind the scenes.
About your specific mentioned "new comers"
"expose management port?" - if you by this mean which url and port to use for
doing management operations? then you already have a Ports section, but you also in this
need eventually to support setting the host used to connect for this and thinking about it
this makes more sense together with admin username/password settings...in short - its too
spread out now and the new setup continues that (bad) trend.
"for openshift, automatically git-add new files before commit?" - I do not see
this as a server specific setting - this is something handled at publish time and could
just as well be a global behavior.
Similar the "pattern for restart" could also be global IMO, but if it should be
added to the server then this seem to fit into "Publishing" section. Can we
edit/add to that ?
On the topic of using Properties view then that I agree should not be a primary UI for
configuring these things but it could be used as an alternative for getting an overview
for certain parts of the UI which might be showing on separate pages.
It's worth mentioning that the UI element that disturbs me the most is the
non-intuitive "Server State Detectors". i.e. what does "JBoss 7 Manager
Service" tell the user ? would it not make more sense this was called "Ping
Management API" for start and "Attempt graceful shutdown" for Stop and then
dependent on the server this was either handled via JMX or AS7 Management API ?
And the title of that section should be more like the others, i.e. "Server State
Detection" instead of "Detectors"....actually - "server" is a
redundant word in our sections now that I look at it.
Similar - "Timeout" is a bit weird since it afaik mean "just wait some
random seconds without actually doing anything" ... and afaik there are timeouts in
place for all the the other options - what is so special about this one ? The UI does not
tell.
"Web Port" could also be more less "low level" - maybe "Ping
Web"?
Now trying toggling all these I'm considering if there shouldn't be a label
beneath these choices explaining what the current selected option does?
About "ports" then couldn't these be split into a "Web" and
"Management" section which for "Web" could have the Port and possibly
an option for enabling for AS7 the "recompile .jsp on save" and then
"Management" could have host/port and username/password settings tied together
?
[UI][Usability] Streamline UI for server editor and all possible
options
------------------------------------------------------------------------
Key: JBIDE-10550
URL:
https://issues.jboss.org/browse/JBIDE-10550
Project: Tools (JBoss Tools)
Issue Type: Task
Components: JBossAS/Servers
Affects Versions: 3.3.0.M5
Reporter: Rob Stryker
Assignee: Rob Stryker
Fix For: 3.3.0.Beta1
Attachments: JBIDE-10550_empty_editor.png, serverUIasProperties.png
The Server Editor has often been called "too busy" with unrelated settings
populating it in a rather disorganized fashion. Less-often used settings, such as which
pollers to use, or manually setting ports, have often been suggested that they be hidden a
bit so as not to distract users.
With several jiras open for adding additional settings (ex: expose management port? or,
for openshift, automatically git-add new files before commit?), simply throwing them into
the Server Editor would only serve to clutter it further. A uniform UI with a real design
and intuitive location for new settings should be created, with clear outlines for what
belongs in the server editor (very little) vs what is a more advanced setting and can be
hidden (though still not too far... user should not need to go 'DIG' to find it).
Currently, there are 4 key sections: Pollers, Ports, Credentials, and
"Behaviour" (or mode... local vs rse). But, in recent builds, the
"Behaviour" section has received several checkboxes that have more to do with
launching, such as binding to all interfaces, or the server being remotely controlled and
thus a dummy adapter. Other options, like the possibility of restarting a module on .class
changes, have no obvious place to live, and, if added today, would most likely be added in
the "Behaviour" section, which seems like it does not belong there. Also, an
option like exposing the management port on launch would probably similarly be placed in
this section, bringing the number of options for "Behaviour" to 4.
This of course seems very wrong to me.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: