[Mapbender-dev] GUI elements

Tue May 20 04:24:07 EDT 2008

Marc Jansen schrieb:
> Hi all,
>
> the proposed changes will influence mapbenders structure heavily... so 
> all of this is due in version 3.0, right?
>
> As for the motion I have some further questions... sorry if they have 
> already been answered previously, I'll vote quickly when everything 
> seems clear to me:
>
> ad 1) I like the motion alot, but does this mean that every 
> "application_element" is inherited from an "element"?

Yes. The columns of gui_element are split into two tables element and 
application element. There is a 1:n relation of element to 
application_element, which means that a single element can exist in n 
configurations.

> Or is it more like: There is a "element" "mapbender_logo" (unique to 
> all applications) another "application_element" 
> "logo_of_certain_application" (unique only within this application). I 
> could modify certain attributes of both fo my application and these 
> changes would then be stored as application_element settings, right?

I think that's not what I meant.

An application would contain application elements only. But these 
application elements are inherited from (globally unique) elements.

Take the logo element for example. The element would contain the columns 
which should be constant (e.g.  JavaScript, elementId etc). 
Application_element would contain the columns which are configurable, 
like position, image src, title etc.

A proposal for the split is here

http://lists.osgeo.org/pipermail/mapbender_dev/2008-April/001137.html

Let's discuss if this is the way to split...on a second thought, "e_url" 
(URL to help site) would better be stored in application_element.

>
> Where would you save the "logo_of_certain_application"? As a new 
> element AND as a new application_element? Sorry, I'm confused

If you wanted to modify the certified logo element which is delivered 
with Mapbender, you would only be able to modify the application element 
settings. So there would be a new entry in application_element only.

If you wanted to generally change the logo element, you would have to 
copy the element and rename it. Then you would deal with a non-certified 
element! This would create a new element, and if you loaded it into an 
application, a new application_element as well.

The main idea is quality control. If you change the "application 
element" settings and the application fails, it's a Mapbender problem. 
If you change the "element" setting and the application fails, it's your 
problem. At the moment we are unable to detect if anyone is toying 
around with the elements that came with the release. It would be nice to 
prevent it in the first place.

You see that it will be easy to automatically update elements that are 
certified. Customized elements (manipulated copies of certified 
elements) will NOT be updated! The user has to update these manually.

