On Tue, Jan 25, 2011 at 1:56 AM, Matt Neuburg <m...@tidbits.com> wrote:
> This is madlibs; the template string comes from him, the programmer. Only the
> words that go into the blanks come from the user. You'll need to prove to me
> that performing the substitution this way is any more dangerous than
> substituting words from the user into the template string some other way. m.
As I said, just because he writes the template string doesn't mean he
(or his localization author) is immune to accidentally adding an extra
%@ into the file that causes access to random memory. That's an
embarrassing crasher right there that can be avoided with something as
simple as not directly reading format strings from a file.
And in the future, even with a very simple infrastructure, if he
wishes to allow third-party file authorship, then users don't need to
worry about some troll handing them an intentionally malformed file
designed to crash the app, or worse gain elevated privileges or put
the operating system in an unstable state.
A simple plist-based approach using an array of dictionaries would
work. In old ASCII-plist syntax:
(
{
IsBlank=NO;
Text="The quick"
},
{
IsBlank=YES;
Text="(adjective)"
},
{
IsBlank=NO;
Text="fox jumped over the lazy"
},
{
IsBlank=YES;
Text="(noun)"
}
)
For something more complicated, a simple XML format might be appropriate:
<madlib>
The quick <blank type="adjective" /> fox jumped over the lazy <blank
type="noun" />
</madlib>
Especially if you want to share the resulting madlib with other
people, who might then want to reuse the same template. All that
information is contained in a nice compact file format:
<madlib>
The quick <blank type="adjective">brown</blank> fox jumped over the
lazy <blank type="noun">dog</blank>
</madlib>
None of this is all that hard to parse, and increases the robustness
of the app tremendously. This is especially relevant if Jeremy is
merely using MadLibs as an allegory to describe a more complicated
application, like an app that creates and fills out boilerplate legal
documents.
--Kyle Sluder
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
