[Mapbender-dev] GUI elements

Melchior Moos nimix at gmx.net
Mon Jul 7 17:02:31 EDT 2008 

Hi Devs
Let me present a different propose.
What if we add a Module definition file (for the administration 
interface and the update routine) to the modules directory which 
contains the following meta information about the module:
-version (a module version)
-requirements (eg. requires module x version > 1.1)
-default values in table gui_element
-definition which fields of gui_element are editable from admin 
interface (to lock eg. e_element as there is no need for normal users to 
edit that)
-provided element_vars with default values
-a list of files that are part of the module and their checksum to avoid 
manipulation

When I got the idea of the element table right than it should be 
possible to do intended things also with this method without braking old 
configurations.
Some use cases:
- copying modules from one GUI to another would be replaced by loading 
the default module values from the definition file.
- if you want to ship a module to a customer you only need to give him 
the modules directory (than he can load the module from admin interface 
with the default database entries)
- if would be possible to see if someone changed the default values (by 
comparing the values in database with the default ones)
- an update script can update modules in database (if the values are the 
defaults from old release change them to default of new release, this is 
maybe more complicated than in christophs proposal)

Hopefully I don't wraste your time with these 2 cents of mine ;)
Regards,
Melchior

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

More information about the Mapbender_dev mailing list