[Mapbender-dev] GUI elements

Mon May 19 12:18:26 EDT 2008

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

-- 
_______________________________________

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
_______________________________________