The DatePicker anomalies

[Harish Krishnaswamy <hk...@comcast.net>]

The DatePicker is a great component but it has some pitfalls in my opinion.
1. The component does not take advantage of the validator subsystem
2. The positioning of the picker and the button is fixed and out of 
dev-control (the picker display is messed up when it overflows the screen)
3. No control over the style of the button and field (no class attribute 
allowed)

Having faced with these issues, I decided to break it into three 
components (the field, the button and the picker) and now I can have 
complete control over these comonents and the field can also be a 
validating field. I have implemented a prototype and things are working 
fine. The question though is, whether this approach has any pitfalls. 
Please share any questions/concerns you may have.

Thanks
Harish

Re: The DatePicker anomalies

[Eitan Suez <ei...@uptodata.com>]

i couldn't help but comment on this:

  i believe that once msie was a valuable product.
  there's nothing ie does today that mozilla
  can't do (and probably does better).
  furthermore mozilla won't lock you in to an
  os and is open source.

  i urge anyone working on a project to help their
  managers make the right choice:  the notion that
  a company should standardize on msie or force
  its users to use msie in the long term will
  handicap you.

  one of corporate-world's big tenets is
  [supposed to be] embracing change.  let's
  help corporations make the right decisions.

i think i'm preaching to the right crowd here
since you've all embraced tapestry because
it's awesome and open source.


/ eitan


Harish Krishnaswamy wrote:

> Yeah, I remember having read about the z-index problem on this list a 
> while back. Luckily (surprising!) none of my layouts displease IE! But I 
> shall keep that in mind when the problem pops up. Thanks for sharing, Luis.
> 
> -Harish
> 
> Luis Neves wrote:
> 
>> Hi,
>>
>> One of the applications I developed a while ago also suffered from
>> the DatePicker shortcomings you mentioned, plus another (IE
>> gives the highest Z-Index to list boxes, which gives interesting 
>> results if
>> the DatePicker happens to be in vicinity).
>>
>> My solution was similar to yours, I separated the components but
>> instead of using a layer to show the calendar, I used o pop-window.
>>
>> The only shortcoming I noticed in what I did was the slightly bigger
>> delay in the "showing up" of the calendar, but your solution doesn't
>> suffer from this... so I guess you are home free.
>>
>> Best regards,
>> Luis Neves
>>
>>
>> Harish Krishnaswamy wrote:
>>
>>> The DatePicker is a great component but it has some pitfalls in my 
>>> opinion.
>>> 1. The component does not take advantage of the validator subsystem
>>> 2. The positioning of the picker and the button is fixed and out of 
>>> dev-control (the picker display is messed up when it overflows the 
>>> screen)
>>> 3. No control over the style of the button and field (no class 
>>> attribute allowed)
>>>
>>> Having faced with these issues, I decided to break it into three 
>>> components (the field, the button and the picker) and now I can have 
>>> complete control over these comonents and the field can also be a 
>>> validating field. I have implemented a prototype and things are 
>>> working fine. The question though is, whether this approach has any 
>>> pitfalls. Please share any questions/concerns you may have.
>>>
>>> Thanks
>>> Harish 

Re: The DatePicker anomalies

[Harish Krishnaswamy <hk...@comcast.net>]

Yeah, I remember having read about the z-index problem on this list a 
while back. Luckily (surprising!) none of my layouts displease IE! But I 
shall keep that in mind when the problem pops up. Thanks for sharing, Luis.

-Harish

Luis Neves wrote:

> Hi,
>
> One of the applications I developed a while ago also suffered from
> the DatePicker shortcomings you mentioned, plus another (IE
> gives the highest Z-Index to list boxes, which gives interesting 
> results if
> the DatePicker happens to be in vicinity).
>
> My solution was similar to yours, I separated the components but
> instead of using a layer to show the calendar, I used o pop-window.
>
> The only shortcoming I noticed in what I did was the slightly bigger
> delay in the "showing up" of the calendar, but your solution doesn't
> suffer from this... so I guess you are home free.
>
> Best regards,
> Luis Neves
>
>
> Harish Krishnaswamy wrote:
>
>> The DatePicker is a great component but it has some pitfalls in my 
>> opinion.
>> 1. The component does not take advantage of the validator subsystem
>> 2. The positioning of the picker and the button is fixed and out of 
>> dev-control (the picker display is messed up when it overflows the 
>> screen)
>> 3. No control over the style of the button and field (no class 
>> attribute allowed)
>>
>> Having faced with these issues, I decided to break it into three 
>> components (the field, the button and the picker) and now I can have 
>> complete control over these comonents and the field can also be a 
>> validating field. I have implemented a prototype and things are 
>> working fine. The question though is, whether this approach has any 
>> pitfalls. Please share any questions/concerns you may have.
>>
>> Thanks
>> Harish 
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>

Re: The DatePicker anomalies

[Luis Neves <ln...@netcabo.pt>]

Hi,

One of the applications I developed a while ago also suffered from
the DatePicker shortcomings you mentioned, plus another (IE
gives the highest Z-Index to list boxes, which gives interesting results if
the DatePicker happens to be in vicinity).

My solution was similar to yours, I separated the components but
instead of using a layer to show the calendar, I used o pop-window.

The only shortcoming I noticed in what I did was the slightly bigger
delay in the "showing up" of the calendar, but your solution doesn't
suffer from this... so I guess you are home free.

Best regards,
Luis Neves


Harish Krishnaswamy wrote:

> The DatePicker is a great component but it has some pitfalls in my 
> opinion.
> 1. The component does not take advantage of the validator subsystem
> 2. The positioning of the picker and the button is fixed and out of 
> dev-control (the picker display is messed up when it overflows the 
> screen)
> 3. No control over the style of the button and field (no class 
> attribute allowed)
>
> Having faced with these issues, I decided to break it into three 
> components (the field, the button and the picker) and now I can have 
> complete control over these comonents and the field can also be a 
> validating field. I have implemented a prototype and things are 
> working fine. The question though is, whether this approach has any 
> pitfalls. Please share any questions/concerns you may have.
>
> Thanks
> Harish