[Mapbender-dev] GUI elements

[Astrid Emde (WhereGroup)]

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.

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
>>
>>
>
>


-- 


Mit freundlichen Grüßen

Astrid Emde

 ----------------------------------

 Astrid Emde
 WhereGroup GmbH & Co.KG
 Siemensstraße 8
 53121 Bonn
 Germany

 Fon: +49(0)228 90 90 38 - 19
 Fax: +49(0)228 90 90 38 - 11

 astrid.emde at wheregroup.com
 www.wheregroup.com

 Amtsgericht Bonn, HRA 6788
 -------------------------------
 Komplementärin:
 WhereGroup Verwaltungs GmbH
 vertreten durch:
 Arnulf Christl, Olaf Knopp, Peter Stamm
 ---------------------------------------