Pierce Freeman wrote:
A user logs on to a web application. They have some options for
filing a
web report. Choices: single line and multiple line. They can
choose how
many of these fields they have for various variables that they want to
input. This is then saved in a MYSQL database for later use.
The client side application fetches the data in the MYSQL databases
and then
displays it. The problem is that it is a variable number of fields
and a
variable number of types.
This seems like a fairly straightforward data-driven document-
template to me.
If parts of this doesn't exactly match what you have, you'll have to
interpolate or extrapolate, but the basic idea is the same.
A user sets options for filing a web report. These options are
stored in the MySQL database as, say, "1-line" or "n-line", or maybe
"table" if a table is do be displayed. The variable itself is also
identified, along with the presentation option.
The client app fetches the raw data, i.e. "1-line", "n-line", or
"table", for however many items it's supposed to display. It's
unclear whether the number and ordering of displayed items is a user
option, or whether it's controlled by the client app or web app.
It's also unclear if these are all elements the user is supposed to
enter, i.e. a data-entry form, or whether some elements present data
to the user, i.e. data-presentation form, or whether it's a mix.
"Filing a web report" doesn't provide enough detail about the
complete workflow.
Anyway, the client app eventually has a series of presentation
options and variable identifiers (tuples), in the order they're
supposed to be presented to a specific user. It then iterates over
this series of tuples and generates HTML unique to each presentation
option and variable.
For "1-line" it would generate HTML corresponding to a single-line
entry field (<input type="text">) in a data-entry form (HTML <form>
tag). It could use CSS or it could surround this with static HTML
for that element's particular template.
For "n-line", the generated HTML may use <textarea>. And for "table"
it uses some table template. Any of these templates can use any
available HTML feature. Maybe use JavaScript, too.
The basic idea is that a simple user-specified presentation option is
expanded to a chunk of HTML, and the chunk is different for each type
of displayed element and variable name. HTML is defines what is
presented, as opposed to nib-files defining what's presented.
Ultimately, the client app displays the generated HTML in a WebView,
so you can bring the full power of WebKit to the presentation. You
also have the full WebKit DOM available to the client app.
http://developer.apple.com/documentation/AppleApplications/Conceptual/
SafariJSProgTopics/WebKitJavaScript.html
-- GG
_______________________________________________
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
