[Mapbender-dev] GUI elements

Tue May 20 02:21:46 EDT 2008

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

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

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