[Mapbender-dev] GUI elements

Thu May 8 06:38:26 EDT 2008

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)

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

-- 
_______________________________________

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
_______________________________________