From c7eaf3c262f322290f6e15959369c14d190bbe09 Mon Sep 17 00:00:00 2001 From: "http://kerravonsen.dreamwidth.org/" Date: Tue, 6 Apr 2010 23:19:18 +0000 Subject: [PATCH] response --- doc/forum/an_alternative_approach_to_structured_data.mdwn | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/doc/forum/an_alternative_approach_to_structured_data.mdwn b/doc/forum/an_alternative_approach_to_structured_data.mdwn index 06c82337a..6e6af8adb 100644 --- a/doc/forum/an_alternative_approach_to_structured_data.mdwn +++ b/doc/forum/an_alternative_approach_to_structured_data.mdwn @@ -20,7 +20,9 @@ I think it could be really powerful and useful, especially if it becomes part of > I agree such a separation makes some sense. But note that the discussion on [[todo/structured_page_data]] > talks about associating data types with fields for a good reason: It's hard to later develop a good UI for -> querying or modifying a page's data if all the data has an implicit type "string". --[[Joey]] +> querying or modifying a page's data if all the data has an implicit type "string". --[[Joey]] + +>> I'm not sure that having an implicit type of "string" is really such a bad thing. After all, Perl itself manages with just string and number, and easily converts from one to the other. Strong typing is generally used to (a) restrict what can be done with the data and/or (b) restrict how the data is input. The latter could be done with some sort of validated form, but that, too, could be decoupled from looking up and returning the value of a field. --[[KathrynAndersen]] ## Second Pass