Page 2 of 4
Re: PrefsObject
Posted: Fri Sep 18, 2015 2:18 am
by mritter0
I am happy to help out with suggestions, but I still need some example code to start with. Could someone post the example(s) on here?
Re: PrefsObject
Posted: Fri Sep 18, 2015 7:12 am
by trixie
salass00 wrote:Currently application.library reads and writes version 1.0 pobjects files but it should be simple enough to make a new version of the library that reads version 1.0 and version 2.0 pobjects file and writes in the latter format only.
I was just going to suggest the same thing!
If you have suggestions on how the new pobjects format should look then please post them here.
Will do.
Re: PrefsObject
Posted: Fri Sep 18, 2015 7:14 am
by trixie
@mritter0
mritter0 wrote:Am I wasting my time using PrefsObject system?
No, the system is cool (though still a little undocumented). It's just the current XML schema that is bad.
I'll send you some code examples when I get to my machine later today.
Re: PrefsObject
Posted: Fri Sep 18, 2015 1:06 pm
by broadblues
salass00 wrote:broadblues wrote:
I wouldn't use it myself, it produces horid unstructured xml, where the only relation between a key and value is that value follows immediatly after the key.
Well if there are problems with the current pobjects format then they can be fixed in application.library.
Currently application.library reads and writes version 1.0 pobjects files but it should be simple enough to make a new version of the library that reads version 1.0 and version 2.0 pobjects file and writes in the latter format only.
If you have suggestions on how the new pobjects format should look then please post them here.
Current:
Code: Select all
<key>Filer.def.dstbackground2pen.r</key>
<string>0xEEEDEEED</string>
This is bad because there is no structure, the only relation between key and string is that string follows key.
Possible improvement:
Key and string now bound together in an item.
Code: Select all
<item>
<key>Filer.def.dstbackground2pen.r</key>
<string>0xEEEDEEED</string>
</item>
alternative.
Code: Select all
<item key="Filer.def.dstbackground2pen.r" type="string" >
0xEEEDEEED
</item>
<item key="Filer.def.search.filename.case" type="bool" >
TRUE
</item>
There are a lot of variations ofcourse, Trixie may have better suggestions still...
Re: PrefsObject
Posted: Fri Sep 18, 2015 3:00 pm
by trixie
@mritter0
I started reworking the PrefsObjects wiki documentation to turn it into something more useful - it's now well overdue! I've covered reading the preferences and added a how-to example code fragment; this should get you started. More information to be added soon I hope:
Link:
http://wiki.amigaos.net/wiki/PrefsObjects
@broadblues
I was actually going to suggest something like you show in that last example.
Re: PrefsObject
Posted: Fri Sep 18, 2015 7:50 pm
by salass00
broadblues wrote:
Code: Select all
<item key="Filer.def.dstbackground2pen.r" type="string" >
0xEEEDEEED
</item>
<item key="Filer.def.search.filename.case" type="bool" >
TRUE
</item>
There are a lot of variations ofcourse, Trixie may have better suggestions still...
How about something like this?
Code: Select all
<string key="Filer.def.dstbackground2pen.r>0xEEEDEEED</string>
<bool key="Filer.def.search.filename.case">TRUE</bool>
Re: PrefsObject
Posted: Sat Sep 19, 2015 10:09 am
by jaokim
Code: Select all
<item key="Filer.def.dstbackground2pen.r" type="string" >
0xEEEDEEED
</item>
<item key="Filer.def.search.filename.case" type="bool" >
TRUE
</item>
Code: Select all
<string key="Filer.def.dstbackground2pen.r>0xEEEDEEED</string>
<bool key="Filer.def.search.filename.case">TRUE</bool>
I'd prefer the first option over the second, since with a general <item> structure it'd be very easy to f.i. create a general GUI that can edit all items, using a fallback text gadget, whereas with the type defining in the tag, you'd have to support all possible types in order to parse the file. I'm also assuming that the "type" attribute could be something application specific, like type="email" allowing the application to validate it, whereas application.library would only treat it as text.
Re: PrefsObject
Posted: Sat Sep 19, 2015 10:27 am
by trixie
jaokim wrote:I'd prefer the first option over the second
On the other hand, Chris' suggestion looks much more human-readable, so if we are to arrive at a compromise between "easy to parse" and "easy to read and edit manually", I'd probably go with something like that. And from the viewpoint of the parser, I guess there's not much difference between handling six different elements (there are six types of PrefsObject) and six different attributes - you need to process them anyway.
Re: PrefsObject
Posted: Sat Sep 19, 2015 11:37 am
by salass00
jaokim wrote:
I'd prefer the first option over the second, since with a general <item> structure it'd be very easy to f.i. create a general GUI that can edit all items, using a fallback text gadget, whereas with the type defining in the tag, you'd have to support all possible types in order to parse the file. I'm also assuming that the "type" attribute could be something application specific, like type="email" allowing the application to validate it, whereas application.library would only treat it as text.
As I see it this won't be a problem since only application.library should be used for parsing these files.
I haven't looked at the code but I would assume that the PrefsObjectsEditor also uses application.library to read and write the pobjects files.
Re: PrefsObject
Posted: Sat Sep 19, 2015 2:04 pm
by broadblues
salass00 wrote:
How about something like this?
Code: Select all
<string key="Filer.def.dstbackground2pen.r>0xEEEDEEED</string>
<bool key="Filer.def.search.filename.case">TRUE</bool>
Well I'm not keen on that format. My objection to the original was lack of structure. The point of using xml in the first place (IMHO at least) is to export data in a structured way, other wise you might as wel use plain text.
My second format adds structure:
Dictionary->Item in dictionary->Key and type information->data.
Whilst it's a slight improvement on the original your suggestion doesn't really add much in the way structure, although the data and key is at least bound togther.
If you want to use tags to define the datatype (that can make parsing slightly easier internally) then how about.
Code: Select all
<pobjects version="2.0">
<dict>
<item key="itemone">
<bool>FALSE</bool>
</item>
<item key="itemtwo">
<string>This is the winter of our discontent</string>
</item>
</dict>
</pobject>