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
[email protected]
http://lists.osgeo.org/mailman/listinfo/mapbender_dev
_______________________________________________
Mapbender_dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/mapbender_dev
_______________________________________________
Mapbender_dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/mapbender_dev
