FW: [Mapbender-dev] GUI elements

[Samson, Marko]

Mail lost in space?
Once again ....

 
-----Original Message-----
From: Samson, Marko 
Sent: Tuesday, July 08, 2008 9:15 AM
To: 'Mapbender Developer List'
Subject: RE: [Mapbender-dev] GUI elements

+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
>