Hi,
in our current new data tree we have no visible way to
show which resources and datastores are in trouble,
meaning they are in a state that cannot be used.
The simple example is the misconfigured datastore,
or the proper configured one that cannot connect
to its backend (dbms down for example).
How do you think we should handle that? Talking with
Rolando we considered a few possibilities:
* red mark decorators on the icons, a la Eclipse.
Nice effect, implementation is not exactly trivial,
but doable. Would also call for an icon explosion
unless we do add the decoration by dong some
image ops using the base icons and one that does
contain only the red marker)
* a separate ajax pageable list below the tree table
that explicitly list the resources that are failing,
maybe collapsed under a link saying "xxx nodes in error"
and expanding when you click on it
* same as above, but instead of expanding in place,
pop up a dialog with the same table
One drawback of this kind of error reporting is that
we have to scan the whole catalog in order to provide
it, so it won't scale very well. On the other side,
that's exactly what we're doing nowadays anyways,
scannign the whole catalog in order to build the
green/red/gray status bars.
Related to this we have the feedback for the auto
configure button, which should try to auto
configure a resource. Rolando suggested to try to
autoconfigure, and if it fails decorate the nodes
that failed with a marker, not in the icon, but after the
name (aligned right in the same column).
Seems like a good idea to me, and hovering on top of the
icon one would get the error message that prevented
the full auto-configuration.
Opinions?
Cheers
Andrea
Andrea Aime wrote:
Hi,
in our current new data tree we have no visible way to
show which resources and datastores are in trouble,
meaning they are in a state that cannot be used.
The simple example is the misconfigured datastore,
or the proper configured one that cannot connect
to its backend (dbms down for example).
How do you think we should handle that? Talking with
Rolando we considered a few possibilities:
* red mark decorators on the icons, a la Eclipse.
Nice effect, implementation is not exactly trivial,
but doable. Would also call for an icon explosion
unless we do add the decoration by dong some
image ops using the base icons and one that does
contain only the red marker)
* a separate ajax pageable list below the tree table
that explicitly list the resources that are failing,
maybe collapsed under a link saying "xxx nodes in error"
and expanding when you click on it
* same as above, but instead of expanding in place,
pop up a dialog with the same table
I think I like the icon decorator. Its the same deal as eclipse does errors and I think it works well. I believe udig does this too.
One drawback of this kind of error reporting is that
we have to scan the whole catalog in order to provide
it, so it won't scale very well. On the other side,
that's exactly what we're doing nowadays anyways,
scannign the whole catalog in order to build the
green/red/gray status bars.
The StoreInfo interface has a getError()/setError(). The point of this method is to track when a store has a problem. Could we use this as an alternativ to scanning the entire catalog. Basically anytime ResourcePool tries to connect to a store using a StoreInfo it would store the error that occurs (if it does) in this property. If no error occurs it clears the property.
Related to this we have the feedback for the auto
configure button, which should try to auto
configure a resource. Rolando suggested to try to
autoconfigure, and if it fails decorate the nodes
that failed with a marker, not in the icon, but after the
name (aligned right in the same column).
Seems like a good idea to me, and hovering on top of the
icon one would get the error message that prevented
the full auto-configuration.
Opinions?
Cheers
Andrea
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
!DSPAM:4007,48651f4c211821804284693!
--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com
Justin Deoliveira ha scritto:
...
I think I like the icon decorator. Its the same deal as eclipse does errors and I think it works well. I believe udig does this too.
Ok. Rolando, do you think you can make me a decorating icon?
(just the red marker alone, I believe I can compose the full icon
at runtime, if it's too hard, I'll ask you for the fully decorated
icons)
One drawback of this kind of error reporting is that
we have to scan the whole catalog in order to provide
it, so it won't scale very well. On the other side,
that's exactly what we're doing nowadays anyways,
scannign the whole catalog in order to build the
green/red/gray status bars.
The StoreInfo interface has a getError()/setError(). The point of this method is to track when a store has a problem. Could we use this as an alternativ to scanning the entire catalog. Basically anytime ResourcePool tries to connect to a store using a StoreInfo it would store the error that occurs (if it does) in this property. If no error occurs it clears the property.
Ok, so to make sure I would still have to try and connect to the
datastore and then check for error message. Like, I cannot be sure
an attempt to connect already occurred? (or can I?)
Cheers
Andrea
Ok, so to make sure I would still have to try and connect to the
datastore and then check for error message. Like, I cannot be sure
an attempt to connect already occurred? (or can I?)
Well I was more thinking that if getError() was non-null you would mark it was an error. Then if say the user changes a parameter you then try again (ie, call getDataStore()). Under the hood the resorucePool would then re-connect and clear the error if the connection was successul. Then I guess you would have to update the icon.
Cheers
Andrea
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
!DSPAM:4007,4865277d228261431913854!
--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com
On Friday 27 June 2008 08:22:19 pm Justin Deoliveira wrote:
> Ok, so to make sure I would still have to try and connect to the
> datastore and then check for error message. Like, I cannot be sure
> an attempt to connect already occurred? (or can I?)
Well I was more thinking that if getError() was non-null you would mark
it was an error. Then if say the user changes a parameter you then try
again (ie, call getDataStore()). Under the hood the resorucePool would
then re-connect and clear the error if the connection was successul.
Then I guess you would have to update the icon.
I beleave at the time of writing the datastore configuration page I didn't
know the datastore shall be acquired through StoreInfo.getDataStore and hence
I'm using DataStoreFinder directly with the Map of parameters set in the
form.
This missunderstanding may lead to conflicts in the intended workflow. For
instance, I seem to remember wasn't able to edit the configuration for a
datastore that became invalid (say, wrong server ip or whatever avoids from
connecting to the backend), so there may not be a way to edit datastore
parameters when they're invalid...
It seems to be the datastore page should only deal with StoreInfo and avoid
accessing the actual DataStore as much as possible, or at least let
StoreInfo.getDataStore() to lazily do it, right?
That's one thing that should be fixed I guess.
Gabriel
> Cheers
> Andrea
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel