unfu~help

Submitted by sad hack on Tue, 2009-07-14 14:29

@@
@@ ========================================================================
@@ ------------------------------------------------------------------------
@@ ________________________________________________________________________
@@ .:....1....:....2....:....3....:....4....:....5....:....6....:....7....:
@@ ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
@@ ------------------------------------------------------------------------
@@ ========================================================================
@@ unfu~help
@@ ========================================================================
@set unfu~()=~`PACK`HELP:[create(unfu~help,10)]
@set unfu~(HELP)=nocommand
@link unfu~(HELP)=unfu~()
@tel unfu~(HELP)=unfu~()
@@
@@ ========================================================================
@@ EMPTY ATTRIBS
&~ unfu~(HELP)=
&CONTENT unfu~(HELP)=
&CONTENT`TEXT unfu~(HELP)=
&CONTENT`TEXT`HELP unfu~(HELP)=
@@
@@ ========================================================================
@@ CREDITS
&~`AUTHOR unfu~(HELP)=Unless otherwise explicitly stated, Trispis is the author of the content management system, heretofore referred to as "unfu~".%r To contact the author, send email to: [lit(nemosolid)][lit(@)][lit(gmail)][lit(.)][lit(com)]%r
&~`AUTHOR2 unfu~(HELP)=Individual content packages, such as this one, are authored by their respective authors. See the individual content package for authorship.
&~`AUTHOR3 unfu~(HELP)=The distribution version of this package (unfu~help) only contains the unfu~ help file(s), written by Trispis; however, it is intended to allow the addition of an unlimited quantity of other help files, most of which are quite likely written by other people.
@@
&~`LICENSE unfu~(HELP)=WARPED~core Softcode and Documentation License. See: unfu~wsdl
@@
@@ ------------------------------------------------------------------------
@describe unfu~(HELP)=The unfu~help package.
@@
@@ ------------------------------------------------------------------------
&CONTENT`TEXT`HELP`UNFU~ unfu~(HELP)=unfu~%runfu~()%r%rSituation Normal All Fouled Up -- SNAFU%runfu~'s intent is to UNdo the "FU" in snafu: unfu~(<this>).%r%rThe command:%r%r[iter(unfu~|returns info about unfu~%runfu~<pack>|returns info about <pack>,align(36 [sub(ifelse(isnum(%1),%1,width(%#)),37)],first(%i0,|),rest(%i0,|)),%r,%r)]%r%rThe function:%r%r[iter(unfu~\(\)|#dbref of unfu~ object%runfu~\(<pack>\)|#dbref of <pack>%runfu~\(<pack>\,<\[path] file\[\, parms]>\)|process <file> from <pack> with optional path and parameters,align(36 [sub(width(%#),37)],first(%i0,|),rest(%i0,|)),%r,%r)%r%rSee also: UNFU~2
@@
&CONTENT`TEXT`HELP`UNFU~2 unfu~(HELP)=unfu~%runfu~ example:%r%r unfu~wsdl wsdl%r%runfu~\(\) examples:%r%r th unfu~\(help\, unfu~\)%r th unfu~\(display\, scroll1\, setr\(f\, width\(\%#\)\)\, unfu~\(help\, unfu~2\, sub\(\%qf\, 9\)\)\, y\)%r th unfu~\(display\, scroll1\, setr\(f\,width\(\%#\)\)\, rest\(unfu~\(help\, unfu~2\, sub\(\%qf\,9\)\)\, \%r\)\, y\)
@@
&CONTENT`TEXT`HELP`UNFU~3 unfu~(HELP)=unfu~%runfu~ syntax conventions:%r%rThere is one premise on which the input syntax of the unfu~() function is based. Specifically, anything returned by the unfu~() function is intended, in some way, to be displayed; whether it be a display of textual material (rules, help files, descriptions, etc.), data structures (properties/stats of players, mobs, weapons, equipment, etc.), packaging frills (borders, layouts, etc.), or otherwise.%r%rSince unfu~() can self-reference (i.e., it can call itself again to package up some other result it returns), <width> is considered a crucial, primary parameter for all packages. And, since not all unfu~ packages will embrace any sort of user input (unrelated to any internal, stored, information), user input is considered secondary to <width>, with all other inputs following thereafter. Thus, for consistency and uniformity among content packs, the preferred organization of input parameters (i.e., if you want to contribute a package feature) is as follows:%r%runfu~(<pack>, <attr>\[, <width>\[, <user input>\]\[, <other, parms>\]\])
@@
@@ Why not have <pack/attrib> as a single input parameter?
@@ Two reasons:
@@
@@ 1. I'm limiting the number of input parameters available to packages to
@@ a total of 8 (one or two of which have been defined above, leaving 6-7
@@ to the package feature's additional needs), so that unfu~ itself has
@@ a limit to what it does, compared to what the package does, and...
@@ 2. I'm reducing and simplifying the initial errorchecking steps which
@@ unfu~ needs to perform at the outset. E.g., a single input parameter is
@@ assumed to be a package name ONLY (rather than a pack/attrib combo which
@@ must be separated out into parts).
@@
@@ The aforementioned points may seem trivial to the casual observer, but
@@ hey... I'm not Linus Torvalds; and at the time of this writing, I'm still
@@ developing this thing solo. (Plus, most experienced softcoders know how
@@ to amplify input parameter capacity by using alternative delimiters
@@ other than the comma, such as: foo|bar|baz as three parms in one.)
@@
@@ Additionally, any input parameters beyond <pack> and <attrib> are
@@ considered optional to unfu~ (that is, they are not required by unfu~,
@@ but may be required by the specific content pack being called;
@@ and if they do exist, regardless of whether they are pack-optional or
@@ otherwise, they should occur in the order specified above: width, user
@@ input, other parms). And, since these are considered optional by unfu~,
@@ well-written packs will embrace assumed defaults (e.g., width(%#) is
@@ the assumed default for the display pack's scroll1 distributed example).
@@
@@ Finally, if the potential for unlimited variations on input seems, at
@@ the outset, to be somewhat intimidating (see my excuses, above), there
@@ is a silver lining: This isn't intended to be called manually each time;
@@ rather, it's intention, like all functions, is to be part of some coded
@@ thing or other where it can be written and debugged ONCE, and used
@@ repeatedly thereafter for variations of conditions or user input.
@@ ------------------------------------------------------------------------
@@ ========================================================================