Hi Bob, YES, by all means do move to XML. I think this would be a very important step forward (and my first guess is it would be not too complicated, but you never know...).
I do see how some might be attracted to having an DB storage too, but I would urge you to always have that as an alternative, not as instead-of: keep the main configuration mechanism (XML-)file based! In many use cases there's no need for a DB and that would mean you'd have tho have a DB plus all its hassle, only for the configuration part. Also the current file-base config is ideal in situations were many people need to work on the one MS, such as in our educational setup, where we have many students working on their own config files in their private dirs, and they don't need to touch the 'main' MS setup on the server. Actually, what are your reasons for preferring an SQL sdolution over the file based one...? -- Barend Köbben International Institute for Geo-Information Sciences and Earth Observation (ITC) PO Box 6 7500AA Enschede, The Netherlands +31 (0)53 4874253 On 10-06-08 20:30, "Bob Basques" <[EMAIL PROTECTED]> wrote: > All, > > We've been pondering some sort of alternative to the Mapfiles for a few years > now. A preferable approach would be something that could be stored in a DB in > some fashion for querying/assembly processes. It seems on the surface like a > DB schema could be developed to handle the MapFile storage aspects. > > A first step would be in how to best approach moving into an XML way of life > for the MapFiles. Would it make any sense in the beginning to just build a > MapFile2XML convertor (I would imagine this would be needed before anyone > would sign up for XML) and once something like this is a state close to > production, the innards of MapServer would then be made to parse the XML > directly? > > Another approach might be to do something like MapFile2SQL first, and then the > MapFile2XML. This might save some time and seem like it would make > standardization easier, since it would need to be inside of the DB fist. > > Has anyone tried putting together any requirements list along these lines at > all? Is it going to be something where we just need to jump in and build > something even if it might be a wrong approach to begin with? > > This thread just got me thinking is all . . .you know how dangerous that can > be . . . :c) > > bobb > > > >>>> "Tamas Szekeres" <[EMAIL PROTECTED]> wrote: > Hi, > > MapServer currently doesn`t support any other persitence > representation than the mapfiles. There have been some initial plans > related to an XML format in this list, but no one had any motivation > to implement that. > So I think the best what you can do at the moment is to use reflection > to access the properties along with some other members of the objects > and serialize the values manually. > > Best regards, > > Tamas > > > 2008/6/9 BrainDrain <[EMAIL PROTECTED]>: >> >> Is there any 'standart' fast(!) way/method to serialize (xml/json/other >> markup) mapObj in C#? I need it for using server mapObj as JSON on rich >> client app running on browser. Look at my method (using reflection): >> >> public static ListDictionary PartialSerialize(object instance, Stack >> callerTypes, Type[] excludeTypes) >> { >> ListDictionary result = new ListDictionary(); >> object val; >> >> callerTypes.Push(instance.GetType()); >> PropertyInfo[] pis = instance.GetType().GetProperties(); >> foreach (PropertyInfo pi in pis) >> { >> if (pi.PropertyType.IsSerializable && >> !pi.PropertyType.IsArray) >> result[pi.Name] = pi.GetValue(instance, new object[0]); >> else >> { >> //preventing useless nesting >> if (!callerTypes.Contains(pi.PropertyType) && >> !((IList)excludeTypes).Contains(pi.PropertyType)) >> { >> val = pi.GetValue(instance, new object[0]); >> if (val != null) >> result[pi.Name] = PartialSerialize(val, >> callerTypes, excludeTypes); >> } >> } >> } >> callerTypes.Pop(); >> return result; >> } >> ... >> So I can convert mapObj on serever to hashtable automatically an then >> populate JSON object >> (still need to call explicitly getLayer, getClass etc., but this is not a >> problem): >> ... >> layers[i].Properties = Tools.PartialSerialize(layer, new Stack(), new >> Type[3] { typeof(mapObj), typeof(hashTableObj), typeof(colorObj)}); >> ... >> classes[j].Properties = Tools.PartialSerialize(layerClass, new Stack(), new >> Type[4] { typeof(layerObj), typeof(labelObj), typeof(hashTableObj), >> typeof(colorObj)}); >> ... >> styles[k].Properties = Tools.PartialSerialize(classStyle, new Stack(), new >> Type[2]{typeof(hashTableObj), typeof(colorObj)}); >> ... >> mapStub.Properties = Tools.PartialSerialize(map, new Stack(), new Type[11] { >> typeof(labelObj), typeof(hashTableObj), typeof(fontSetObj), >> typeof(labelCacheObj), typeof(outputFormatObj[]), typeof(queryMapObj), >> typeof(referenceMapObj), typeof(scalebarObj), typeof(symbolSetObj), >> typeof(colorObj), typeof(legendObj)}); >> ... >> JavaScriptSerializer class object allows to perform convertion to client >> More often I use script method in my web service that can do it behind the >> scenes. >> >> How do you do such kind of operation? >> -- >> View this message in context: >> http://www.nabble.com/mapObject-serialization-in-C--%28variant%29-tp17739919p >> 17739919.html >> Sent from the Mapserver - User mailing list archive at Nabble.com. >> >> _______________________________________________ >> mapserver-users mailing list >> mapserver-users@lists.osgeo.org >> http://lists.osgeo.org/mailman/listinfo/mapserver-users >> > _______________________________________________ > mapserver-users mailing list > mapserver-users@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/mapserver-users > _______________________________________________ > mapserver-users mailing list > mapserver-users@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/mapserver-users International Institute for Geo-Information Science and Earth Observation (ITC) Chamber of Commerce: 410 27 560 E-mail disclaimer The information in this e-mail, including any attachments, is intended for the addressee only. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or action in relation to the content of this information is strictly prohibited. If you have received this e-mail by mistake, please delete the message and any attachment and inform the sender by return e-mail. ITC accepts no liability for any error or omission in the message content or for damage of any kind that may arise as a result of e-mail transmission. _______________________________________________ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users