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
[email protected]
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 - 15
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
