The 5.3 version of tapestry-bootstrap is in maven central but I'm not really working on it anymore. At first I was just going to drop the project since Tapestry 5.4 converted to Bootstrap but I've found I need various add-ons which I think will be useful to others. For example I have components/mixins for all the Bootstrap javascript components. I'm using it on a project I'm converting to 5.4 and when I'm finished I'll push it up to GitHub.
On Wed, Sep 18, 2013 at 8:54 PM, Lenny Primak <[email protected]>wrote: > 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] > >
