[Mapbender-dev] GUI elements

[Samson, Marko]

+1 to the elements idea. 


> -----Original Message-----
> From: mapbender_dev-bounces at lists.osgeo.org 
> [mailto:mapbender_dev-bounces at lists.osgeo.org] On Behalf Of 
> Arnulf Christl
> Sent: Monday, July 07, 2008 5:36 PM
> To: Mapbender Developer List
> Subject: 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
>