Greetings, I just stumbled upon the 1.4 Preferences class and its subclass AbstractPreferences. I like the scenario. But here are some questions for the kind souls who are familiar with this stuff: - would it be appropriate to call (the implemented) method exportNode() from within the (to be implemented) method flushSpi()? - how come that importPreferences() is implemented in the Preferences class itself, while exportPreferences() is implemented in the subclass AbstractPreferences()? As you'd probably noticed, Sun's Javadocs are puzzling me here on this subject. All I want to do/have, is a working Preferences subclass that allows me to add/delete/read preference values in a conforming way. Any ideas, tip, hints, anyone? All responses are truly appreciated. kind regards
Anonymous
Ranch Hand
Joined: Nov 22, 2008
Posts: 18944
posted
0
I apologize for 'up-ing' this topic, but it really amazes me that noone aparantly uses this mechanism? kind regards
Jim Yingst
Wanderer
Sheriff
Joined: Jan 30, 2000
Posts: 18652
posted
0
Well, Ranch traffic is usually pretty slow on what is Friday afternoon/evening for those of us in the US. Also I suspect that most people who use Preferences haven't had any need to write their own implementation using AbstractPreferences - we just use the existing implementations. (Preferences.systemRoot(), Preferences.systemNodeForPackage(), etc.) That's true for me anyway. Are you sure that's not sufficient to your needs? You may want to check out this article from our own Thomas Paul for the basics of how to use Preferences (without creating your own implementation). Now if you really need to extends AbstractPreferences - well to be honest I only started using Preferences fairly recently, and never previously looked at AbstractPreferences. But of course I won't let that stop me from looking at the API and offering opinions anyway... - would it be appropriate to call (the implemented) method exportNode() from within the (to be implemented) method flushSpi()? Sounds reasonable to me, if you want to use the standard XML format for your backing store. (Not a requirement, but a reasonable default.) - how come that importPreferences() is implemented in the Preferences class itself, while exportPreferences() is implemented in the subclass AbstractPreferences()? I don't see exportPreferences() at all - but I see exportNode() and exportSubtree(). Which just raises further questions - why aren't the forms symmetric? I think this difference exists because at the time you decide to export, you need to choose whether to export just one Node, or all its subtrees as well. But when you import, you just specify the input stream, and the XML will specify exactly which Node(s) the data are associated with. I guess there's no way to say "import only the parts of this file that refer the system root node" for example - you just import everything in a file, into whatever Node it originally came from. Anyway, that seems to answer my question here (why not symmetric?) - but I still have no idea about the answer to your question (why in different classes?). Maybe someone else can help here.
"I'm not back." - Bill Harding, Twister
Anonymous
Ranch Hand
Joined: Nov 22, 2008
Posts: 18944
posted
0
Jim, thanks a bunch for your reply and the link to the article. After reading this article I came to realize that there is no need for writing my own Preferences implementation; I just missed the description of those static methods in Sun's JavaDocs. All problems solved ... thanks again and kind regards ps. sometimes I hate this catching up on 1.0 -- 1.1 -- 1.2 -- 1.3 -- 1.4 -- 1.5 (coming soon, more work to be done)
0
Maybe someone else can help here.
