Re: DateField behaviour when within a zone
On Fri, Dec 14, 2018 at 3:57 AM Christopher Dodunski < chrisfromtapes...@christopher.net.nz> wrote: > Hi Thiago, > Hello, Christopher! > Yes, I'll certainly use your Html5DateField wherever I can, in preference > to the WebFX based DateField component, whenever just a date is required. > Good effort! > Nice! > Indeed, datetime-local is not yet widely implemented in desktop browsers > (seems to work fine in Chrome and Edge, but not IE or Firefox). Indeed. > I think > this should improve with time. The situation with mobile browsers seems > much better. I guess offering Html5 versions of date/datetime fields > keeps Tapestry ahead of the game. Agreed. > More than happy to send you > DateTimeField.java if it might be of interest. > Please do! :) > > Regards, > > Chris. > > > - > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > > -- Thiago
Re: DateField behaviour when within a zone
Hi Thiago, Yes, I'll certainly use your Html5DateField wherever I can, in preference to the WebFX based DateField component, whenever just a date is required. Good effort! Indeed, datetime-local is not yet widely implemented in desktop browsers (seems to work fine in Chrome and Edge, but not IE or Firefox). I think this should improve with time. The situation with mobile browsers seems much better. I guess offering Html5 versions of date/datetime fields keeps Tapestry ahead of the game. More than happy to send you DateTimeField.java if it might be of interest. Regards, Chris. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: DateField behaviour when within a zone
On Tue, Dec 11, 2018 at 8:14 AM Christopher Dodunski < chrisfromtapes...@christopher.net.nz> wrote: > Hi Thiago, > Hello! > Great, I'll take a look. Meanwhile, because of working to a deadline, > last weekend I developed my own, and was just about to offer it to the > Tapestry community. But maybe there's no need now? > > I based it on HTML 5 datetime-local. The various browser implementations > of this element aren't consistently good, but slowly improving. > Awesome! Thanks! Well, take a look at the one I did and let me know whether it's what you need. I tested datetime-local in a couple desktop browsers but I've found it seriously lacking, so I just implemented a component using type="date", which is widely supported. > > Regards, > > Chris. > > > - > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > > -- Thiago
Re: DateField behaviour when within a zone
Hi Thiago, Great, I'll take a look. Meanwhile, because of working to a deadline, last weekend I developed my own, and was just about to offer it to the Tapestry community. But maybe there's no need now? I based it on HTML 5 datetime-local. The various browser implementations of this element aren't consistently good, but slowly improving. Regards, Chris. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: DateField behaviour when within a zone
Hello, Christopher! I got tired of waiting for my bosses and I had to release Tapestry 5.4.4 anyway (see the vote thread on the Tapestry dev mailing list for more details) so I decided to rewrite it from scratch to be included in this release. Please take a look. :) On Thu, Dec 6, 2018 at 9:44 PM Christopher Dodunski < chrisfromtapes...@christopher.net.nz> wrote: > On second thoughts, producing a new DateTimeField component is probably > wiser. > > I'm impressed by the HTML5 "datetime-local" input type. Browsers that > don't support it should gracefully degrade to plain textfield. > > A DateTimeField component based on this HTML5 element would be lighter > weight than the existing DateField component, as there would be no need > for server round trips to wire the field and picker. Dates would be > formatted and parsed on component rendering and submission only. > > What do you think? > > Regards, > > Chris. > > > - > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > > -- Thiago
Re: DateField behaviour when within a zone
I'm still waiting for my bosses to release the Html5DateField we have in our projects . . . On Thu, Dec 6, 2018 at 9:44 PM Christopher Dodunski < chrisfromtapes...@christopher.net.nz> wrote: > On second thoughts, producing a new DateTimeField component is probably > wiser. > > I'm impressed by the HTML5 "datetime-local" input type. Browsers that > don't support it should gracefully degrade to plain textfield. > > A DateTimeField component based on this HTML5 element would be lighter > weight than the existing DateField component, as there would be no need > for server round trips to wire the field and picker. Dates would be > formatted and parsed on component rendering and submission only. > > What do you think? > > Regards, > > Chris. > > > - > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > > -- Thiago
Re: DateField behaviour when within a zone
On second thoughts, producing a new DateTimeField component is probably wiser. I'm impressed by the HTML5 "datetime-local" input type. Browsers that don't support it should gracefully degrade to plain textfield. A DateTimeField component based on this HTML5 element would be lighter weight than the existing DateField component, as there would be no need for server round trips to wire the field and picker. Dates would be formatted and parsed on component rendering and submission only. What do you think? Regards, Chris. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: DateField behaviour when within a zone
Thanks Chris. What puzzled me about the absent closing tag is that it appears in the first example above, but not the second. Yet this markup is generated by the same DateField component (line 276 to be precise: "writer.end()"). I searched the web for alternative 'date pickers'. Bootstrap provides one, and jQuery another. Else Thiago's solution of employing browsers' native datepickers through plain HTML5 may be the better approach. With the improvement in browsers since 2005 - when WebFX DatePicker was the rage - it may be the right time to step away from 3rd party solutions. Thiago, are you happy to release the DateField you wrote? I could look at modifying it to include both date and time, then present it as a complete replacement to Tapestry's DateField. Regards, Chris. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: DateField behaviour when within a zone
Hi
is valid html, while is valid xhtml, so depending on what
you are outputting open may be appropriate.
If the built-in datepicker is giving you grief, roll your own... I find
that we (at work) eventually have had to replace almost all of the slightly
fancy "gui" components in tapestry, while the most basic ones still works
like expected (as browsers / styling frameworks etc. gets better and
requires less server-side interaction, the need for server round trips like
the one you mentioned for the date picker diminishes).
Form fields are matched server-side by the "name" attribute (in the servlet
api).
--
Chris
On Thu, Dec 6, 2018 at 4:02 AM Christopher Dodunski <
chrisfromtapes...@christopher.net.nz> wrote:
> Just a few short questions to help progress with problem solving.
>
> 1) Is there any known reason why DateField's WebFX DatePicker wouldn't
> work within an embedded Tapestry component? I've had no problem with it
> working directly in a Tapestry page. Don't want to be flogging a dead
> horse here. :-)
>
> 2) In the HTML source below, you can see that Tapestry isn't generating
> well-formed markup in the 2nd example (absent closing tags). Is
> this just a red herring?
>
> 3) Despite the DateField tags containing id parameters, could it be that
> these text fields are not discoverable after the server is called to parse
> the date selected using the DatePicker popup?
>
> Again, the datefield itself accepts textual input. Just the DatePicker
> doesn't work.
>
>
> **THIS DATEFIELD'S DATEPICKER WORKS CORRECTLY**
>
> action="/harbour/movement/create.registerform" method="post"
> id="registerForm">
>
> value="K2I7Z6fbINGg1K7hkAtWgn/blEI=:H4sIAJVQu0oDQRS9CRqEIIhPJCgBY7tpTKONiSAWQYRoYze7e92M7M6MMzevxta/8AvE2j6Fnf/gB9haWTibhRg3L4WBYc6cF+fpAxY727AZyTZGKKh8opERHja576MAo+FY6sBhinlNdIgpNKR7FceTGkPu2jtSUlihcc4GktKFlh4a02i5ETeGS3H9UFzrFl5yWcjUIe9JQVqG5yxCgtX6LWuzcshEUG6Q5iI46iqCXJI+qVfbWmMY96rM7OUyg07VtSDz6JRj6JcaSC21f9XPv2+8fo2VuYN7yAzCk4jZ4dX/ho+t0n/2D24+H9+yAF3V2YL1dBj1FIKJay2QPfY1lRWTljpF2En/GtvPb4XoE49+zJaH8KWF5+sS+10opGlS84ALFzU1h+b5BKzF4DxNYrwHxTTJt4Nywcju9Nt9ZeQnifiLOsmZsJ6QNLJx/JrKGnh8A1L3LvkuAwAA"
> name="t:formdata" type="hidden"> name="hidden" type="hidden">
>
>
> Scheduled Time
>
>
> data-format-url="/harbour/movement/create.scheduledtime:format?t:ac=Dashboard"
>
> data-parse-url="/harbour/movement/create.scheduledtime:parse?t:ac=Dashboard"
> data-component-type="core/DateField"> placeholder="scheduled time of movement ("dd mmm
> hh:mm")" data-required-message="You must provide a
> value for Scheduled Time." data-optionality="required"
> data-validation="true" value="" id="scheduledTime"
> name="scheduledTime" class="form-control"
> type="text"> alt="[Show]" class="btn btn-default" type="button"> class="glyphicon
> glyphicon-calendar">
>
>
>
>
>
>
>
> **THIS DATEFIELD'S DATEPICKER FAILS**
>
>
>
> data-validate="submit"
> action="/harbour/dashboard.movementpanel.filterpane.filterform"
> method="post" id="filterForm">
>
> value="Uf5iT4YCrKb6BK/NRv8EvGKwvuI=:H4sIAL2UPWgUQRTHXyJRyGEQQS1sLCIS8SZ3eCdBEQneXRSOVW4vShphdnfusjI7M868TU4EawsbKztBsPOj0MIuRVJIrrBR7AVbQQxYGXDGFS0EuV04m/l+7/ef9x7v2WeYWq9AuUHNaiCpjs4mco0lTKCignHSizky7dYkoQPNTMrRgNGwIHWfUEXDVUaQKmZQ366TUGrG48DOiZLCejGkQ6NYLmmZqlmfYaoeVDZOvZrZ2ZyEiTaUQilQS+7RhCEcbN+ka3SeU9Gf91HHon9uoBCmLbmTkQtJrRWQWh0OhsOX/u7GJMBArZ+EEyNguZTKAcmowLY1mK2Xr2x/mIM72+NHVVc+Pd/pvX73uAjKy4WyCUN75SNF1tIy8d0uushj++Qa5SkrP9x8fw+O7f6qgz8Xt+AuTLi87+k2vbGGo/ZV9eaWDj+9kD8cTuQ0wt7u9abXXclj6ixnirCmWpdb/wm179Ky1+g0G+OF5U3XmcqBLws3ntw/n6XrNFRGQLnBINUY2UJ0zPo/mQE1jCwG9pCG2IoZj7KudXx5q/Tx0Jvvf3Wt39W635F8R2pYUlF1i3nVXdUyZMb4aZDExsRSbL2Iar1vj95mQaoCGVEGE1Emwv3oCELJHTZF9PM3+d04L0d/AJVBrr9eBgAA"
> name="t:formdata" type="hidden">
>
> Start
>
> data-format-url="/harbour/dashboard.movementpanel.filterpane.panestartdate:format?t:ac=movementZone"
>
> data-parse-url="/harbour/dashboard.movementpanel.filterpane.panestartdate:parse?t:ac=movementZone"
> data-component-type="core/DateField"> name="paneStartDate" class="form-control" type="text"> class="input-group-btn">
>
> type="submit">
>
>
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
>
Re: DateField behaviour when within a zone
Just a few short questions to help progress with problem solving. 1) Is there any known reason why DateField's WebFX DatePicker wouldn't work within an embedded Tapestry component? I've had no problem with it working directly in a Tapestry page. Don't want to be flogging a dead horse here. :-) 2) In the HTML source below, you can see that Tapestry isn't generating well-formed markup in the 2nd example (absent closing tags). Is this just a red herring? 3) Despite the DateField tags containing id parameters, could it be that these text fields are not discoverable after the server is called to parse the date selected using the DatePicker popup? Again, the datefield itself accepts textual input. Just the DatePicker doesn't work. **THIS DATEFIELD'S DATEPICKER WORKS CORRECTLY** Scheduled Time **THIS DATEFIELD'S DATEPICKER FAILS** Start - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: DateField behaviour when within a zone
On Sun, Dec 2, 2018 at 10:22 PM Christopher Dodunski < chrisfromtapes...@christopher.net.nz> wrote: > After examining the application's log files I noticed that using the > datepicker resulted in the dashboard page's onActivate() method being > invoked. This was unexpected. > I'm afraid this is actually expected. Any component event will trigger the onActivate() method of its containing page, AJAX ones included. The page should handle its activation context so it's properly initialized for this request. > ... > Suggestion: don't use ActionLink anymore. I'd consider it at least half deprecated, with EventLink being the recommended one. ActionLink is basically an EventLink in which the event name is always "action". Using ActionLink itself isn't a bug at all. Just using something very vintage with corresponding event handler methods with longer names. -- Thiago
Re: DateField behaviour when within a zone
Making some headway...
The base page is "Dashboard", which contains 10 panel components (each
having its own zone). Three of these panels require a "FilterPane" for
limiting the number of records displayed (again, this filter pane has its
own zone). This pane contains a form, and this form contains two
datefields.
After examining the application's log files I noticed that using the
datepicker resulted in the dashboard page's onActivate() method being
invoked. This was unexpected.
03-12-2018 12:02:40 DEBUG Dashboard:74 - [ENTER] onActivate()
03-12-2018 12:02:40 DEBUG Dashboard:193 - onActivate
03-12-2018 12:02:40 INFO Dashboard:202 - User Chris [uid:3] accessed the
dashboard page
03-12-2018 12:02:40 DEBUG Dashboard:154 - [ EXIT] onActivate [null]
The above is the result of simply clicking on a date in the DatePicker popup.
At least part of the problem may be the way I've wired the 10 child panels
to the dashboard page itself (FilterPane is a grandchild).
>From the child template:
...
To the dashboard page class:
public void onActionFromOperationPanel(){
if(!expandedPanel.equals("operationZone")){
operationPanel.expand();
}
else{
operationPanel.collapse();
}
refreshZone("operationZone", operationZone);
}
The child component's actionlink obviously bubbles up to the dashboard
page's onActionFrom...() method. I'm not sure whether this is what's
triggering this page's onActivate() method, but hopefully I'm on the right
track.
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: DateField behaviour when within a zone
On Sun, Dec 2, 2018 at 9:16 AM Christopher Dodunski < chrisfromtapes...@christopher.net.nz> wrote: > > Not all components have that parameter. DatePicker doesn't trigger zone > > refreshes as far as I know. > > According to the Tapestry docs for DateField: > > "One wierd aspect here is that, because client-side JavaScript formatting > and parsing is so limited, we (currently) use Ajax to send the user's > input to the server for parsing (before raising the popup) and formatting > (after closing the popup). Weird and inefficient, but easier than writing > client-side JavaScript for that purpose." > > Seemingly the serverside formatting is failing, and a container's zone is > getting refreshed instead. Yes, DateField uses AJAX, but not zones, so, if a DateField is causing an AJAX update, that's definitely a problem there. > Tomorrow I may delve into how "async=true" > works when zones are nested. I assume nested zones are allowable? > Yes, nested zones are allowed. > > Regards, > > Chris. > > > - > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > > -- Thiago
Re: DateField behaviour when within a zone
>> I imagine others are using the existing DateField with success, whether >> inside or outside of zones. Assuming the DatePicker javascript is using >> AJAX to invoke a zone refresh, is there perhaps a way of disabling this >> without meddling with the code? I had thought that without "async=true", >> components would not invoke zone refreshes. > Not all components have that parameter. DatePicker doesn't trigger zone > refreshes as far as I know. According to the Tapestry docs for DateField: "One wierd aspect here is that, because client-side JavaScript formatting and parsing is so limited, we (currently) use Ajax to send the user's input to the server for parsing (before raising the popup) and formatting (after closing the popup). Weird and inefficient, but easier than writing client-side JavaScript for that purpose." Seemingly the serverside formatting is failing, and a container's zone is getting refreshed instead. Tomorrow I may delve into how "async=true" works when zones are nested. I assume nested zones are allowable? Regards, Chris. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: DateField behaviour when within a zone
On Fri, Nov 30, 2018 at 4:03 AM Christopher Dodunski < chrisfromtapes...@christopher.net.nz> wrote: > That sounds promising Thiago. Does your component support time also, Nope, just date, but it could be copied and adapted to one who accepts time too. > or just date (you mentioned -mm-dd is hardcoded)? > It's hardcoded because that's the format used by the browsers when sending the selected date. The actual format presented to the users is locale-dependent. > I imagine others are using the existing DateField with success, whether > inside or outside of zones. Assuming the DatePicker javascript is using > AJAX to invoke a zone refresh, is there perhaps a way of disabling this > without meddling with the code? I had thought that without "async=true", > components would not invoke zone refreshes. > Not all components have that parameter. DatePicker doesn't trigger zone refreshes as far as I know. > > Regards, > > Chris. > > > - > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > > -- Thiago
Re: DateField behaviour when within a zone
That sounds promising Thiago. Does your component support time also, or just date (you mentioned -mm-dd is hardcoded)? I imagine others are using the existing DateField with success, whether inside or outside of zones. Assuming the DatePicker javascript is using AJAX to invoke a zone refresh, is there perhaps a way of disabling this without meddling with the code? I had thought that without "async=true", components would not invoke zone refreshes. Regards, Chris. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: DateField behaviour when within a zone
Hello! Something I did in my day job was to create an Html5DateField class by copying the DateField sources and removing all the JavaScript from it and also hardcoding the date format to -MM-dd. In addition, instead of outputting , it outputs wrote: > Hi all, > > I've successfully been using the datefield component within a number of > tapestry pages. But now that I've embedded a datefield within a custom > component that is nested within a zone, the datepicker isn't working as it > should. When the datepicker is used to select a certain date, the zone > refreshes but the date remains null. Naturally I would like the date to > reflect that which was chosen, but also there is no need for the zone to > refresh simply because a date in the datepicker was clicked on. So two > wrongs. > > Incidentally, it is possible to manually type a date into the datefield, > just not use the datepicker. And it is not a browser related problem > (tested on Chrome and Firefox). > > > Below are the relevant snippets of markup received by the browser: > > > Start > > data-format-url="/harbour/dashboard.operationpanel.filterpane.panestartdate:format?t:ac=operationZone" > > data-parse-url="/harbour/dashboard.operationpanel.filterpane.panestartdate:parse?t:ac=operationZone" > data-component-type="core/DateField"> > name="paneStartDate" class="form-control" type="text"> > > > > > > > > > > > > > > And, for the sake of comparison, a snippet of the HTML generated by a > Tapestry page, where the datefield works correctly: > > > Start > Time > data-format-url="/harbour/event/create.starttime:format?t:ac=Dashboard/4" > data-parse-url="/harbour/event/create.starttime:parse?t:ac=Dashboard/4" > data-component-type="core/DateField"> > value="" id="startTime" name="startTime" class="form-control" > type="text"> > > > > > > > > > type="submit"> > > Appreciate your help, > > Chris. > > > - > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > > -- Thiago
