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.
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
[email protected]
http://lists.osgeo.org/mailman/listinfo/mapbender_dev
--
Mit freundlichen Grüßen
Astrid Emde
----------------------------------
Astrid Emde
WhereGroup GmbH & Co.KG
Siemensstraße 8
53121 Bonn
Germany
Fon: +49(0)228 90 90 38 - 19
Fax: +49(0)228 90 90 38 - 11
[EMAIL PROTECTED]
www.wheregroup.com
Amtsgericht Bonn, HRA 6788
-------------------------------
Komplementärin:
WhereGroup Verwaltungs GmbH
vertreten durch:
Arnulf Christl, Olaf Knopp, Peter Stamm
---------------------------------------
_______________________________________________
Mapbender_dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/mapbender_dev
