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 <[EMAIL PROTECTED]> > An: Mapbender Developer List <[email protected]> > 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 > >>>>>>>> [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 -- GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen! Jetzt dabei sein: http://www.shortview.de/[EMAIL PROTECTED] _______________________________________________ Mapbender_dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/mapbender_dev
