> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Arnulf Christl > Sent: Thursday, May 31, 2007 1:50 PM > To: Discussion of Mapbender Development > Subject: [Mapbender-dev] Cleaning up the SQL database > > Hi, > I propose to change our way to manage SQL data in Mapbender. > > There are two different kinds > * Service data (WMS, WFS) > * GUI element data (code, module, position, content, element > variables, etc.) > > == Service Data == > This is a hot topic when updating. Currently we have a fixed > ID that is generated by the development server's sequence. > This is horror for people who maintain a large number of WMS > and have them organized in GUI. Currently every time > Mapbender is updated we get load-errors because of > constraints on the WMS ID or - even worse - we mess up the > client's repository and bound GUIs. >
Why don't we reduce the 'basic' services to 'Demis World Map', 'Jpl World Map', 'Germany' and 'MB Users' (for example) and just offer a list of other services-links at the wiki. So everyone can add services and delete obsoleted links. These basic-services could be offerd with a 'Basic Services' insertscript, for people who need a basic installation for testing mapbender or whatever. That would simplify to handle a effective list of services and updating the database, too. > == GUI element data == > GUI element data comes in two variants: > # template GUI (currently gui, gui1, etc.) # as an "SQL > template" to be used to update private GUI. > > In the second case it is required to add the GUI name to any > update scripts. Potentially we do not need to do this because > people can first update gui and gui1 and then copy from those > GUIs. (There was a separate discussion to rename gui and gui1 > into template_gui or template_basic_gui, etc.) > > Some Mapbender functionality needs several modules. Therefore > sometimes in the Wiki we name the function as the code, > sometimes we invent a new name. Example: > * http://www.mapbender.org/index.php/AddWMS (simple) > * http://www.mapbender.org/index.php/MonitorCapabilities (many) > > Another background is maintainability of the SQL. Currently > keeping the dump up to date is painful and error prone. My > hope is that if we split the large SQL chunk up into little > pieces it will help maintenance because then the developer of > the corresponding module also maintains the SQL snippet. The > snippets are stored using the SVN which will also enhance > updating for professional users and will allow us to have > regular auto-builds over night so that the dev server is > always up to date. I like the method of copying from one 'basic_gui'. /*now brainstormingmode*/ On the other hand, it would be nice to have a little function to insert a new module/element into a specified gui. If we have splitted SQL for every element, we could create a mod_insertelementintodesiredgui script much easier. Perhaps it would be possible to create it with help of the sql-snippets and auto-builds from svn, to have a generated xml file, or something like that, with all single element-sqls ordered by the element names. (something like: <element name='logout'> <module_name>mod_logout</module_name> <functionality>Ends this session.</functionality> <insertsql>INSERT INTO gui_element(fkey_gui_id, e_id, e_pos, e_public, e_comment, e_element, e_src, e_attributes, e_left, e_top, e_width, e_height, e_z_index, e_more_styles, e_content, e_closetag, e_js_file, e_mb_mod, e_target, e_requires) VALUES($Request['desiredgui'], 'logout', '2', '1', 'Logout', 'img', '../img/button_gray/logout_off.png', 'onClick="window.location.href=''../php/mod_logout.php?sessionID''" border=''0'' onmouseover=''this.src="../img/button_gray/logout_over.png"'' onmouseout=''this.src="../img/button_gray/logout_off.png"'' title="Logout"', '660', '10', '24', '24', '1', '', '', '', '', '', '', ''); INSERT INTO gui_element_vars(fkey_gui_id, fkey_e_id, var_name, var_value, context, var_type) VALUES($Request['desiredgui'], 'logout', 'logout_location', '', 'webside to show after logout' ,'php_var'); </insertsql> <dependencies></dependencies> </element> <element name='nextone'> . . . ) So the script could parse the generated-file and offer the elements at the new installation-form, where the user just has to select the desired element and to insert his desired gui. Would this (builing a file(xml for example) from svn-sqlsnippets) even possible with auto-build svn functionality? I don't know! So far, enough storm across my brain now.;-) What do you think about it? Sadly, I can't join you today at IRC-Meeting! cu, Marko > > This needs a lot more thought as it will even tie back into > packaging, install scripts, etc. Potentially this is better > done in the Wiki once we know what we are talking about. Feel > free to start this as a new page or tie it to a Trac ticket. > > Regards, Arnulf. > _______________________________________________ > 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
