[Mapbender-dev] GUI elements

Thomas Baschetti Thomas.Baschetti at gmx.de
Mon Jul 7 11:39:20 EDT 2008


as i can't really estimate all implications of this

+0 from me

bye
Thomas
-------- Original-Nachricht --------
> Datum: Mon, 07 Jul 2008 17:35:56 +0200
> Von: Arnulf Christl <arnulf.christl at wheregroup.com>
> An: Mapbender Developer List <mapbender_dev at lists.osgeo.org>
> Betreff: Re: [Mapbender-dev] GUI elements

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

-- 
GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen!
Jetzt dabei sein: http://www.shortview.de/wasistshortview.php?mc=sv_ext_mf@gmx


More information about the Mapbender_dev mailing list