Speaking of that, what's the status of tapestry-bootstrap and T5.4?
And also is it in maven central yet?



On Sep 18, 2013, at 7:53 PM, Barry Books <[email protected]> wrote:

> I was planing on using modernizr to detect if type="date" is supported.
> I've also added min and max to the mixin since they are also supported by
> HTML5. I'm sure I'll put in my Bootstrap library and I'll submit it for
> inclusion in 5.4 but it's not at all compatible with the old DateField.
> 
> 
> 
> 
> On Wed, Sep 18, 2013 at 7:12 PM, Geoff Callender <
> [email protected]> wrote:
> 
>> iDevices have their own, great, touch-friendly, date picker for HTML5
>> type="date", so maybe what's needed is to detect the media type before
>> deciding whether to display a JavaScript datepicker.
>> 
>> Similarly, recent releases of Chrome handle type="date" with a pretty good
>> picker, so maybe what's needed is a parameter to declare which browsers to
>> NOT override with our picker.
>> 
>> 
>> 
>> On 19 September 2013 08:24, Barry Books <[email protected]> wrote:
>> 
>>> I started working on this today. Give the HTML5 spec supporting
>> type="date"
>>> I decided to break this into two parts. First I wrote a Translator for
>> the
>>> Date class. This means you can now just use TextField for dates if the
>>> input type is Date. Since the Translator is contributed in the AppModule
>>> you get a consistent date format across all fields. If you want to a
>>> different format you can just supply a different translator to the
>>> textField. Next I'll just create a mixin that adds some javascript to the
>>> field. I suspect I'll just use the jQueryUI one but it should be easy to
>>> swap them since it's a mixin. I'm not sure how general this approach is
>> but
>>> it solves all my problems.
>>> 
>>> FYI: It would be possible to create the Translator on the fly in the
>> mixin
>>> except for two problems.
>>> 1. The Translator has a default which means the mixin cannot do a
>>> BindParameter and set the value
>>> 2. I don't get a form prepare event so I can't set the translator on the
>>> form submit.
>>> 
>>> The Translator is here:
>>> 
>>> public class DateTranslator extends AbstractTranslator<Date> {
>>> 
>>> 
>>> 
>>>                                private final String formatString;
>>> 
>>> 
>>> 
>>>                                public DateTranslator(String format) {
>>> 
>>>                                                super("DateTranslator(" +
>>> format + ")",Date.class,"date");
>>> 
>>>                                                formatString = format;
>>> 
>>>                                }
>>> 
>>> 
>>> 
>>>                                @Override
>>> 
>>>                                public String toClient(Date value) {
>>> 
>>>                                                return new
>>> SimpleDateFormat(formatString).format(value);
>>> 
>>>                                }
>>> 
>>> 
>>> 
>>>                                @Override
>>> 
>>>                                public Date parseClient(Field field,
>> String
>>> clientValue, String message)
>>> 
>>>                                                                throws
>>> ValidationException {
>>> 
>>> 
>>> 
>>>                                                ParsePosition
>> parsePosition
>>> = new ParsePosition(0);
>>> 
>>>                                DateFormat format = new
>>> SimpleDateFormat(formatString);
>>> 
>>>                                format.setLenient(false);
>>> 
>>> 
>>> 
>>>                                Date date =
>>> format.parse(clientValue,parsePosition);
>>> 
>>>                                if ( parsePosition.getIndex() !=
>>> clientValue.length() ) {
>>> 
>>>                                                throw new
>>> ValidationException(message);
>>> 
>>>                                }
>>> 
>>>                                                return date;
>>> 
>>>                                }
>>> 
>>> 
>>> 
>>>                                @Override
>>> 
>>>                                public void render(Field field, String
>>> message, MarkupWriter writer, FormSupport formSupport) {
>>> 
>>> 
>>> writer.attributes("data-format",formatString);
>>> 
>>>                                }
>>> 
>>> 
>>> 
>>> }
>>> 
>>> 
>>> On Tue, Sep 17, 2013 at 11:25 PM, Lenny Primak <[email protected]
>>>> wrote:
>>> 
>>>> Agreed. I will let the dev list know when I will start working on
>>>> datepicker.
>>>> Barry, if you start earlier let me know and we can coordinate efforts.
>> I
>>>> don't want to duplicate efforts. I have never written
>> PropertyEditBlocks
>>>> etc so you may be in a better position to do this.
>>>> 
>>>> What I don't want to do is try to write my own datepicker. We should
>> use
>>>> one of the public ally available ones, I,e, bootstrap of jquery UI one.
>>>> 
>>>> On Sep 17, 2013, at 10:09 PM, Barry Books <[email protected]> wrote:
>>>> 
>>>>> This is high on my list also. I've spent today looking at datepickers
>>> and
>>>>> concluded none of them are perfect and it may be best to just
>> implement
>>>> the
>>>>> one you want and not bother with the Tapestry one. However I do think
>>>>> the TypeCoercer
>>>>> for String to DateFormat needs to be fixed. The current one does not
>> do
>>>>> setLenient(false) which I think is needed no matter what data picker
>> is
>>>>> used and while most Tapestry configuration can be overridden this one
>>>>> cannot. I'll submit a JIRA for this. The fix is easy and even makes
>> the
>>>>> current datepicker better. Here is a description of setLenient:
>>>>> 
>>>>> Specify whether or not date/time parsing is to be lenient. With
>> lenient
>>>>> parsing, the parser may use heuristics to interpret inputs that do
>> not
>>>>> precisely match this object's format. With strict parsing, inputs
>> must
>>>>> match this object's format.
>>>>> 
>>>>> I don't think you want heuristics when validating dates, you want the
>>>>> format to precisely match.
>>>>> 
>>>>> 
>>>>> On Tue, Sep 17, 2013 at 6:04 PM, Lenny Primak <
>> [email protected]
>>>>> wrote:
>>>>> 
>>>>>> High because we have to get this done for 5.4. Probably start with
>>>>>> incorporating the new datefield into FlowLogix though. Not sure
>> patch
>>>> makes
>>>>>> sense in this case though. But I am willing to work on the datefield
>>>>>> modernization.
>>>>>> 
>>>>>> On Sep 16, 2013, at 7:02 PM, Howard Lewis Ship <[email protected]>
>>>> wrote:
>>>>>> 
>>>>>>> What are the chances of a patch?
>>>>>>> 
>>>>>>> I'm stretched really, really thin right now. More so than usual.
>> I'm
>>>>>>> anything but a fan of the built-in DateField component for any
>> number
>>>> of
>>>>>>> reasons, but I can't squeeze blood from a stone.
>>>>>>> 
>>>>>>> 
>>>>>>> On Mon, Sep 16, 2013 at 7:12 PM, Lenny Primak <[email protected]
>>> 
>>>>>> wrote:
>>>>>>> 
>>>>>>>> Just for planning purposes, what are the changes of datepicker
>> being
>>>>>>>> replaced to bootstrap (or any other modern one)
>>>>>>>> prior to T5.4 release?
>>>>>>>> 
>>>>>>>> I need to plan this out, because current T5.4 datepicker is
>> unusable
>>>> for
>>>>>>>> us, so if the new datepicker isn't in the cards,
>>>>>>>> we need to start writing our own datepicker integration.
>>>>>>>> 
>>>>>>>> Thank you.
>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: [email protected]
>>>>>>>> For additional commands, e-mail: [email protected]
>>>>>>> 
>>>>>>> 
>>>>>>> --
>>>>>>> Howard M. Lewis Ship
>>>>>>> 
>>>>>>> Creator of Apache Tapestry
>>>>>>> 
>>>>>>> The source for Tapestry training, mentoring and support. Contact me
>>> to
>>>>>>> learn how I can get you up and productive in Tapestry fast!
>>>>>>> 
>>>>>>> (971) 678-5210
>>>>>>> http://howardlewisship.com
>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: [email protected]
>>>>>> For additional commands, e-mail: [email protected]
>>>> 
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [email protected]
>>>> For additional commands, e-mail: [email protected]
>> 

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to