Yep, one way you get to store local information about your format state, the
other way you get to share a single format object. As I get the feeling you
care more about sharing a single format class then I care about allowing the
format to have state, so I'll fhmp.
Cheers,
Emily
On Wed, Dec 17, 2008 at 7:21 PM, Ray Ryan <rj...@google.com> wrote:
> Who cares? This is happening in response to a user action, and will be
> undetectable. Why would we flush the ability to have shared formats to avoid
> parsing the CSS? We're just talking about a call to
> UIObject#removeStyleDependentName here, right?
> rjrjr
>
>
> On Thu, Dec 18, 2008 at 11:15 AM, Emily Crutcher <e...@google.com> wrote:
>
>> When a default format instance receives a format or parse request, how
>> does it know whether it needs to remove its error style name from that date
>> box other then getting the current css off the date box and parsing it?
>>
>>
>> On Wed, Dec 17, 2008 at 7:09 PM, Ray Ryan <rj...@google.com> wrote:
>>
>>> Nope.
>>> Each formatter *class* can attach dependent styles to a datebox. It
>>> should do so using a naming convention s.t. it can tell styles it has added
>>> from styles that others have added. (This was your concern that lead to the
>>> back pointer, right?)
>>>
>>> When a formatter is removed from a datebox (by a new one being added), it
>>> receives an abandon call to give it a chance clean up any css (or whatever)
>>> that it may have applied that another format will not know how to delete.
>>>
>>> No less efficient, and no need to instantiate a formatter per date box.
>>>
>>> rjrjr
>>>
>>>
>>> On Thu, Dec 18, 2008 at 11:04 AM, Emily Crutcher <e...@google.com> wrote:
>>>
>>>>
>>>>>
>>>>> cal state.
>>>>>
>>>>>
>>>>> You can add an abandon() method to the format lifecycle, to tell it to
>>>>> clean up its crap. To make sure my formatter doesn't interfere with
>>>>> someone
>>>>> else's styling, change the CSS class name for errors to reflect that the
>>>>> formatter owns it, not the DateBox, e.g. DATE_BOX_DEFAULT_FORMAT_ERROR
>>>>>
>>>>>>
>>>> Am I correct that this is your solution?
>>>>
>>>> - Each formatter has its own style name, the expectation is that
>>>> the css for the widget should be dependent upon that stylename and no
>>>> other
>>>> process should use that style name.
>>>> - Whenever the date box's content is parsed or formatted, the date
>>>> box would first call abandon/reset on the formatter. During the
>>>> abandon/reset method, the formatter would access the date box's class
>>>> dom
>>>> property and do a string comparison to see if it had to remove the error
>>>> condition before proceding. Formatters that did not use the css style
>>>> name
>>>> directly to indicate format errors would have to figure out some other
>>>> way
>>>> of clearing any current format state.
>>>>
>>>> I think that would work, but it seems somewhat less efficient then the
>>>> current solution, can you explain a bit more why it is more desirable?
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>
>>>>>>
>>>>>> On 2008/12/17 22:41:41, rjrjr wrote:
>>>>>>
>>>>>>> The dateBox field seems wrong, you don't need the circular
>>>>>>>
>>>>>> relationship btw.
>>>>>>
>>>>>>> DateBox and format. Instead, why don't you pass in the dateBox as a
>>>>>>>
>>>>>> param to
>>>>>>
>>>>>>> format, parse and reset--and allow yourself to share instances? Then
>>>>>>>
>>>>>> you can get
>>>>>>
>>>>>>> rid of this init method entirely.
>>>>>>>
>>>>>>
>>>>>> http://gwt-code-reviews.appspot.com/1201
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> "There are only 10 types of people in the world: Those who understand
>>>> binary, and those who don't"
>>>>
>>>
>>>
>>
>>
>> --
>> "There are only 10 types of people in the world: Those who understand
>> binary, and those who don't"
>>
>
>
--
"There are only 10 types of people in the world: Those who understand
binary, and those who don't"
--~--~---------~--~----~------------~-------~--~----~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~----------~----~----~----~------~----~------~--~---