It would really make it easy to identify an element. It would consist of 
a set of files (with a checksum for each file):
With the checksum we could identify if the files belong to a certain 
version: when building a release, an automated routine would generate 
checksums for all files. Somewhere we would have a list (XML) of all 
elements with the files they use (including an SQL for element 
creation!). So an element in a certain Mapbender version could be 
described precisely by these files and their checksums. An update 
routine could match these checksums to determine what the status of 
Mapbender is. In other words, we would have sth like module version 
numbers. (You could also easily identify obsolete files too, now you 
can't).

Idea: For creating the dump for the release, we could have another XML 
(created by a Mapbender administration interface), that states which 
application holds which elements + links to SQLs of their 
configurations. The build script would then parse these XMLs and compile 
the dump dynamically. The same could be done for services, i.e. a 
context document storing the whole GUI WMS data.

I'm not sure about calling this 3.0, and what the implications are when 
calling it 3.0. I would just like to have that as soon as possible, 
preferably now, as our GSoC students could work on it. We could maintain 
the old version and slowly build the new one parallel. We could have an 
incubation process for modules to have full quality control. People 
could use this new version (maybe 3.0) although it would only contain a 
single map application and a single administration application, each 
with only a few modules.

I think it's time for another dev sprint :-)

Sorry for my verbosity

Christoph

>
> ad 2) In bundle with 1) this makes perfect sense...
>
> ad 3) I like that a lot, too. but this is certainly a 3.0-thing, isn't 
> it?
>
> Bye,
>
> Marc
>
>
> Christoph Baudson schrieb:
>> Astrid Emde (WhereGroup) schrieb:
>>> Hello devs,
>>>
>>> I second Christophs motion. Let's vote.
>>>
>>> 1.)  +1
>>> 2.) +1
>>> 3. ) I am not sure what this means in detail and how this "light" 
>>> version  could look like. need some more concreate description on this.
>>
>> I think of it as the core. We could take this as an opportunity to 
>> build new application templates. We could start with a single basic 
>> application, and incubate the necessary modules. During incubation we 
>> could also apply more quality control, like code conventions, 
>> updating interfaces or removing redundant code. Incubation would also 
>> include creating a new administration interface (maybe this could be 
>> Len's job).
>>
>> I'm not sure if it's too much but Mapbender has a lot of bloat which 
>> makes it VERY hard to add innovations. By starting a light version we 
>> could get rid of that bloat.
>>
>>>
>>> best regards astrid
>>>
>>> Christoph Baudson schrieb:
>>>> I think it's about time we make a decision
>>>>
>>>> <motion>
>>>> I motion to
>>>>
>>>> 1) split "gui_element" into "element" and "application_element". 
>>>> This implies:
>>>> - "element" is globally unique
>>>> - "application_element" is unique only application-wide (like 
>>>> "gui_element" was)
>>> you have to make sure that every element in table element has an 
>>> entry in table application_element.
>>> e_src - should be part of application_element ( we have to get rid 
>>> of the iframes first)
>>>>
>>>> 2) add a "readonly" column to element. This implies:
>>>> - You can't modify or delete "readonly" elements
>>>> - You can only modify or delete your own elements
>>>> - You can only modify "readonly" elements via "application_element" 
>>>> settings
>>>>
>>>> 3) The above changes have severe consequences. A lot of scripts are 
>>>> affected. My plan would be to set up a "light" version of Mapbender 
>>>> with a single admin and map application, and slowly incubate other 
>>>> modules into this version. Users could still work with the 2.5 
>>>> series while incubation is in progress, but devs (including the 
>>>> GSoC students) could focus on the "light" version.
>>>>
>>>> </motion>
>>>>
>>>> Slimming down Mapbender would have a lot of effects. We could
>>>> - have trouble with a lot of merging
>>>> + get rid of deprecated files
>>>> + reorganise the file system
>>>> + add changes quickly (less files are affected)
>>>> + make it easier for our GSoC students (they could work in a less 
>>>> complicated environment and have clearer tasks)
>>>> + eliminate iframes
>>>> + move SQL statements from dump to modules, and compile the dump 
>>>> with a build process (less error-prone)
>>>>
>>>> This is not a motion that you should nod off with a casual +1. 
>>>> Voting 0 is acceptable yet not helpful. Voting -1 implies you 
>>>> present alternatives or reasons why to stick to the current model.
>>>>
>>>> The only -1 I could think of are insufficient funding and backwards 
>>>> compatibility, yet I see more pros than cons. I see it as an 
>>>> investment that will pay off in the near future.
>>>>
>>>> Please vote +1, 0 or -1, don't be shy to use either option.
>>>>
>>>> Christoph Baudson schrieb:
>>>>> Christoph Baudson schrieb:
>>>>>> In order to enhance the modular character of Mapbender, I propose 
>>>>>> to split the database table gui_element. The problem with the 
>>>>>> current table layout is, that there is no table for "element", 
>>>>>> just gui_element (From now on, whenever I speak of an "element" 
>>>>>> (as in "gui_element") I refer to it as a "module").
>>>>>
>>>>> I think this is a severe change to the concept of application 
>>>>> elements. Formerly, copying an application element has been a copy 
>>>>> "by value", meaning a completely new set of element settings. You 
>>>>> can have two application elements with the same ID that are yet 
>>>>> quite different.
>>>>>
>>>>> The new concept would imply copy "by reference", so altering a 
>>>>> copied element (without changing the id) would result in changing 
>>>>> the original as well. However, this would only be the case for the 
>>>>> element settings, and not the gui_element settings.
>>>>>
>>>>> An example for the new "by reference" logic: There is an element 
>>>>> called "back". You copy it and modify only its "top" and "left" 
>>>>> settings. No problem with the original, as "top" and "left" are 
>>>>> both gui_element settings. Now let's change "HTML-TAG": This would 
>>>>> change the original, as it is an element setting (and not a 
>>>>> gui_element setting).
>>>>>
>>>>> Now let's assume the element back was tagged "read-only". If you 
>>>>> would copy the element, you were to choose if you wanted to use 
>>>>> the original module (and ONLY alter gui_element settings like 
>>>>> "top", copy "by reference"), or if you wanted to create a new 
>>>>> module based on the original, with a new ID (and so being able to 
>>>>> edit the element settings like "HTML-TAG" as well, copy "by value").
>>>>>
>>>>> For read-only elements, "by reference" could be the default copy 
>>>>> option, for other elements "by value".
>>>>>
>>>>> An important issue are element vars. Now we only have 
>>>>> gui_element_vars. Do we still need them? Or is element_var 
>>>>> sufficient? I guess so. Because by altering element vars, you 
>>>>> alter the element itself.
>>>>>
>>>>> The new database structure could look sth like this, let's discuss 
>>>>> it because I'm not 100% sure about some fields:
>>>>>
>>>>> element:
>>>>> e_id
>>>>> e_comment
>>>>> e_element
>>>>> e_src (? - for images it would be better suited in 
>>>>> application_element, but for iframes :-/)
>>>>> e_attributes
>>>>> e_content
>>>>> e_closetag
>>>>> e_js_file
>>>>> e_mb_mod
>>>>> e_target
>>>>> e_requires
>>>>> e_url
>>>>> e_readonly (THIS WOULD BE NEW!)
>>>>>
>>>>> application_element (fka gui_element):
>>>>> fkey_gui_id
>>>>> e_public
>>>>> e_pos
>>>>> e_title
>>>>> e_left
>>>>> e_top
>>>>> e_width
>>>>> e_height
>>>>> e_z_index
>>>>> e_more_styles
>>>>>
>>>>> element_vars (fka gui_element_vars):
>>>>> fkey_e_id
>>>>> var_name
>>>>> var_value
>>>>> context
>>>>> var_type
>>>>>
>>>>> I guess what I really want to say is that the gui_element_id is 
>>>>> not sufficient, we need element_ids for real control over the 
>>>>> modules in Mapbender. Class dismissed...anyone still awake? If 
>>>>> yes, please comment.
>>>>>
>>>>> Christoph
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> So if you have to change a module, the changes do not propagate 
>>>>>> throughout Mapbender. You have to edit the settings in every GUI 
>>>>>> manually, it is harder to track module changes.
>>>>>>
>>>>>> Currently it's not possible to set a version number on a module. 
>>>>>> So you also do not know the compatibility status of a module. 
>>>>>> Some only work with specific versions, for example "set_locale" 
>>>>>> will require Mapbender 2.5, it should not be possible to load it 
>>>>>> in an older Mapbender.
>>>>>>
>>>>>> We need a centralised spot for keeping modules. Like an Eclipse 
>>>>>> update: You open your admin GUI and get a message about new 
>>>>>> available modules. Currently, you can only copy a GUI element 
>>>>>> from another GUI. Imagine, Mapbender could load it from 
>>>>>> mapbender.org. We would have enormous quality control over the 
>>>>>> modules in distributions.
>>>>>>
>>>>>> Another problem is module IDs, the same module can have two IDs 
>>>>>> in two separate GUIs. IDs should be unique at all the time. If a 
>>>>>> user created a new module, we could do a remote check if there 
>>>>>> already is a module by that name.
>>>>>>
>>>>>> Users would also be kept from editing a stable module and by this 
>>>>>> creating their own bastard modules that waste everybody's time.
>>>>>>
>>>>>> For releasing, this approach would also make things easier. You 
>>>>>> could keep the SQL for a module within the file system, and 
>>>>>> construct the SQL data dump with a build process.
>>>>>>
>>>>>> I would like to see this happen this year. Mapbender needs to 
>>>>>> change, things are growing to be more and more complex, yet there 
>>>>>> is no infrastructure. We need less overhead, I don't want to see 
>>>>>> Mapbender dead as a dodo.
>>>>>>
>>>>>> Maybe we can discuss this face-to-face at FOSSGIS, but certainly 
>>>>>> up front here.
>>>>>> _______________________________________________
>>>>>> Mapbender_dev mailing list
>>>>>> Mapbender_dev at lists.osgeo.org
>>>>>> http://lists.osgeo.org/mailman/listinfo/mapbender_dev
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
> _______________________________________________
> Mapbender_dev mailing list
> Mapbender_dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapbender_dev

-- 
_______________________________________

W h e r e G r o u p GmbH & Co. KG

Siemensstraße 8
53121 Bonn
Germany

Christoph Baudson
Anwendungsentwickler

Fon: +49 (0)228 / 90 90 38 - 15
Fax: +49 (0)228 / 90 90 38 - 11
christoph.baudson at wheregroup.com
www.wheregroup.com
Amtsgericht Bonn, HRA 6788
_______________________________________

Komplementärin:
WhereGroup Verwaltungs GmbH
vertreten durch:
Arnulf Christl, Olaf Knopp, Peter Stamm
_______________________________________