[Thuban-devel] Re: RfD: Support for layer specific resources

[Bernhard Herzog]

Martin Schulze <joey at infodrom.org> writes:

> If dialogs should not be opened multiple times, they need to be named
> and inserted into the dialog list.  My idea is that when dialog
> creation is handled globally there needs to be a global logic for
> naming dialogs.

I don't think this is necessary in the current stage of Thuban's
development, but it shouldn't hurt to establish some policy in this
area.

For some non-modal dialogs it is desirable that only one instance is
shown.  This could be one instance globally or one instance per
e.g. session or layer.  The mainwindow does this by determining a unique
name for a dialog based on the kind of dialog and the objects it depends
on.  For instance the name of the layer properties dialog contains the
id of the layer object.  If the dialog is to be opened, the mainwindow
uses its name to determine whether it is alrady open and only needs to
be raised to the top or whether it has to be instantiated yet.

The naming of standard dialogs is an implementation detail of the
mainwindow.  The only case in which code outside of the mainwindow needs
to come up with a layer name is when it calls the OpenOrRaiseDialog
directly.  This will only be necessary for non-standard dialogs where
the mainwindow can't determine the dialog class to use on its own.  In
such cases, you should use a name that contains a dot (".") and does not
start with the string "Thuban.".

For extensions it's a good idea to use the extension name as a prefix,
e.g. "Extensions.myextension.server_config".


>> > we will probably handle show_table
>> > and information similar to the properties dialog.
>> 
>> Why do we need layer specific dialogs for show table?  It may be
>> necessary to make the existing code more flexible, so that it works for
>> layers that are not sub-classes of Layer among others, but that
>> shouldn't require different dialogs.
>
> Maybe there is no need for different show table dialogs at the
> moment.  I can't guarantee that there won't be one in the future.

Well, I can't guarantee it either, but I still don't think that we'll
need it.  The show table show tha tabular data associated with a layer.
That tabular data is given as an object implementing the table
interface.  Now, I can think of cases where the current dialog may not
be exactly right -- the table may need to contain as yet unsupported
types of data, for instance -- but in such cases it's better to extend
the current dialog and perhaps the table or layer interface.

So, the flexibility we need for the layer property dialog is already
provided for in the case of the table dialog through the table objects.

> Hence, I would rather like to implement a general solution which could
> be used for other instances of the same problem class as well.
>
>> > Apart from that, this method is executed quite often.  We would
>> > probably create a reasonable delay if it would be implemented that
>> > way.  In order to avoid this, I propose a hierarchical data structure
>> > for layer_dialogs.py (attached).
>> 
>> Well, the way you wrote the function, it returns the wrong results (see
>> below) in some cases and probably isn't all that much faster.  Anyway, I
>> don't think we need the hierarchical approach yet.  If the lookup is too
>> slow there are lots of ways in can be made faster.  E.g. instead of
>> doing a linear search each time, we could build a dictionary on demand
>> mapping layer classes to the appropriate dialog classes.
>
> ok.
>
> Is the attached patch better?

Yes.

> --- Extensions/wms/properties.py	15 Apr 2004 16:14:51 -0000	1.1
> +++ Extensions/wms/properties.py	9 Jun 2004 15:30:45 -0000
> @@ -72,7 +72,7 @@
>      Representation for the WMS properties dialog
>      """
>  
> -    def __init__(self, parent, name, layer):
> +    def __init__(self, parent, name, layer, group = None):

I don't think we should have to add the group parameter to all layer
property dialogs.  See below.

> --- Thuban/UI/mainwindow.py	18 Apr 2004 20:37:01 -0000	1.132
> +++ Thuban/UI/mainwindow.py	9 Jun 2004 15:30:54 -0000
[...]
> @@ -705,14 +742,18 @@
>          self.OpenLayerProperties(layer)
>  
>      def OpenLayerProperties(self, layer, group = None):

We should get rid of this group parameter and replace it with a more
generic **kw which are simply passed through to OpenOrRaiseDialog.  This
parameter is currently only provided by the legend and only makes sense
for layers which have a classification.  The code in legend.py probably
needs to become a little smarter for this (pass the group argument as a
keyword argument and only pass it for layers with classifications).


> _layer_dialogs = {}
>
>
> def add_layer_dialog(type, layer_class, dialog_class):
>     try:
>         _layer_dialogs[type].append((layer_class, dialog_class))
>     except KeyError:
>         _layer_dialogs[type] = [(layer_class, dialog_class)]
>     
>
> def init_layer_dialogs(type):
>     try:
>         del _layer_dialogs[type][:]
>     except KeyError:
>         pass
>
>
> def has_layer_dialog(type, layer_class):
>     for cls, dialog_class in _layer_dialogs[type]:
>         if cls == layer_class:
>             return True
>     return False
>
>
> def get_layer_dialog_class(type, layer):
>     for layer_class, dialog_class in _layer_dialogs['properties']:
>         if isinstance(layer, layer_class):
>             return dialog_class
>     return None
>
>
> def get_layer_properties_class(layer):
>     return get_layer_dialog_class('properties', layer)


I'd prefer a different approach for different types of dialogs.  There
should be one class that implements the mapping from class instances to
the objects associated with classes (in this case from layer instances
to the property dialog classes).  There would be one instance for the
layer property dialogs and one for the renderers.  If we need more layer
type specific things we can create more instances.

   Bernhard

-- 
Intevation GmbH                                 http://intevation.de/
Skencil                                http://sketch.sourceforge.net/
Thuban                                  http://thuban.intevation.org/