I am not seeing this behavior in my own application. I checked out from the branch names TURBINE_2_2_BRANCH and the DateStringField does not override the toString() method in that code line. Perhaps I am "barking up the wrong branch." ;-) Thinking this might be the case I also grabbed the HEAD tag to see if it lived there. No such luck. Can you please tell me where I can grab this functionality. It does sound like I would be reinventing the wheel for the most part.

Cheers,
Jake

Quinton McCombs wrote:

There is something close to this for the DateString field. The
toString() method will use the first format rule for the field to format
the date. This is actually in the Fulcrum version which I have just
completed back porting to T2.2.
What would be ideal is one definition (formatter/mask) that is used for
both validation and display. This is what I really like about the way
that the DatString field is implemented. It used the first format mask
for display. You can still have other masks that will allow other
formats for the input.



-----Original Message-----
From: Jake Fear [mailto:[EMAIL PROTECTED]] Sent: Monday, December 23, 2002 2:09 AM
To: Turbine Users List
Subject: Re: turbine 2.2 in CVS


I'm considering adding the capability to specify a formatter for a field. I don't want to dupliate any effort. Can you tell me if anyone else is working on such a feature already? It does not appear like it would be difficult, provided a few assumptions.
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:turbine-user-> [EMAIL PROTECTED]>

For
additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>






--
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]>

Reply via email to