in a class i'm writing i'll most likely have to use NSXMLParser twice to parse two different xml's, and i'm wondering which approach should i use?
- release the parser after it finished parsing url and reinitialize when need to parse the second url?
- use different class as delegate for parsing other url?
- or something else?
thanks
peter
In my own personal experience, I've commonly had to parse several different REST xml responses and for each of them I inherit a base class and create one class per request/response/parse. IMHO although this isn't clean code, I honestly find it impossible to write clean code when dealing with a SAX-style parser.
My advice would be separate calls and perhaps separate classes if you don't want a bunch of if-else's in your code. Now if the XML is very similar, it could be a different story...
I have written a class which implements the parser methods and you just have to pass it a string (your url). It returns with an array of elements. It may be of use to you.
You can download it here: http://www.kieranmcgrady.me/helper-classes-for-parsing-xml-files
In the past I've often made classes to parse each response type that I expected to see, you can reuse an NSXMLParser, but I really haven't seen a need to.
Depending on your requirements you may want to just read the responses into nested NSDictionaries, then deal with accessing the elements that you need directly from the dictionaries.
Related
Because of legacy (unfortunate) reasons, we have the same xml roots for 2 different representations. With xstream, how would we let unmarshaller to use a class we need while unmarshalling.
I am thinking of passing some context (through ThreadContext) so that xstream would use that information to pick the right class during unmarshalling, though I am not sure where to start. Any suggestions are very appreciated.
Notes:
Root tags are same for both XML
No other information (attribute) on root tag is available to distingish 2 representations
Cannot change the xml because of legacy reasons
Ideally I would like the solution to work with Spring-OXM but will take shortcuts if needed
You know in advance which of the two representations you are about to parse.
So you can create two instances of the xStream in the beginning, and configure the converters and aliases differently for each of them, and use one instance per representation.
This approach seems to me cleaner and more controllable than setting a global context variable and then having a bunch of ifs inside the converters, and dealing with potential ambiguities.
I'm looking for an end to end example using dojo.store with dijit.Tree over REST.
There are many existing examples that use the older dojo api, dojo.data.api, but a dearth of ones using the dojo.store api.
Is the reason that dijit.Tree doesn't fully support dojo.store yet?
If so, do I need to use the dojo.data.ObjectStore wrapper to encapsulate dojo.store for use with dijit.tree?
I saw one example of working around this by extending StoreFileCache:
http://dojo-toolkit.33424.n3.nabble.com/New-object-store-and-dijit-Tree-td2680201.html
Is that the recommended option, or should I
a) stick to dojo.data.api until dijit.Tree supports dojo.store directly, or
b) use the dojo.data.ObjectStore wrapper
Thanks
There is now a tutorial on the DTK website that seems to cover pretty much exactly this topic.
http://staging.dojotoolkit.org/documentation/tutorials/1.6/store_driven_tree/
However, as I know linking to something without giving an answer is considered a poor practice, the general idea is that rather than using a dojo.data.ObjectStore to wrap around it and then potentially shoving it through a ForestStoreModel, you can simply augment your dojo.store-based store to add the methods that the Tree will look for. Here's a simple example from the tutorial:
usGov = new dojo.store.JsonRest({
target:"data/",
mayHaveChildren: function(object){
// see if it has a children property
return "children" in object;
},
getChildren: function(object, onComplete, onError){
// retrieve the full copy of the object
this.get(object.id).then(function(fullObject){
// copy to the original object so it has the children array as well.
object.children = fullObject.children;
// now that full object, we should have an array of children
onComplete(fullObject.children);
}, onError);
},
getRoot: function(onItem, onError){
// get the root object, we will do a get() and callback the result
this.get("root").then(onItem, onError);
},
getLabel: function(object){
// just get the name
return object.name;
}
});
It's worth noting that in this case, we're making some assumptions about what the data looks like. You'd need to know how your children relate and customize the methods below for that purpose, but it's hopefully fairly clear as to how to do that for yourself.
You can also just stick to dojo.data APIs for now, but this approach definitely feels more lightweight. It takes a couple of layers out of the stack and working with customizing a dojo.store-based store is much easier.
Given the two options you outlined, I'd say it's a matter of how well you know the different APIs.
dojo.store is more light-weight, and perhaps easier to understand, but the wrapper adds some overhead. If you think your project will live for a long time, this is probably the best way to go.
dojo.data is a legacy API, which will phased out eventually. If your project is short-lived, and only based on dijit.Tree, this might be your best option for now.
Personally, I'd go with dojo.store and write my own TreeStoreModel to get the best of both worlds. This approach is very similar to Brian's suggestion.
In case you're interested, I've written up a two-series post on how to use dijit.Tree with the ObjectStore wrapper, and implementing a JsonRest backend in PHP.
I've loaded an XML file as NSData into memory and parse over the elements using NSXMLParser. Although it works, it's a very ugly and hard to maintain code since there are about 150 different elements to parse.
I know there are nice third-party solutions, but I want to keep it with the iPhone SDK for purpose of practice and fun.
So I thought: Why not convert that XML file into an NSDictionary? Having this, I could use fast enumeration to go over the elements.
Or is it just the same amount of ugly code needed to parse and process an XML right away with NSXMLParser?
Would I build up an NSDictionary for every found node in the XML and create a huge one, containing the whole structure and data? Or is there an even simpler way?
NSDictionary cannot read any random xml format. It can only read xml in a specific format which is the plist format.
The plist actually predates xml and the current plist format is just an xml version of the original. The name plist is a contraction of "property list" as the files define the properties of an instance of a class. Therefore, all the xml tags in the file must define elements of an instance of class that implements the NSCoder protocol.
So, yes, if you start with arbitrary xml you must laboriously parse it to convert it into an NSDictionary or some other class.
I wouldn't bother writing a parser from scratch for any reason except as a learning exercise. Every single xml format requires a different parser. It's better to use an existing parser so that 80% of the work is done for you. In a real project, you will end up doing that anyway.
There are many parsers there (e.g. XPathQuery, TouchXML etc.).
Hi dontWatchMyProfile,
You should better user NSString XML format. For this format, I have a little lib converting easily
http://bcaccinolo.wordpress.com/2010/11/14/xml-to-nsdictionary-converter/
I hope it might help.
Cheers,
Benoit
i've not tested this code yet.
http://troybrant.net/blog/2010/09/simple-xml-to-nsdictionary-converter/
We seems to be abstracting a lot of logic way from web pages and creating "helper" classes. Sadly, these classes are all sounding the same, e.g
ADHelper, (Active Directory)
AuthenicationHelper,
SharePointHelper
Do other people have a large number of classes with this naming convention?
I would say that it qualifies as a code smell, but remember that a code smell doesn't necessarily spell trouble. It is something you should look into and then decide if it is okay.
Having said that I personally find that a name like that adds very little value and because it is so generic the type may easily become a bucket of non-related utility methods. I.e. a helper class may turn into a Large Class, which is one of the common code smells.
If possible I suggest finding a type name that more closely describes what the methods do. Of course this may prompt additional helper classes, but as long as their names are helpful I don't mind the numbers.
Some time ago I came across a class called XmlHelper during a code review. It had a number of methods that obviously all had to do with Xml. However, it wasn't clear from the type name what the methods had in common (aside from being Xml-related). It turned out that some of the methods were formatting Xml and others were parsing Xml. So IMO the class should have been split in two or more parts with more specific names.
As always, it depends on the context.
When you work with your own API I would definitely consider it a code smell, because FooHelper indicates that it operates on Foo, but the behavior would most likely belong directly on the Foo class.
However, when you work with existing APIs (such as types in the BCL), you can't change the implementation, so extension methods become one of the ways to address shortcomings in the original API. You could choose to names such classes FooHelper just as well as FooExtension. It's equally smelly (or not).
Depends on the actual content of the classes.
If a huge amount of actual business logic/business rules are in the helper classes, then I would say yes.
If the classes are really just helpers that can be used in other enterprise applications (re-use in the absolute sense of the word -- not copy then customize), then I would say the helpers aren't a code smell.
It is an interesting point, if a word becomes 'boilerplate' in names then its probably a bit whiffy - if not quite a real smell. Perhaps using a 'Helper' folder and then allowing it to appear in the namespace keeps its use without overusing the word?
Application.Helper.SharePoint
Application.Helper.Authentication
and so on
In many cases, I use classes ending with Helper for static classes containing extension methods. Doesn't seem smelly to me. You can't put them into a non-static class, and the class itself does not matter, so Helper is fine, I think. Users of such a class won't see the class name anyway.
The .NET Framework does this as well (for example in the LogicalTreeHelper class from WPF, which just has a few static (non-extension) methods).
Ask yourself if the code would be better if the code in your helper class would be refactored to "real" classes, i.e. objects that fit into your class hierarchy. Code has to be somewhere, and if you can't make out a class/object where it really belongs to, like simple helper functions (hence "Helper"), you should be fine.
I wouldn't say that it is a code smell. In ASP.NET MVC it is quite common.
I am wrapping up an application where I am using a lot of Dictionary classes to store Function and Action delegates. I am now refactoring my project a bit and cleaning code. My question is where do or would you put your Dictionary classes in your project structure? Right now, they are located within the calling class source files but I was wondering if I should create a separate source file to store all my Dictionaries. I hope this is enough information. Please forgive me if it is not. Thanks.
I would organize the dictionaries in the same way as the rest of the code; group related functionality together, and separate unrelated functionality.
In addition, I'd look at how the delegation dictionaries are used. If your usage pattern is always to retrieve a delegate and immediately invoke it, then I'd wrap that behavior into a class with a "do-the-right-thing" method. Then each such class can be named by the domain concept it represents.
For example, if you had a dictionary which mapped US state abbreviations to a sales tax calculation, then you could wrap all of that into a class with a "compute sales tax" method taking a state code and subtotal as arguments. The fact that it's using a dictionary to look up the right computation scheme then becomes a hidden implementation detail.
Normally, the Dictionary class would be a thing unto itself (a library) and your various users would create instances of it.
If need be, they might specialize / sub-class it, but this should be rare.
Maybe the question you really should be asking yourself "why do I have multiple Dictionary classes"?