I've got a list of 2000+, almost the same, 'NSString' attributes I need to "import" in my .xcdatamodel-file.
If I could open the xcdatamodel-file using an XML-like-text-editor, like a .plist-file, I can add all of my attributes, but I can't find a way how.
I managed to programmaticly create the attributes (using this tutorial), but then I can't set or fetch the attribute's data.
The list should look like:
["str_1_1"],["str_1_2"],["str_1_3"],...,["str_49_4"],["str_49_5"],...
Is there a way to programmaticly add attributes / set and fetch data from attributes?
OR
Is there a way to staticly add all possible attributes without clicking the +button over 2000 times?
You can just open the model file in any text editor. If you have the file compatibility for the file set to Xcode 4 or higher, it's even easy to edit.
The model Foo.xcdatamodel is actually a directory. Inside that is a file named contents, which is nicely formatted, easily readable XML. Edit that. A string attribute will look something like:
<attribute name="stringAttribute" optional="YES" attributeType="String" syncable="YES"/>
Add one or two string attributes in Xcode and then duplicate/edit them as needed.
A couple of notes:
Obviously, it's your job to get the syntax right. This is not documented but also not hard to figure out. If you end up with a broken model file that won't compile, you got something wrong.
It's probably a good idea to quit Xcode first. It might not freak out if you edit the model file while it's running, but you never know.
Having 2000+ string attributes is frankly terrifying and suggests an extremely bad data model. Before editing the model and adding all of these, please carefully consider whether there's a less extreme solution.
Related
Using XMLProvider from the FSharp.Data package like:
type internal MyProvider = XmlProvider<Sample = "C:\test.xml">
The test.xml file contains a total of 151,838 lines which makes up 15 types.
Working in the same project as the type declaration MyProvider is a pain, as it seems the XmlProvider is triggered everytime I hit CTRL+SPACE (Edit.CompleteWord) - and therefore regenerates all the models, which can take up to 10sec.
Is there any known work around, or setting to cache the generated models from XmlProvider?
I'm afraid F# Data does not currently have any caching mechanism for the inferred schema. It sounds like something that should not be too hard to add - if anyone is interested in contributing, please open an issue on GitHub to start the discussion!
My recommendation for the time being would be to try to simplify the sample XML, so that it is shorter and contains just a few representative records of all the different kinds.
I have an XML file in my app resources folder. I am trying to update that file with new dictionaries dynamically. In other words I am trying to edit an existing XML file to add new keys and values to it.
First of all can we edit a static XML file and add new dictionary with keys and values to it. What is the best way to do this.
In general, you can read an XML file into a document object (choose your language), use methods to modify it (add your new dictionary), and (re-)write it back out to either the original XML file, or a new one.
That's straightforward ... just roll up the ol' sleeves and code it up.
The real problem comes in with formatting in the XML file before and after said additions.
If you are going to 'unix diff' the XML file before and after, then order is important. Some standard XML processors do better with order than others.
If the order changes behind the scenes, and is gratuitously propagated into your output file, you lose standard diffing advantages, such as some gui differs, and some scm diffs (svn, cvs, etc.).
For example, browse to:
Order of XML attributes after DOM processing
They discuss that DOM loses order where SAX does not.
You can also write a custom XML 'diff'er (there may be such off-the-shelf ... for example check out 'http://diffxml.sourceforge.net/') that compares 2 XML documents tag-by-tag, attribute-by-attribute, etc.
Perhaps some standard XML-related tool such as XSLT will allow you to keep the formatting constant without changing tag or attribute order. You'd have to research that.
BTW, a related problem is the config (.ini) file problem ... many common processors flippantly announce that the write-order may not agree with the read-order.
I'm using:
Rails 3.2x
Spree 1.2
Ruby 1.9.3x
I'm trying to edit the title of one of my pages, and I cannot find where it is getting defined. It is showing up in my base ERB file as 'title', but that name is sufficiently generic to make it next to impossible to find where it is defined.
I have prodded everywhere I can think, I've tried searching for "title =", but nothing is working. I tried calling source_location on it, but that appears to only work on methods.
Any tricks for finding where a variable is defined?
I can't think of an elegant way. A dumb-but-probably-effective way would be to dump stack trace in your erb, then see what those locations are doing and if title is defined there. It has to enter somewhere between the start of program and invoking your erb.
When I can't find something, I use grep -ri some_string . at the command-line to recursively search all the content of the directory.
It's also a good tactic to let your editor search all the source code, since the ones worth using have the ability to search through all files in a directory.
it is created from a mixture of product names, a site config, and something else
An alternate trick is to add a HTML-comment section in your ERB file, and put the pertinent information for the components used to create the title into that section. Then, let the pages be generated and look inside the page's content to determine what table and row ID it is, the site_config filename, etc.
You really should be able to figure it out based on the parts that are concatenated to build the title and then search your database or files. That information isn't magically created out of thin air by Rails; Someone had to tell Rails how to define the title. But, people move on, or they don't document correctly, so try the embedded information trick.
I have a database which I want to export as an iOS compatible PLIST.
The work around I have come up with is to create a calculated field which adds the tagged padding and header and creates a report using these fields. I then export the preview of the report as a PDF, open the PDF in Acrobat Reader, select all text, copy and paste into XCode which recognises the PLIST format and all works as expected.
Is there a better way of doing this? (This seems a really convoluted way of doing things, high chance of error, etc.) The Export as XML option looks promising but I can't seem to join the dots.
Two ways that I can think of to do what you're trying to do. The most elegant way is probably the XML with XSLT export which you suggest. If you don't already know XSLT, though, you might try the following -- it sounds like with the calculated XML line you've already created, like this would be a simple change to your database:
Create a single new global field, say outputXML
Create a script, say plistCreator
In the plistCreator script:
Set outputXML to ""
Go to the first record you want to export
Loop through every record putting your calculated XML line into outputXML (set field outputXML to outputXML & ΒΆ & calculatedXMLLine)
Go to next record, exit after last
Export Field Contents (note that this is a different command than Export) for outputXML
The cleanest solution is to use the export XML with an XSLT for transforming the output. You'll need to know a little XSLT to do this, or at least be able to customize the examples from FileMaker.
I've got a bunch of data loaded into a TClientDataset, representing an array of complex objects. But when I try to run
Dataset.SaveToFile('c:\test.xml', dfXMLUTF8);
it doesn't like it:
Project testing.exe raised exception class EDBClient with message 'Fieldtype not supported for XML.'.
This is a lot less useful than it should be, for two reasons. First off, it doesn't say which field or which field type isn't supported, and second, the actual saving is taking place inside a black-box DLL.
The only field types I'm using in this dataset are integers, strings, booleans, and a few TArrayFields that hold arrays of integer fields. Nothing I'd expect to be all that difficult to serialize. Anyone have any idea why this isn't working?
Is everything saved or just some fields? Maybe for example TArrayFields are throwing an exception? Try removing different fieldtypes one-by-one and see when things start working.
Wild guess is that array fields are not supported in XML export,
but you should check.
Go to Project options->Compiler and turn on "Use debug DCUs". Rebuild.
Set breakpoint on your SaveToFile() call. Run.
Then you can step into VCL source and try to hunt for what is unsupported.