[Mapbender-dev] GUI elements

[Arnulf Christl]

Christoph Baudson wrote:
> How about this motion?
> 
> There have been no votes yet. Let's extend the voting period until July 
> 21st. If no votes have been cast until then, let's abandon the motion.
> 
> With the separation of "gui_element" into "element" and "gui_element" we 
> would have control over the modules delivered with Mapbender. These 
> could be certified modules and their core could not be altered. 
> Mapbender is very error prone because it gives administrators way too 
> much freedom to misconfigure their applications. It would also make 
> updates a lot easier.
> 
> Maybe people were more enthusiastic if we deferred the split into two 
> tables? Maybe we add a read only column, and the read-only column only 
> affects certain columns. Redundant, but people don't seem to like 
> changes. :-)
> 
> I still think it's a necessary step and in my opinion ignoring it is not 
> an option. But please prove me wrong.
> 
> Christoph

+1 Arnulf

> Christoph Baudson schrieb:
>> 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
>>
>>
> 
>