1.) There is no need to have several formatters for a field, one should always suffice.
2.) Specifying a formatter is optional.
3.) If a formatter is specified, it will be used in the toString() call of the Field class. If not formatter is specified, the current behavior will be used.
I think this is a good way to remain backward compatible and have minimum impact on the API, while at the same time allow those who want to leverage the solution to do so with little or now code change (they may need to rip out any existing solutions to use this one). The implementation would be similar to that for rules, only significantly simpler. I think this really completes the "Field" abstraction, and simplifies the writing of templates that must deal with dates, currencies and the like.
Cheers,
Jake
Quinton McCombs wrote:
The DTD is out of date.
-----Original Message-----
From: Jake Fear [mailto:[EMAIL PROTECTED]] Sent: Monday, December 23, 2002 1:55 AM
To: Turbine Users List
Subject: turbine 2.2 in CVS
I am building from the 2.2 branch in CVS. Can anyone tell me why the displayName attribute of an intake group does not appear in the intake.dtd? I actually rely on this attribute, and I am concerned it may be removed from future versions of the product. Perhaps it is very new and only appears in the code. In any instance, I have added it myself, and the implementing code seems to work fine.
Jake
--
To unsubscribe, e-mail: <mailto:turbine-user-> [EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
