[Mapbender-dev] GUI elements

Christoph Baudson christoph.baudson at wheregroup.com
Mon Apr 14 05:20:47 EDT 2008


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



More information about the Mapbender_dev mailing list