[jira] [Commented] (TAP5-2211) Replace DatePicker with Bootstrap or JQueryUI DatePicker
[ https://issues.apache.org/jira/browse/TAP5-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17735452#comment-17735452 ] Lenny Primak commented on TAP5-2211: Hi, Thiago :) > Replace DatePicker with Bootstrap or JQueryUI DatePicker > > > Key: TAP5-2211 > URL: https://issues.apache.org/jira/browse/TAP5-2211 > Project: Tapestry 5 > Issue Type: Improvement > Components: tapestry-core >Affects Versions: 5.4 >Reporter: Lenny Primak >Priority: Major > Labels: datefield, datepicker > > The current 3rd party datepicker used by Tapestry is very old, > and isn't very good. It's time to update it to one of > the better currently-available datepickers. > There are about 15 unresolved issues opened against Datepicker that can all > be solved by just replacing it. > I suggest JQueryUI datepicker (if JQuery is included as the default stack) > The current datepicker can be left alone is prototype is chosen. > By default, JQueryUI datepicker should be used with the button-to-activate > option so that it looks similar to the current datepicker. > It should also work properly in BeanEditor and friends and even look good > with form-horizontal version of BeanEditor > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (TAP5-2211) Replace DatePicker with Bootstrap or JQueryUI DatePicker
[ https://issues.apache.org/jira/browse/TAP5-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lenny Primak closed TAP5-2211. -- Resolution: Abandoned > Replace DatePicker with Bootstrap or JQueryUI DatePicker > > > Key: TAP5-2211 > URL: https://issues.apache.org/jira/browse/TAP5-2211 > Project: Tapestry 5 > Issue Type: Improvement > Components: tapestry-core >Affects Versions: 5.4 >Reporter: Lenny Primak >Priority: Major > Labels: datefield, datepicker > > The current 3rd party datepicker used by Tapestry is very old, > and isn't very good. It's time to update it to one of > the better currently-available datepickers. > There are about 15 unresolved issues opened against Datepicker that can all > be solved by just replacing it. > I suggest JQueryUI datepicker (if JQuery is included as the default stack) > The current datepicker can be left alone is prototype is chosen. > By default, JQueryUI datepicker should be used with the button-to-activate > option so that it looks similar to the current datepicker. > It should also work properly in BeanEditor and friends and even look good > with form-horizontal version of BeanEditor > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (TAP5-1634) Grid, inPlace Update and expired Sessions - Redirect to Login
[
https://issues.apache.org/jira/browse/TAP5-1634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lenny Primak closed TAP5-1634.
--
Resolution: Abandoned
> Grid, inPlace Update and expired Sessions - Redirect to Login
> -
>
> Key: TAP5-1634
> URL: https://issues.apache.org/jira/browse/TAP5-1634
> Project: Tapestry 5
> Issue Type: Improvement
> Components: tapestry-core
>Affects Versions: 5.3, 5.4
>Reporter: Lenny Primak
>Priority: Minor
>
> I have a basic Grid pulling data from an Entity bean. inPlace = true.
> Obviously, when session expires, I get the "there is no data to display"
> message.
> What I really want to do is to redirect to the current page, so the user gets
> to relogin and session
> gets re-established.
> Here's what I tried:
>@SuppressWarnings("unused")
>@OnEvent(value="inplaceUpdate", component="usersGrid")
>private Object ajaxPageChanged()
>{
>if(request.getSession(false) != null)
>{
>return null;
>}
>else
>{
> return ps.createPageRenderLink(LoginPage.class).;
>}
>}
> I get an exception:
> Caused by: java.lang.IllegalArgumentException: Event 'inplaceupdate' from
> test/TapPage:usersgrid.pager received an event handler method return value of
> /com.bettaway_baw-website_war_1.2/loginpage. This type of event does not
> support return values from event handler methods.
> at
> org.apache.tapestry5.internal.util.NotificationEventCallback.handleResult(NotificationEventCallback.java:39)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (TAP5-2211) Replace DatePicker with Bootstrap or JQueryUI DatePicker
[ https://issues.apache.org/jira/browse/TAP5-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17735352#comment-17735352 ] Lenny Primak commented on TAP5-2211: No longer using Tapestry > Replace DatePicker with Bootstrap or JQueryUI DatePicker > > > Key: TAP5-2211 > URL: https://issues.apache.org/jira/browse/TAP5-2211 > Project: Tapestry 5 > Issue Type: Improvement > Components: tapestry-core >Affects Versions: 5.4 >Reporter: Lenny Primak >Priority: Major > Labels: datefield, datepicker > > The current 3rd party datepicker used by Tapestry is very old, > and isn't very good. It's time to update it to one of > the better currently-available datepickers. > There are about 15 unresolved issues opened against Datepicker that can all > be solved by just replacing it. > I suggest JQueryUI datepicker (if JQuery is included as the default stack) > The current datepicker can be left alone is prototype is chosen. > By default, JQueryUI datepicker should be used with the button-to-activate > option so that it looks similar to the current datepicker. > It should also work properly in BeanEditor and friends and even look good > with form-horizontal version of BeanEditor > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (TAP5-1634) Grid, inPlace Update and expired Sessions - Redirect to Login
[
https://issues.apache.org/jira/browse/TAP5-1634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17735351#comment-17735351
]
Lenny Primak commented on TAP5-1634:
No longer using Tapestry
> Grid, inPlace Update and expired Sessions - Redirect to Login
> -
>
> Key: TAP5-1634
> URL: https://issues.apache.org/jira/browse/TAP5-1634
> Project: Tapestry 5
> Issue Type: Improvement
> Components: tapestry-core
>Affects Versions: 5.3, 5.4
>Reporter: Lenny Primak
>Priority: Minor
>
> I have a basic Grid pulling data from an Entity bean. inPlace = true.
> Obviously, when session expires, I get the "there is no data to display"
> message.
> What I really want to do is to redirect to the current page, so the user gets
> to relogin and session
> gets re-established.
> Here's what I tried:
>@SuppressWarnings("unused")
>@OnEvent(value="inplaceUpdate", component="usersGrid")
>private Object ajaxPageChanged()
>{
>if(request.getSession(false) != null)
>{
>return null;
>}
>else
>{
> return ps.createPageRenderLink(LoginPage.class).;
>}
>}
> I get an exception:
> Caused by: java.lang.IllegalArgumentException: Event 'inplaceupdate' from
> test/TapPage:usersgrid.pager received an event handler method return value of
> /com.bettaway_baw-website_war_1.2/loginpage. This type of event does not
> support return values from event handler methods.
> at
> org.apache.tapestry5.internal.util.NotificationEventCallback.handleResult(NotificationEventCallback.java:39)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (TAP5-1661) Grid inPlace=true - Gracedul degradation with JavaScript disabled
[ https://issues.apache.org/jira/browse/TAP5-1661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15185194#comment-15185194 ] Lenny Primak commented on TAP5-1661: I no longer use Tapestry, and cannot verify this issue Sorry > Grid inPlace=true - Gracedul degradation with JavaScript disabled > - > > Key: TAP5-1661 > URL: https://issues.apache.org/jira/browse/TAP5-1661 > Project: Tapestry 5 > Issue Type: Improvement > Components: tapestry-core >Affects Versions: 5.3, 5.4, 5.2 >Reporter: Lenny Primak >Priority: Minor > > When JavaScript is disabled on the browser, > Grid inPlace="true" pager will not function. > It should gracefully degrade and still function with JavaScript disabled, > as if inPlace was set to false. > I realize this is difficult to do because its really not detectable if JS is > enabled on the server side. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TAP5-1973) :443 added to URLs when using the Link.toAbsoluteURI(true)
[
https://issues.apache.org/jira/browse/TAP5-1973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14083199#comment-14083199
]
Lenny Primak commented on TAP5-1973:
Also, take a look at my comment from 21/Oct/12 23:26
When running behind Apache/mod_jk, port is 8009, so that's why
this bug manifests itself with this setup.
> :443 added to URLs when using the Link.toAbsoluteURI(true)
> --
>
> Key: TAP5-1973
> URL: https://issues.apache.org/jira/browse/TAP5-1973
> Project: Tapestry 5
> Issue Type: Bug
> Components: tapestry-core
>Affects Versions: 5.3.4, 5.4
>Reporter: Howard M. Lewis Ship
>Assignee: Howard M. Lewis Ship
> Labels: fixed-in-5.4-js-rewrite
> Fix For: 5.3.5, 5.4
>
>
> An error in the code means that when secure is true and the port is set to
> 443, then ":443" is appended:
> int port = secure ? secureHostPort : hostPort;
> String portSuffix = "";
> if (port <= 0) {
> port = request.getServerPort();
> int schemeDefaultPort = request.isSecure() ? 443 : 80;
> portSuffix = port == schemeDefaultPort ? "" : ":" + port;
> }
> else if (secure && port != 443) portSuffix = ":" + port;
> else if (port != 80) portSuffix = ":" + port;
>
> String hostname = "".equals(this.hostname) ? request.getServerName()
> : this.hostname.startsWith("$") ? System.getenv(this.hostname.substring(1)) :
> this.hostname;
>
> return String.format("%s://%s%s", secure ? "https" : "http",
> hostname, portSuffix);
> secure == true && port != 443 is false, so
> port != 80 is evaluated, it true, so
> ":443" is appended.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TAP5-1973) :443 added to URLs when using the Link.toAbsoluteURI(true)
[
https://issues.apache.org/jira/browse/TAP5-1973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14083187#comment-14083187
]
Lenny Primak commented on TAP5-1973:
As far as I know the bug still exists, as commented by Alejandro.
He also has a good test for this
That's why I reopened it.
This is exposed when running behind apache / mod_jk combination
> :443 added to URLs when using the Link.toAbsoluteURI(true)
> --
>
> Key: TAP5-1973
> URL: https://issues.apache.org/jira/browse/TAP5-1973
> Project: Tapestry 5
> Issue Type: Bug
> Components: tapestry-core
>Affects Versions: 5.3.4, 5.4
>Reporter: Howard M. Lewis Ship
>Assignee: Kalle Korhonen
> Labels: fixed-in-5.4-js-rewrite
> Fix For: 5.3.5, 5.4
>
>
> An error in the code means that when secure is true and the port is set to
> 443, then ":443" is appended:
> int port = secure ? secureHostPort : hostPort;
> String portSuffix = "";
> if (port <= 0) {
> port = request.getServerPort();
> int schemeDefaultPort = request.isSecure() ? 443 : 80;
> portSuffix = port == schemeDefaultPort ? "" : ":" + port;
> }
> else if (secure && port != 443) portSuffix = ":" + port;
> else if (port != 80) portSuffix = ":" + port;
>
> String hostname = "".equals(this.hostname) ? request.getServerName()
> : this.hostname.startsWith("$") ? System.getenv(this.hostname.substring(1)) :
> this.hostname;
>
> return String.format("%s://%s%s", secure ? "https" : "http",
> hostname, portSuffix);
> secure == true && port != 443 is false, so
> port != 80 is evaluated, it true, so
> ":443" is appended.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TAP5-2170) constructAssetPath() requires use of internal service
[ https://issues.apache.org/jira/browse/TAP5-2170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14082718#comment-14082718 ] Lenny Primak commented on TAP5-2170: Perhaps there should be some kind of migration document that includes this > constructAssetPath() requires use of internal service > - > > Key: TAP5-2170 > URL: https://issues.apache.org/jira/browse/TAP5-2170 > Project: Tapestry 5 > Issue Type: Bug > Components: tapestry-core >Affects Versions: 5.4 >Reporter: Lenny Primak >Priority: Minor > > Since 5.4, constructAssetPath requires an argument that not easily obtained, > and requires a use of internal API. > Thread: > http://apache-tapestry-mailing-list-archives.1045711.n5.nabble.com/T5-4-Alpha-15-constructAssetPath-changes-td5723188.html -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TAP5-2170) constructAssetPath() requires use of internal service
[ https://issues.apache.org/jira/browse/TAP5-2170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14082716#comment-14082716 ] Lenny Primak commented on TAP5-2170: Agreed. The above method works > constructAssetPath() requires use of internal service > - > > Key: TAP5-2170 > URL: https://issues.apache.org/jira/browse/TAP5-2170 > Project: Tapestry 5 > Issue Type: Bug > Components: tapestry-core >Affects Versions: 5.4 >Reporter: Lenny Primak >Priority: Minor > > Since 5.4, constructAssetPath requires an argument that not easily obtained, > and requires a use of internal API. > Thread: > http://apache-tapestry-mailing-list-archives.1045711.n5.nabble.com/T5-4-Alpha-15-constructAssetPath-changes-td5723188.html -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TAP5-2321) Tapestry 5.3.7 does not run with Java 8
[ https://issues.apache.org/jira/browse/TAP5-2321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13971760#comment-13971760 ] Lenny Primak commented on TAP5-2321: Related Ticket: https://issues.apache.org/jira/browse/TAP5-2214 > Tapestry 5.3.7 does not run with Java 8 > --- > > Key: TAP5-2321 > URL: https://issues.apache.org/jira/browse/TAP5-2321 > Project: Tapestry 5 > Issue Type: Bug > Components: plastic >Affects Versions: 5.3.7 >Reporter: Lenny Primak >Priority: Critical > > Tapestry 5.3.7 does not run on Java 8 due to ASM issues. > The same fix applied to Tapestry 5.4 should be applied to Tapestry 5.3 > and 5.3.8 should be release. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (TAP5-2320) Tapestry 5.3.7 does not run with Java 8
Lenny Primak created TAP5-2320: -- Summary: Tapestry 5.3.7 does not run with Java 8 Key: TAP5-2320 URL: https://issues.apache.org/jira/browse/TAP5-2320 Project: Tapestry 5 Issue Type: Bug Components: plastic Affects Versions: 5.3.7 Reporter: Lenny Primak Priority: Critical Tapestry 5.3.7 does not run on Java 8 due to ASM issues. The same fix applied to Tapestry 5.4 should be applied to Tapestry 5.3 and 5.3.8 should be release. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (TAP5-2321) Tapestry 5.3.7 does not run with Java 8
Lenny Primak created TAP5-2321: -- Summary: Tapestry 5.3.7 does not run with Java 8 Key: TAP5-2321 URL: https://issues.apache.org/jira/browse/TAP5-2321 Project: Tapestry 5 Issue Type: Bug Components: plastic Affects Versions: 5.3.7 Reporter: Lenny Primak Priority: Critical Tapestry 5.3.7 does not run on Java 8 due to ASM issues. The same fix applied to Tapestry 5.4 should be applied to Tapestry 5.3 and 5.3.8 should be release. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TAP5-2187) CSS relative URL rewriting isn't lenient enough
[ https://issues.apache.org/jira/browse/TAP5-2187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13945839#comment-13945839 ] Lenny Primak commented on TAP5-2187: My particular reason is a 3rd party JS/CSS library that cannot be changed (proprietary, and generated from GWT) so there is no way to add the files in the proper locations (files are dynamic) etc. > CSS relative URL rewriting isn't lenient enough > --- > > Key: TAP5-2187 > URL: https://issues.apache.org/jira/browse/TAP5-2187 > Project: Tapestry 5 > Issue Type: Bug > Components: tapestry-core >Affects Versions: 5.4 >Reporter: Lenny Primak > > I am trying to integrate an existing GWT framework as tapestry components. > One of the .css files its trying to load references an non-existent .png file. > Instead of just ignoring it, Tapestry produces a 500 error loading the .css > file, > which I don't believe there is a workaround for. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TAP5-2214) Make tapestry5 java8 compatible
[ https://issues.apache.org/jira/browse/TAP5-2214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13889022#comment-13889022 ] Lenny Primak commented on TAP5-2214: I would also like a T5.3.x release that's compatible via Java8 > Make tapestry5 java8 compatible > --- > > Key: TAP5-2214 > URL: https://issues.apache.org/jira/browse/TAP5-2214 > Project: Tapestry 5 > Issue Type: Improvement > Components: plastic >Affects Versions: 5.4 >Reporter: Joachim Van der Auwera >Assignee: Howard M. Lewis Ship > Attachments: 0001-use-asm-5.0_BETA-for-java8.patch, > 0002-TAP5-2214-use-ASM-5.0_BETA-for-java8-compatibility.patch > > > As it stands Tapestry does not work on java8. This seems to be caused by ASM. > Updating the enclosed asm to 5.0_Bet seems to do the trick. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (TAP5-2158) Client-side validation of @Size is not working when only min or max is set
[
https://issues.apache.org/jira/browse/TAP5-2158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13811713#comment-13811713
]
Lenny Primak commented on TAP5-2158:
Looks good
> Client-side validation of @Size is not working when only min or max is set
> --
>
> Key: TAP5-2158
> URL: https://issues.apache.org/jira/browse/TAP5-2158
> Project: Tapestry 5
> Issue Type: Bug
> Components: tapestry-beanvalidator
>Affects Versions: 5.4
>Reporter: Balázs Palcsó
>Assignee: Thiago H. de Paula Figueiredo
>Priority: Minor
> Fix For: 5.4
>
>
> Exact version: 5.4-alpha-14
> Server side example:
> {code}
> @Size(min = 3)
> private String name;
> {code}
> On the client side the following function gets executed:
> {code}
> doRangeValidate = function(element, value, memo) {
> var max, min;
> min = rangeValue(element, "data-range-min", 0);
> max = rangeValue(element, "data-range-max", Number.MAX_VALUE);
> if (_.isString(value)) {
> value = value.length;
> }
> if (!((min <= value && value <= max))) {
> memo.error = (element.attribute("data-range-message")) || "RANGE
> ERROR";
> return false;
> }
> return true;
> };
> {code}
> In the above example max is evaluated to NaN and therefore the function
> returns false causing validation error.
> Same applies when you only max is specified in @Size annotation and min is
> evaluated to NaN.
> h3. Workaround
> Specify both min and max.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (TAP5-2158) Client-side validation of @Size is not working when only min or max is set
[
https://issues.apache.org/jira/browse/TAP5-2158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13811414#comment-13811414
]
Lenny Primak commented on TAP5-2158:
I believe that this issue is only fixed for prototype, but for JQuery DOM
backing, this issue still exists
> Client-side validation of @Size is not working when only min or max is set
> --
>
> Key: TAP5-2158
> URL: https://issues.apache.org/jira/browse/TAP5-2158
> Project: Tapestry 5
> Issue Type: Bug
> Components: tapestry-beanvalidator
>Affects Versions: 5.4
>Reporter: Balázs Palcsó
>Assignee: Thiago H. de Paula Figueiredo
>Priority: Minor
> Fix For: 5.4
>
>
> Exact version: 5.4-alpha-14
> Server side example:
> {code}
> @Size(min = 3)
> private String name;
> {code}
> On the client side the following function gets executed:
> {code}
> doRangeValidate = function(element, value, memo) {
> var max, min;
> min = rangeValue(element, "data-range-min", 0);
> max = rangeValue(element, "data-range-max", Number.MAX_VALUE);
> if (_.isString(value)) {
> value = value.length;
> }
> if (!((min <= value && value <= max))) {
> memo.error = (element.attribute("data-range-message")) || "RANGE
> ERROR";
> return false;
> }
> return true;
> };
> {code}
> In the above example max is evaluated to NaN and therefore the function
> returns false causing validation error.
> Same applies when you only max is specified in @Size annotation and min is
> evaluated to NaN.
> h3. Workaround
> Specify both min and max.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (TAP5-2196) RequireJs custom path contribution - via Stacks or JavaScriptSupport
[
https://issues.apache.org/jira/browse/TAP5-2196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13811388#comment-13811388
]
Lenny Primak commented on TAP5-2196:
Not sure I understand this approach completely, but it sounds reasonable.
At the end of the day we want to customize requirejs.config() and however its
done
(the easier the better) will work for me.
> RequireJs custom path contribution - via Stacks or JavaScriptSupport
>
>
> Key: TAP5-2196
> URL: https://issues.apache.org/jira/browse/TAP5-2196
> Project: Tapestry 5
> Issue Type: Improvement
> Components: tapestry-core
>Affects Versions: 5.4
>Reporter: Magnus Kvalheim
> Labels: requirejs
>
> Currently I think there is no way to configure requirejs paths.
> Also - the requirejs config is 'global' and all entries included on every
> page.
> Would be good improvement if there were some more flexibility in config and
> more contributions was possible.
> --
> As part of 5.4 migration process we have some components that make use of
> JQueryFileUpload, https://github.com/blueimp/jQuery-File-Upload .
> This library uses the factory approach for defining the modules to work in
> both AMD and non AMD environments.
> Internally it handles loading of required modules, but work with paths. (And
> does not try to load from a fixed directory structure).
> So I think I need to specify things like
> requirejs.config({
> paths: {
> 'jquery.fileupload':
> '../library/jquery.fileupload/jquery.fileupload', //path to file
> 'jquery.iframe-transport':
> '../library/jquery.fileupload/jquery.iframe-transport', //path to file
> 'jquery.ui.widget':
> '../library/jquery.fileupload/vendor/jquery.ui.widget', //path to file
> }
> });
> Currently, only option is to configure shims through tapestry's
> modulemanager, but that's for non-AMD scripts and is likely to cause problems.
> Also the shim config would be global (all pages) - which I'd like to avoid as
> well.
> In 5.3 I've used a JQueryFileUpload to define all the deps like so..
> public List getJavaScriptLibraries() {
> List ret = new ArrayList();
>
> ret.add(assetSource.getContextAsset("jquery-file-upload/7.2.1/js/vendor/jquery.ui.widget.js",
> null));
>
> ret.add(assetSource.getContextAsset("jquery-file-upload/extra/js/load-image.min.js",
> null));
>
> ret.add(assetSource.getContextAsset("jquery-file-upload/extra/js/canvas-to-blob.min.js",
> null));
>
> ret.add(assetSource.getContextAsset("jquery-file-upload/7.2.1/js/jquery.iframe-transport.js",
> null));
>
> ret.add(assetSource.getContextAsset("jquery-file-upload/7.2.1/js/jquery.fileupload.js",
> null));
>
> ret.add(assetSource.getContextAsset("jquery-file-upload/7.2.1/js/jquery.fileupload-fp.js",
> null));
> It would be useful it was possible somehow to contribute to requirejs
> configuration through stacks.
> That way they could be added to the requirejs config if the stack was used.
> If it was a service (perhaps exposed through JavaScriptSupport) one could
> also contribute on a page/component level..?
> I have no idea about the implications of this and if it's possible to
> accomplish, but could potentially help solving some more advanced use cases.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (TAP5-2182) BeanEditor should be more flexible in the markup it generates (was BeanEditor doesn't look as good in T5.4 as in T5.3)
[ https://issues.apache.org/jira/browse/TAP5-2182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13811023#comment-13811023 ] Lenny Primak commented on TAP5-2182: The fix should be able to modify all components to emit form-horizontal forms. > BeanEditor should be more flexible in the markup it generates (was BeanEditor > doesn't look as good in T5.4 as in T5.3) > -- > > Key: TAP5-2182 > URL: https://issues.apache.org/jira/browse/TAP5-2182 > Project: Tapestry 5 > Issue Type: Bug > Components: tapestry-core >Affects Versions: 5.4 >Reporter: Lenny Primak >Assignee: Thiago H. de Paula Figueiredo > > I noticed something else that's not as pretty out of the box in T5.4 due to > bootstrap probably > In T5.3, beaneditor looks something like this (pretty): > Label [Input Text/Date/etc] > Label [Input Text/Date/etc] > In T5.4, it looks like this (not so pretty or usable): > Label > [Input Text/Date/etc (takes up the whole width of the page)] > Label > [Input Text/Date/etc (takes up the whole width of the page)] > I think this should be fixed out of the box -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Closed] (TAP5-2208) BeanEditForm doesn't generate form-group DIVs with block parameters
[
https://issues.apache.org/jira/browse/TAP5-2208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lenny Primak closed TAP5-2208.
--
Resolution: Won't Fix
Risk of incompatibility too great
> BeanEditForm doesn't generate form-group DIVs with block parameters
> ---
>
> Key: TAP5-2208
> URL: https://issues.apache.org/jira/browse/TAP5-2208
> Project: Tapestry 5
> Issue Type: Bug
> Components: tapestry-core
>Affects Versions: 5.4
>Reporter: Lenny Primak
>
> When using BeanEditForm with block parameters, i.e.
> {{{
>
>
>
> for="CreateTextRecord">
> Create Text Record?
>
> t:id="CreateTextRecord"
> value="rr.createTextRecord" />
>
>
> }}}
> div class=form-group is the proper boostrap markup,
> but it's not being generated.
> When block parameters are not used, the form-group DIVs
> are generated correctly
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (TAP5-2208) BeanEditForm doesn't generate form-group DIVs with block parameters
[
https://issues.apache.org/jira/browse/TAP5-2208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lenny Primak updated TAP5-2208:
---
Issue Type: New Feature (was: Bug)
> BeanEditForm doesn't generate form-group DIVs with block parameters
> ---
>
> Key: TAP5-2208
> URL: https://issues.apache.org/jira/browse/TAP5-2208
> Project: Tapestry 5
> Issue Type: New Feature
> Components: tapestry-core
>Affects Versions: 5.4
>Reporter: Lenny Primak
>
> When using BeanEditForm with block parameters, i.e.
> {{{
>
>
>
> for="CreateTextRecord">
> Create Text Record?
>
> t:id="CreateTextRecord"
> value="rr.createTextRecord" />
>
>
> }}}
> div class=form-group is the proper boostrap markup,
> but it's not being generated.
> When block parameters are not used, the form-group DIVs
> are generated correctly
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (TAP5-2208) BeanEditForm doesn't generate form-group DIVs with block parameters
[
https://issues.apache.org/jira/browse/TAP5-2208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lenny Primak updated TAP5-2208:
---
Issue Type: Improvement (was: New Feature)
> BeanEditForm doesn't generate form-group DIVs with block parameters
> ---
>
> Key: TAP5-2208
> URL: https://issues.apache.org/jira/browse/TAP5-2208
> Project: Tapestry 5
> Issue Type: Improvement
> Components: tapestry-core
>Affects Versions: 5.4
>Reporter: Lenny Primak
>
> When using BeanEditForm with block parameters, i.e.
> {{{
>
>
>
> for="CreateTextRecord">
> Create Text Record?
>
> t:id="CreateTextRecord"
> value="rr.createTextRecord" />
>
>
> }}}
> div class=form-group is the proper boostrap markup,
> but it's not being generated.
> When block parameters are not used, the form-group DIVs
> are generated correctly
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Reopened] (TAP5-2208) BeanEditForm doesn't generate form-group DIVs with block parameters
[
https://issues.apache.org/jira/browse/TAP5-2208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lenny Primak reopened TAP5-2208:
Will change to improvement
> BeanEditForm doesn't generate form-group DIVs with block parameters
> ---
>
> Key: TAP5-2208
> URL: https://issues.apache.org/jira/browse/TAP5-2208
> Project: Tapestry 5
> Issue Type: Bug
> Components: tapestry-core
>Affects Versions: 5.4
>Reporter: Lenny Primak
>
> When using BeanEditForm with block parameters, i.e.
> {{{
>
>
>
> for="CreateTextRecord">
> Create Text Record?
>
> t:id="CreateTextRecord"
> value="rr.createTextRecord" />
>
>
> }}}
> div class=form-group is the proper boostrap markup,
> but it's not being generated.
> When block parameters are not used, the form-group DIVs
> are generated correctly
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (TAP5-2208) BeanEditForm doesn't generate form-group DIVs with block parameters
[
https://issues.apache.org/jira/browse/TAP5-2208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13810462#comment-13810462
]
Lenny Primak commented on TAP5-2208:
Than, things can be handled even easier.
We can have a symbol that automatically surrounds block-parameters in
This way, the layout won't be broken for existing 5.3 templates in case for
form-horizontal.
Once TAP5-2182 is implemented you will see that this is the right course of
action,
and will be the most compatible. I know this because I already implemented
this in a mixin and
can see the results.
Lets put this issue off until we can test TAP5-2182 and we can see what's the
better default option.
We can have it as optional as well, no harm done.
> BeanEditForm doesn't generate form-group DIVs with block parameters
> ---
>
> Key: TAP5-2208
> URL: https://issues.apache.org/jira/browse/TAP5-2208
> Project: Tapestry 5
> Issue Type: Bug
> Components: tapestry-core
>Affects Versions: 5.4
>Reporter: Lenny Primak
>
> When using BeanEditForm with block parameters, i.e.
> {{{
>
>
>
> for="CreateTextRecord">
> Create Text Record?
>
> t:id="CreateTextRecord"
> value="rr.createTextRecord" />
>
>
> }}}
> div class=form-group is the proper boostrap markup,
> but it's not being generated.
> When block parameters are not used, the form-group DIVs
> are generated correctly
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (TAP5-2208) BeanEditForm doesn't generate form-group DIVs with block parameters
[
https://issues.apache.org/jira/browse/TAP5-2208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13810426#comment-13810426
]
Lenny Primak commented on TAP5-2208:
If block parameters won't require different markup whether its form-horizontal
or not,
I am OK with that solution. I just don't see how it can possibly be done with
bootstrap 3 markup,
other that what I envision. But I am looking forward to a pleasant surprise.
> BeanEditForm doesn't generate form-group DIVs with block parameters
> ---
>
> Key: TAP5-2208
> URL: https://issues.apache.org/jira/browse/TAP5-2208
> Project: Tapestry 5
> Issue Type: Bug
> Components: tapestry-core
>Affects Versions: 5.4
>Reporter: Lenny Primak
>
> When using BeanEditForm with block parameters, i.e.
> {{{
>
>
>
> for="CreateTextRecord">
> Create Text Record?
>
> t:id="CreateTextRecord"
> value="rr.createTextRecord" />
>
>
> }}}
> div class=form-group is the proper boostrap markup,
> but it's not being generated.
> When block parameters are not used, the form-group DIVs
> are generated correctly
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (TAP5-2208) BeanEditForm doesn't generate form-group DIVs with block parameters
[
https://issues.apache.org/jira/browse/TAP5-2208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13810407#comment-13810407
]
Lenny Primak commented on TAP5-2208:
That's exactly the problem. New behavior is required due to bootstrap 3 and
form-horizontal.
It will become very clear to you once you implement TAP5-2182 because its just
common sense.
What I am suggestion will not break any existing templates. This bug actually
arose because
the new layout actually broke existing templates.
Many, if not all issues that I am raising are actually regressions that I am
getting from trying to port
my projects. I am all about compatibility! (or at least for 99% of it that
matters!)
> BeanEditForm doesn't generate form-group DIVs with block parameters
> ---
>
> Key: TAP5-2208
> URL: https://issues.apache.org/jira/browse/TAP5-2208
> Project: Tapestry 5
> Issue Type: Bug
> Components: tapestry-core
>Affects Versions: 5.4
>Reporter: Lenny Primak
>
> When using BeanEditForm with block parameters, i.e.
> {{{
>
>
>
> for="CreateTextRecord">
> Create Text Record?
>
> t:id="CreateTextRecord"
> value="rr.createTextRecord" />
>
>
> }}}
> div class=form-group is the proper boostrap markup,
> but it's not being generated.
> When block parameters are not used, the form-group DIVs
> are generated correctly
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (TAP5-2208) BeanEditForm doesn't generate form-group DIVs with block parameters
[
https://issues.apache.org/jira/browse/TAP5-2208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13810400#comment-13810400
]
Lenny Primak commented on TAP5-2208:
In any case this ticket is in the comments of
https://issues.apache.org/jira/browse/TAP5-2182 anyway
> BeanEditForm doesn't generate form-group DIVs with block parameters
> ---
>
> Key: TAP5-2208
> URL: https://issues.apache.org/jira/browse/TAP5-2208
> Project: Tapestry 5
> Issue Type: Bug
> Components: tapestry-core
>Affects Versions: 5.4
>Reporter: Lenny Primak
>
> When using BeanEditForm with block parameters, i.e.
> {{{
>
>
>
> for="CreateTextRecord">
> Create Text Record?
>
> t:id="CreateTextRecord"
> value="rr.createTextRecord" />
>
>
> }}}
> div class=form-group is the proper boostrap markup,
> but it's not being generated.
> When block parameters are not used, the form-group DIVs
> are generated correctly
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (TAP5-2208) BeanEditForm doesn't generate form-group DIVs with block parameters
[
https://issues.apache.org/jira/browse/TAP5-2208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13810353#comment-13810353
]
Lenny Primak commented on TAP5-2208:
But this forces the user to generate different markup depending if
form-horizontal is used.
Leaving this up to the user feels like incomplete functionality. You will see
this as you implement form-horizontal
> BeanEditForm doesn't generate form-group DIVs with block parameters
> ---
>
> Key: TAP5-2208
> URL: https://issues.apache.org/jira/browse/TAP5-2208
> Project: Tapestry 5
> Issue Type: Bug
> Components: tapestry-core
>Affects Versions: 5.4
>Reporter: Lenny Primak
>
> When using BeanEditForm with block parameters, i.e.
> {{{
>
>
>
> for="CreateTextRecord">
> Create Text Record?
>
> t:id="CreateTextRecord"
> value="rr.createTextRecord" />
>
>
> }}}
> div class=form-group is the proper boostrap markup,
> but it's not being generated.
> When block parameters are not used, the form-group DIVs
> are generated correctly
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (TAP5-2211) Replace DatePicker with Bootstrap or JQueryUI DatePicker
[ https://issues.apache.org/jira/browse/TAP5-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13809450#comment-13809450 ] Lenny Primak commented on TAP5-2211: That would be wonderful, and will take pressure off this issue for me. Maybe we can do both, fix the "old" datepicker and get this issue fixed a bit later, perhaps based on experience that we have with your project (thanks!) > Replace DatePicker with Bootstrap or JQueryUI DatePicker > > > Key: TAP5-2211 > URL: https://issues.apache.org/jira/browse/TAP5-2211 > Project: Tapestry 5 > Issue Type: Improvement > Components: tapestry-core >Affects Versions: 5.4 >Reporter: Lenny Primak >Assignee: Thiago H. de Paula Figueiredo > Labels: datefield, datepicker > > The current 3rd party datepicker used by Tapestry is very old, > and isn't very good. It's time to update it to one of > the better currently-available datepickers. > There are about 15 unresolved issues opened against Datepicker that can all > be solved by just replacing it. > I suggest JQueryUI datepicker (if JQuery is included as the default stack) > The current datepicker can be left alone is prototype is chosen. > By default, JQueryUI datepicker should be used with the button-to-activate > option so that it looks similar to the current datepicker. > It should also work properly in BeanEditor and friends and even look good > with form-horizontal version of BeanEditor > -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (TAP5-2211) Replace DatePicker with Bootstrap or JQueryUI DatePicker
[ https://issues.apache.org/jira/browse/TAP5-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lenny Primak updated TAP5-2211: --- Summary: Replace DatePicker with Bootstrap or JQueryUI DatePicker (was: Replace DatePicker with JQueryUI DatePicker) > Replace DatePicker with Bootstrap or JQueryUI DatePicker > > > Key: TAP5-2211 > URL: https://issues.apache.org/jira/browse/TAP5-2211 > Project: Tapestry 5 > Issue Type: Improvement > Components: tapestry-core >Affects Versions: 5.4 >Reporter: Lenny Primak >Assignee: Thiago H. de Paula Figueiredo > Labels: datefield, datepicker > > The current 3rd party datepicker used by Tapestry is very old, > and isn't very good. It's time to update it to one of > the better currently-available datepickers. > There are about 15 unresolved issues opened against Datepicker that can all > be solved by just replacing it. > I suggest JQueryUI datepicker (if JQuery is included as the default stack) > The current datepicker can be left alone is prototype is chosen. > By default, JQueryUI datepicker should be used with the button-to-activate > option so that it looks similar to the current datepicker. > It should also work properly in BeanEditor and friends and even look good > with form-horizontal version of BeanEditor > -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (TAP5-2211) Replace DatePicker with JQueryUI DatePicker
[ https://issues.apache.org/jira/browse/TAP5-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13809425#comment-13809425 ] Lenny Primak commented on TAP5-2211: Barry, this is it! This date picker does what it needs to do: - it works well - doesn't add much after-the-fact via JavaScript - has lots of options, easy to configure - works in form-horizontal (which JQueryDatepicker doesn't) I think you've stumbled on a gold mine here > Replace DatePicker with JQueryUI DatePicker > --- > > Key: TAP5-2211 > URL: https://issues.apache.org/jira/browse/TAP5-2211 > Project: Tapestry 5 > Issue Type: Improvement > Components: tapestry-core >Affects Versions: 5.4 >Reporter: Lenny Primak >Assignee: Thiago H. de Paula Figueiredo > Labels: datefield, datepicker > > The current 3rd party datepicker used by Tapestry is very old, > and isn't very good. It's time to update it to one of > the better currently-available datepickers. > There are about 15 unresolved issues opened against Datepicker that can all > be solved by just replacing it. > I suggest JQueryUI datepicker (if JQuery is included as the default stack) > The current datepicker can be left alone is prototype is chosen. > By default, JQueryUI datepicker should be used with the button-to-activate > option so that it looks similar to the current datepicker. > It should also work properly in BeanEditor and friends and even look good > with form-horizontal version of BeanEditor > -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (TAP5-2211) Replace DatePicker with JQueryUI DatePicker
[ https://issues.apache.org/jira/browse/TAP5-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13809268#comment-13809268 ] Lenny Primak commented on TAP5-2211: I just found a good one: https://issues.apache.org/jira/browse/TAP5-1845 If you look at the last comment, even Howard says that we should move to JQuery datepicker. Yes, some bugs mentioned above are closed, but they have clones / related ones that are not. I don't think any of these are indeed completely fixed in T5.4 There are lots of individual issues here, but they are all trivial to fix though. Anyway, I am willing to start by fixing all little bugs mentioned with the existing datefield, and then think about moving to the JQuery one. In the FlowLogix library, I have patches that fix all the issues for T5.3, but with T5.4 the patches no longer work, plus some of the bugs mentioned above are regressions from 5.3 http://code.google.com/p/flowlogix/wiki/TLCalendarPopupPatch > Replace DatePicker with JQueryUI DatePicker > --- > > Key: TAP5-2211 > URL: https://issues.apache.org/jira/browse/TAP5-2211 > Project: Tapestry 5 > Issue Type: Improvement > Components: tapestry-core >Affects Versions: 5.4 >Reporter: Lenny Primak >Assignee: Thiago H. de Paula Figueiredo > Labels: datefield, datepicker > > The current 3rd party datepicker used by Tapestry is very old, > and isn't very good. It's time to update it to one of > the better currently-available datepickers. > There are about 15 unresolved issues opened against Datepicker that can all > be solved by just replacing it. > I suggest JQueryUI datepicker (if JQuery is included as the default stack) > The current datepicker can be left alone is prototype is chosen. > By default, JQueryUI datepicker should be used with the button-to-activate > option so that it looks similar to the current datepicker. > It should also work properly in BeanEditor and friends and even look good > with form-horizontal version of BeanEditor > -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (TAP5-2211) Replace DatePicker with JQueryUI DatePicker
[ https://issues.apache.org/jira/browse/TAP5-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13808727#comment-13808727 ] Lenny Primak commented on TAP5-2211: As far as fixing "old" DateField, (which I could accept as an option) isn't that difficult either. Perhaps we could start with that as well There are "showstopper" datefield issues: https://issues.apache.org/jira/browse/TAP5-1845 https://issues.apache.org/jira/browse/TAP5-2203 https://issues.apache.org/jira/browse/TAP5-2003 https://issues.apache.org/jira/browse/TAP5-805 https://issues.apache.org/jira/browse/TAP5-1998 https://issues.apache.org/jira/browse/TAP5-2173 https://issues.apache.org/jira/browse/TAP5-2144 Plus one more (localization) to show "September 2013" as opposed to "2013 September" in the title: http://code.google.com/p/flowlogix/wiki/TLCalendarPopupPatch > Replace DatePicker with JQueryUI DatePicker > --- > > Key: TAP5-2211 > URL: https://issues.apache.org/jira/browse/TAP5-2211 > Project: Tapestry 5 > Issue Type: Improvement > Components: tapestry-core >Affects Versions: 5.4 >Reporter: Lenny Primak >Assignee: Thiago H. de Paula Figueiredo > Labels: datefield, datepicker > > The current 3rd party datepicker used by Tapestry is very old, > and isn't very good. It's time to update it to one of > the better currently-available datepickers. > There are about 15 unresolved issues opened against Datepicker that can all > be solved by just replacing it. > I suggest JQueryUI datepicker (if JQuery is included as the default stack) > The current datepicker can be left alone is prototype is chosen. > By default, JQueryUI datepicker should be used with the button-to-activate > option so that it looks similar to the current datepicker. > It should also work properly in BeanEditor and friends and even look good > with form-horizontal version of BeanEditor > -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (TAP5-2211) Replace DatePicker with JQueryUI DatePicker
[ https://issues.apache.org/jira/browse/TAP5-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13808725#comment-13808725 ] Lenny Primak commented on TAP5-2211: Barry, Thiago, all are valid points, but from the user's perspective, it would be needlessly removing functionality, and it's not that easy, especially for a novice to figure out how to built AppBlocks, etc. Native browser date + morernizr is a fabulous idea, but the objections that were raised to JQuery date picker also apply here. Tapestry-JQuery datefield doesn't have any insurmountable problems like this, so I don't see why any of these are such a big deal. > Replace DatePicker with JQueryUI DatePicker > --- > > Key: TAP5-2211 > URL: https://issues.apache.org/jira/browse/TAP5-2211 > Project: Tapestry 5 > Issue Type: Improvement > Components: tapestry-core >Affects Versions: 5.4 >Reporter: Lenny Primak >Assignee: Thiago H. de Paula Figueiredo > Labels: datefield, datepicker > > The current 3rd party datepicker used by Tapestry is very old, > and isn't very good. It's time to update it to one of > the better currently-available datepickers. > There are about 15 unresolved issues opened against Datepicker that can all > be solved by just replacing it. > I suggest JQueryUI datepicker (if JQuery is included as the default stack) > The current datepicker can be left alone is prototype is chosen. > By default, JQueryUI datepicker should be used with the button-to-activate > option so that it looks similar to the current datepicker. > It should also work properly in BeanEditor and friends and even look good > with form-horizontal version of BeanEditor > -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (TAP5-2211) Replace DatePicker with JQueryUI DatePicker
[ https://issues.apache.org/jira/browse/TAP5-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13808633#comment-13808633 ] Lenny Primak commented on TAP5-2211: I think in any case, tying Tapestry to a legacy datepicker that's unsupported is not the best approach. If tying a framework to a datepicker, a supported JQuery datepicker is a good way to go. At least when there are issues filed against it then JQuery people could fix it. The API for this is pretty stable as well, so that's wouldn't be an issues. I've tried using Barry's datepicker library, and it does work as advertised, but it doesn't integrate well in all cases and all layouts in bootstrap. I won't go into it further (maybe later offline) but all these problems are too complicated for ordinary users to grasp, so this should be fixed in tapestry one way or another. I do have an alternative set of issues that can make the current datepicker work, but I would prefer to fix the root of the problem and go with JQuery Datepicker. > Replace DatePicker with JQueryUI DatePicker > --- > > Key: TAP5-2211 > URL: https://issues.apache.org/jira/browse/TAP5-2211 > Project: Tapestry 5 > Issue Type: Improvement > Components: tapestry-core >Affects Versions: 5.4 >Reporter: Lenny Primak > Labels: datefield, datepicker > > The current 3rd party datepicker used by Tapestry is very old, > and isn't very good. It's time to update it to one of > the better currently-available datepickers. > There are about 15 unresolved issues opened against Datepicker that can all > be solved by just replacing it. > I suggest JQueryUI datepicker (if JQuery is included as the default stack) > The current datepicker can be left alone is prototype is chosen. > By default, JQueryUI datepicker should be used with the button-to-activate > option so that it looks similar to the current datepicker. > It should also work properly in BeanEditor and friends and even look good > with form-horizontal version of BeanEditor > -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (TAP5-2211) Replace DatePicker with JQueryUI DatePicker
[ https://issues.apache.org/jira/browse/TAP5-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13808619#comment-13808619 ] Lenny Primak commented on TAP5-2211: I am not convinced that this is an unsolvable problem. Another approach is JQDateField or something like that, and have a symbol that switches the default. The current datefield situation in Tapestry now isn't workable (at least in our projects) > Replace DatePicker with JQueryUI DatePicker > --- > > Key: TAP5-2211 > URL: https://issues.apache.org/jira/browse/TAP5-2211 > Project: Tapestry 5 > Issue Type: Improvement > Components: tapestry-core >Affects Versions: 5.4 >Reporter: Lenny Primak > Labels: datefield, datepicker > > The current 3rd party datepicker used by Tapestry is very old, > and isn't very good. It's time to update it to one of > the better currently-available datepickers. > There are about 15 unresolved issues opened against Datepicker that can all > be solved by just replacing it. > I suggest JQueryUI datepicker (if JQuery is included as the default stack) > The current datepicker can be left alone is prototype is chosen. > By default, JQueryUI datepicker should be used with the button-to-activate > option so that it looks similar to the current datepicker. > It should also work properly in BeanEditor and friends and even look good > with form-horizontal version of BeanEditor > -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Comment Edited] (TAP5-2211) Replace DatePicker with JQueryUI DatePicker
[ https://issues.apache.org/jira/browse/TAP5-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13808531#comment-13808531 ] Lenny Primak edited comment on TAP5-2211 at 10/29/13 10:21 PM: --- Barry, I don't think that the problem that you mentioned here is unsolvable at all. There can be a mapping between Java and JavaScript DateFormat, and there can be a subclass of DateFormat that returns the format. The whole reason to replace Datepicker in Tapestry is so there is a modern, supported datepicker that's maintained by someone else (JQuery team) and it won't get stale or obsolete soon Also, your textfield solution won't work for BeanEditor. was (Author: lprimak): Barry, I don't think that the problem that you mentioned here is unsolvable at all. There can be a mapping between Java and JavaScript DateFormat, and there can be a subclass of DateFormat that returns the format. The whole reason to replace Datepicker in Tapestry is so there is a modern, supported datepicker that's maintained by someone else (JQuery team) and it won't get stale or obsolete soon > Replace DatePicker with JQueryUI DatePicker > --- > > Key: TAP5-2211 > URL: https://issues.apache.org/jira/browse/TAP5-2211 > Project: Tapestry 5 > Issue Type: Improvement > Components: tapestry-core >Affects Versions: 5.4 >Reporter: Lenny Primak > Labels: datefield, datepicker > > The current 3rd party datepicker used by Tapestry is very old, > and isn't very good. It's time to update it to one of > the better currently-available datepickers. > There are about 15 unresolved issues opened against Datepicker that can all > be solved by just replacing it. > I suggest JQueryUI datepicker (if JQuery is included as the default stack) > The current datepicker can be left alone is prototype is chosen. > By default, JQueryUI datepicker should be used with the button-to-activate > option so that it looks similar to the current datepicker. > It should also work properly in BeanEditor and friends and even look good > with form-horizontal version of BeanEditor > -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (TAP5-2211) Replace DatePicker with JQueryUI DatePicker
[ https://issues.apache.org/jira/browse/TAP5-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13808531#comment-13808531 ] Lenny Primak commented on TAP5-2211: Barry, I don't think that the problem that you mentioned here is unsolvable at all. There can be a mapping between Java and JavaScript DateFormat, and there can be a subclass of DateFormat that returns the format. The whole reason to replace Datepicker in Tapestry is so there is a modern, supported datepicker that's maintained by someone else (JQuery team) and it won't get stale or obsolete soon > Replace DatePicker with JQueryUI DatePicker > --- > > Key: TAP5-2211 > URL: https://issues.apache.org/jira/browse/TAP5-2211 > Project: Tapestry 5 > Issue Type: Improvement > Components: tapestry-core >Affects Versions: 5.4 >Reporter: Lenny Primak > Labels: datefield, datepicker > > The current 3rd party datepicker used by Tapestry is very old, > and isn't very good. It's time to update it to one of > the better currently-available datepickers. > There are about 15 unresolved issues opened against Datepicker that can all > be solved by just replacing it. > I suggest JQueryUI datepicker (if JQuery is included as the default stack) > The current datepicker can be left alone is prototype is chosen. > By default, JQueryUI datepicker should be used with the button-to-activate > option so that it looks similar to the current datepicker. > It should also work properly in BeanEditor and friends and even look good > with form-horizontal version of BeanEditor > -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (TAP5-2211) Replace DatePicker with JQueryUI DatePicker
[ https://issues.apache.org/jira/browse/TAP5-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13808476#comment-13808476 ] Lenny Primak commented on TAP5-2211: Quick google search revealed this: http://stackoverflow.com/questions/494958/how-do-i-localize-the-jquery-ui-datepicker > Replace DatePicker with JQueryUI DatePicker > --- > > Key: TAP5-2211 > URL: https://issues.apache.org/jira/browse/TAP5-2211 > Project: Tapestry 5 > Issue Type: Improvement > Components: tapestry-core >Affects Versions: 5.4 >Reporter: Lenny Primak > Labels: datefield, datepicker > > The current 3rd party datepicker used by Tapestry is very old, > and isn't very good. It's time to update it to one of > the better currently-available datepickers. > There are about 15 unresolved issues opened against Datepicker that can all > be solved by just replacing it. > I suggest JQueryUI datepicker (if JQuery is included as the default stack) > The current datepicker can be left alone is prototype is chosen. > By default, JQueryUI datepicker should be used with the button-to-activate > option so that it looks similar to the current datepicker. > It should also work properly in BeanEditor and friends and even look good > with form-horizontal version of BeanEditor > -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (TAP5-2211) Replace DatePicker with JQueryUI DatePicker
[ https://issues.apache.org/jira/browse/TAP5-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13808366#comment-13808366 ] Lenny Primak commented on TAP5-2211: I see #1 being the best option. It's not ideal but I think it's the best that can be hoped for. #2 isn't a good option to be the Tapestry default. > Replace DatePicker with JQueryUI DatePicker > --- > > Key: TAP5-2211 > URL: https://issues.apache.org/jira/browse/TAP5-2211 > Project: Tapestry 5 > Issue Type: Improvement > Components: tapestry-core >Affects Versions: 5.4 >Reporter: Lenny Primak > Labels: datefield, datepicker > > The current 3rd party datepicker used by Tapestry is very old, > and isn't very good. It's time to update it to one of > the better currently-available datepickers. > There are about 15 unresolved issues opened against Datepicker that can all > be solved by just replacing it. > I suggest JQueryUI datepicker (if JQuery is included as the default stack) > The current datepicker can be left alone is prototype is chosen. > By default, JQueryUI datepicker should be used with the button-to-activate > option so that it looks similar to the current datepicker. > It should also work properly in BeanEditor and friends and even look good > with form-horizontal version of BeanEditor > -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (TAP5-2182) BeanEditor doesn't look as good in T5.4 as in T5.3
[ https://issues.apache.org/jira/browse/TAP5-2182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13808262#comment-13808262 ] Lenny Primak commented on TAP5-2182: Related ticket: https://issues.apache.org/jira/browse/TAP5-2208 > BeanEditor doesn't look as good in T5.4 as in T5.3 > -- > > Key: TAP5-2182 > URL: https://issues.apache.org/jira/browse/TAP5-2182 > Project: Tapestry 5 > Issue Type: Bug > Components: tapestry-core >Affects Versions: 5.4 >Reporter: Lenny Primak >Assignee: Thiago H. de Paula Figueiredo > > I noticed something else that's not as pretty out of the box in T5.4 due to > bootstrap probably > In T5.3, beaneditor looks something like this (pretty): > Label [Input Text/Date/etc] > Label [Input Text/Date/etc] > In T5.4, it looks like this (not so pretty or usable): > Label > [Input Text/Date/etc (takes up the whole width of the page)] > Label > [Input Text/Date/etc (takes up the whole width of the page)] > I think this should be fixed out of the box -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Comment Edited] (TAP5-2182) BeanEditor doesn't look as good in T5.4 as in T5.3
[ https://issues.apache.org/jira/browse/TAP5-2182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13808262#comment-13808262 ] Lenny Primak edited comment on TAP5-2182 at 10/29/13 6:20 PM: -- The form-horizontal markup should also work with block-parameters i.e. my field inside the beaneditform Related ticket: https://issues.apache.org/jira/browse/TAP5-2208 was (Author: lprimak): Related ticket: https://issues.apache.org/jira/browse/TAP5-2208 > BeanEditor doesn't look as good in T5.4 as in T5.3 > -- > > Key: TAP5-2182 > URL: https://issues.apache.org/jira/browse/TAP5-2182 > Project: Tapestry 5 > Issue Type: Bug > Components: tapestry-core >Affects Versions: 5.4 >Reporter: Lenny Primak >Assignee: Thiago H. de Paula Figueiredo > > I noticed something else that's not as pretty out of the box in T5.4 due to > bootstrap probably > In T5.3, beaneditor looks something like this (pretty): > Label [Input Text/Date/etc] > Label [Input Text/Date/etc] > In T5.4, it looks like this (not so pretty or usable): > Label > [Input Text/Date/etc (takes up the whole width of the page)] > Label > [Input Text/Date/etc (takes up the whole width of the page)] > I think this should be fixed out of the box -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (TAP5-2197) Overriding core css - bug?
[
https://issues.apache.org/jira/browse/TAP5-2197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13808258#comment-13808258
]
Lenny Primak commented on TAP5-2197:
I created a mixin to as a workaround for this problem here (as part of
FlowLogix lirary)
http://code.google.com/p/flowlogix/source/browse/tapestry-services/src/main/java/com/flowlogix/web/mixins/OverrideCSS.java?name=tapestry-5.4
> Overriding core css - bug?
> --
>
> Key: TAP5-2197
> URL: https://issues.apache.org/jira/browse/TAP5-2197
> Project: Tapestry 5
> Issue Type: Bug
> Components: tapestry-core
>Affects Versions: 5.4
>Reporter: Geoff Callender
>
> I'm having trouble overriding the core css. I want to override the css of the
> bootstrap classes...
> When I do the following import, the page renders a link to my css BEFORE the
> links to the core css files. No good.
> @Import(stylesheet = { "context:css/mystylesheet.css" })
> BUT, when I do the following instead, the page renders in the right order,
> ie. a link to my css AFTER the links to the core css. Yay.
> @Import(stack = { "core" }, stylesheet = {
> "context:css/mystylesheet.css" })
> Is this a bug or expected behaviour?
> Cheers,
> Geoff
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (TAP5-2197) Overriding core css - bug?
[
https://issues.apache.org/jira/browse/TAP5-2197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13808256#comment-13808256
]
Lenny Primak commented on TAP5-2197:
Also, if you put your stylesheet in the layout component TML, it's also in the
wrong order
> Overriding core css - bug?
> --
>
> Key: TAP5-2197
> URL: https://issues.apache.org/jira/browse/TAP5-2197
> Project: Tapestry 5
> Issue Type: Bug
> Components: tapestry-core
>Affects Versions: 5.4
>Reporter: Geoff Callender
>
> I'm having trouble overriding the core css. I want to override the css of the
> bootstrap classes...
> When I do the following import, the page renders a link to my css BEFORE the
> links to the core css files. No good.
> @Import(stylesheet = { "context:css/mystylesheet.css" })
> BUT, when I do the following instead, the page renders in the right order,
> ie. a link to my css AFTER the links to the core css. Yay.
> @Import(stack = { "core" }, stylesheet = {
> "context:css/mystylesheet.css" })
> Is this a bug or expected behaviour?
> Cheers,
> Geoff
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (TAP5-2211) Replace DatePicker with JQueryUI DatePicker
[ https://issues.apache.org/jira/browse/TAP5-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13808252#comment-13808252 ] Lenny Primak commented on TAP5-2211: Examples of this being done already are here: http://tapestry5-jquery.com/core/docsdatefield And Here: https://github.com/trsvax/tapestry-datepicker > Replace DatePicker with JQueryUI DatePicker > --- > > Key: TAP5-2211 > URL: https://issues.apache.org/jira/browse/TAP5-2211 > Project: Tapestry 5 > Issue Type: Improvement > Components: tapestry-core >Affects Versions: 5.4 >Reporter: Lenny Primak > Labels: datefield, datepicker > > The current 3rd party datepicker used by Tapestry is very old, > and isn't very good. It's time to update it to one of > the better currently-available datepickers. > There are about 15 unresolved issues opened against Datepicker that can all > be solved by just replacing it. > I suggest JQueryUI datepicker (if JQuery is included as the default stack) > The current datepicker can be left alone is prototype is chosen. > By default, JQueryUI datepicker should be used with the button-to-activate > option so that it looks similar to the current datepicker. > It should also work properly in BeanEditor and friends and even look good > with form-horizontal version of BeanEditor > -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (TAP5-2211) Replace DatePicker with JQueryUI DatePicker
Lenny Primak created TAP5-2211: -- Summary: Replace DatePicker with JQueryUI DatePicker Key: TAP5-2211 URL: https://issues.apache.org/jira/browse/TAP5-2211 Project: Tapestry 5 Issue Type: Improvement Components: tapestry-core Affects Versions: 5.4 Reporter: Lenny Primak The current 3rd party datepicker used by Tapestry is very old, and isn't very good. It's time to update it to one of the better currently-available datepickers. There are about 15 unresolved issues opened against Datepicker that can all be solved by just replacing it. I suggest JQueryUI datepicker (if JQuery is included as the default stack) The current datepicker can be left alone is prototype is chosen. By default, JQueryUI datepicker should be used with the button-to-activate option so that it looks similar to the current datepicker. It should also work properly in BeanEditor and friends and even look good with form-horizontal version of BeanEditor -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (TAP5-2080) Default BaseURLSource does not handle all scenarios
[
https://issues.apache.org/jira/browse/TAP5-2080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13807148#comment-13807148
]
Lenny Primak commented on TAP5-2080:
He didn't use proper words, but the issue is valid.
Thomas is wrong about calling Tapestry code crap (it is far from it),
but that's not a reason to disregard this issue.
> Default BaseURLSource does not handle all scenarios
> ---
>
> Key: TAP5-2080
> URL: https://issues.apache.org/jira/browse/TAP5-2080
> Project: Tapestry 5
> Issue Type: Bug
>Affects Versions: 5.3.6
>Reporter: Thomas Hackel
>Assignee: Howard M. Lewis Ship
>
> Two Scenario:
> 1. User(Internet)->SSL-Proxy:443->Tomcat:8080
> 2. User(Intranet)->Tomcat:8080
> The BaseURLSourceImpl DOES NOT use the Scheme of the request, it just uses
> the secured flag to change the scheme. Which is not required/useful in the
> scenario above.
> The BaseURLSource creates links like "http://foo:443/bar"; instead of
> "https://foo/bar";.
> This problem was already mentioned in TAP5-167 which was "silently" closed.
> Overwriting the BaseURLSource, as described in
> http://tapestry.apache.org/https.html is also not possible because you would
> need a Request object which can't be injected because it causes some "service
> cycle" problem. The Request object is required to physically map 443 to
> https, because the Tap5 Request object also lacks the Request Scheme...
> {code}
> public static void contributeServiceOverride(
> MappedConfiguration, Object> configuration,
> @Inject Request request) {
> BaseURLSource source = new ProxyEnabledBaseURLSource(request);
> configuration.add(BaseURLSource.class, source);
> }
> {code}
> Causes:
> {code}
> java.lang.IllegalStateException: Construction of service 'ServiceOverride'
> has failed due to recursion: the service depends on itself in some way.
> Please check
> org.apache.tapestry5.ioc.internal.services.ServiceOverrideImpl(Map) (at
> ServiceOverrideImpl.java:31) via
> org.apache.tapestry5.ioc.services.TapestryIOCModule.bind(ServiceBinder) (at
> TapestryIOCModule.java:49) for references to another service that is itself
> dependent on service 'ServiceOverride'.
> {code}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Created] (TAP5-2208) BeanEditForm doesn't generate form-group DIVs with block parameters
Lenny Primak created TAP5-2208:
--
Summary: BeanEditForm doesn't generate form-group DIVs with block
parameters
Key: TAP5-2208
URL: https://issues.apache.org/jira/browse/TAP5-2208
Project: Tapestry 5
Issue Type: Bug
Components: tapestry-core
Affects Versions: 5.4
Reporter: Lenny Primak
When using BeanEditForm with block parameters, i.e.
{{{
Create Text Record?
}}}
div class=form-group is the proper boostrap markup,
but it's not being generated.
When block parameters are not used, the form-group DIVs
are generated correctly
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (TAP5-2196) RequireJs custom path contribution - via Stacks or JavaScriptSupport
[
https://issues.apache.org/jira/browse/TAP5-2196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13795689#comment-13795689
]
Lenny Primak commented on TAP5-2196:
For AMD, if module paths are the same, and they are used twice, that is
actually supported by requireJS,
and will be handled correctly.
Also, as you said, JQueryUI being loaded prior to JQuery wouldn't happen in
this case.
> RequireJs custom path contribution - via Stacks or JavaScriptSupport
>
>
> Key: TAP5-2196
> URL: https://issues.apache.org/jira/browse/TAP5-2196
> Project: Tapestry 5
> Issue Type: Improvement
> Components: tapestry-core
>Affects Versions: 5.4
>Reporter: Magnus Kvalheim
> Labels: requirejs
>
> Currently I think there is no way to configure requirejs paths.
> Also - the requirejs config is 'global' and all entries included on every
> page.
> Would be good improvement if there were some more flexibility in config and
> more contributions was possible.
> --
> As part of 5.4 migration process we have some components that make use of
> JQueryFileUpload, https://github.com/blueimp/jQuery-File-Upload .
> This library uses the factory approach for defining the modules to work in
> both AMD and non AMD environments.
> Internally it handles loading of required modules, but work with paths. (And
> does not try to load from a fixed directory structure).
> So I think I need to specify things like
> requirejs.config({
> paths: {
> 'jquery.fileupload':
> '../library/jquery.fileupload/jquery.fileupload', //path to file
> 'jquery.iframe-transport':
> '../library/jquery.fileupload/jquery.iframe-transport', //path to file
> 'jquery.ui.widget':
> '../library/jquery.fileupload/vendor/jquery.ui.widget', //path to file
> }
> });
> Currently, only option is to configure shims through tapestry's
> modulemanager, but that's for non-AMD scripts and is likely to cause problems.
> Also the shim config would be global (all pages) - which I'd like to avoid as
> well.
> In 5.3 I've used a JQueryFileUpload to define all the deps like so..
> public List getJavaScriptLibraries() {
> List ret = new ArrayList();
>
> ret.add(assetSource.getContextAsset("jquery-file-upload/7.2.1/js/vendor/jquery.ui.widget.js",
> null));
>
> ret.add(assetSource.getContextAsset("jquery-file-upload/extra/js/load-image.min.js",
> null));
>
> ret.add(assetSource.getContextAsset("jquery-file-upload/extra/js/canvas-to-blob.min.js",
> null));
>
> ret.add(assetSource.getContextAsset("jquery-file-upload/7.2.1/js/jquery.iframe-transport.js",
> null));
>
> ret.add(assetSource.getContextAsset("jquery-file-upload/7.2.1/js/jquery.fileupload.js",
> null));
>
> ret.add(assetSource.getContextAsset("jquery-file-upload/7.2.1/js/jquery.fileupload-fp.js",
> null));
> It would be useful it was possible somehow to contribute to requirejs
> configuration through stacks.
> That way they could be added to the requirejs config if the stack was used.
> If it was a service (perhaps exposed through JavaScriptSupport) one could
> also contribute on a page/component level..?
> I have no idea about the implications of this and if it's possible to
> accomplish, but could potentially help solving some more advanced use cases.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (TAP5-2196) RequireJs custom path contribution - via Stacks or JavaScriptSupport
[
https://issues.apache.org/jira/browse/TAP5-2196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13795344#comment-13795344
]
Lenny Primak commented on TAP5-2196:
Never mind... you probably have paths relative to your own web site,
so you don't know the exact path ahead of time
> RequireJs custom path contribution - via Stacks or JavaScriptSupport
>
>
> Key: TAP5-2196
> URL: https://issues.apache.org/jira/browse/TAP5-2196
> Project: Tapestry 5
> Issue Type: Improvement
> Components: tapestry-core
>Affects Versions: 5.4
>Reporter: Magnus Kvalheim
> Labels: requirejs
>
> Currently I think there is no way to configure requirejs paths.
> Also - the requirejs config is 'global' and all entries included on every
> page.
> Would be good improvement if there were some more flexibility in config and
> more contributions was possible.
> --
> As part of 5.4 migration process we have some components that make use of
> JQueryFileUpload, https://github.com/blueimp/jQuery-File-Upload .
> This library uses the factory approach for defining the modules to work in
> both AMD and non AMD environments.
> Internally it handles loading of required modules, but work with paths. (And
> does not try to load from a fixed directory structure).
> So I think I need to specify things like
> requirejs.config({
> paths: {
> 'jquery.fileupload':
> '../library/jquery.fileupload/jquery.fileupload', //path to file
> 'jquery.iframe-transport':
> '../library/jquery.fileupload/jquery.iframe-transport', //path to file
> 'jquery.ui.widget':
> '../library/jquery.fileupload/vendor/jquery.ui.widget', //path to file
> }
> });
> Currently, only option is to configure shims through tapestry's
> modulemanager, but that's for non-AMD scripts and is likely to cause problems.
> Also the shim config would be global (all pages) - which I'd like to avoid as
> well.
> In 5.3 I've used a JQueryFileUpload to define all the deps like so..
> public List getJavaScriptLibraries() {
> List ret = new ArrayList();
>
> ret.add(assetSource.getContextAsset("jquery-file-upload/7.2.1/js/vendor/jquery.ui.widget.js",
> null));
>
> ret.add(assetSource.getContextAsset("jquery-file-upload/extra/js/load-image.min.js",
> null));
>
> ret.add(assetSource.getContextAsset("jquery-file-upload/extra/js/canvas-to-blob.min.js",
> null));
>
> ret.add(assetSource.getContextAsset("jquery-file-upload/7.2.1/js/jquery.iframe-transport.js",
> null));
>
> ret.add(assetSource.getContextAsset("jquery-file-upload/7.2.1/js/jquery.fileupload.js",
> null));
>
> ret.add(assetSource.getContextAsset("jquery-file-upload/7.2.1/js/jquery.fileupload-fp.js",
> null));
> It would be useful it was possible somehow to contribute to requirejs
> configuration through stacks.
> That way they could be added to the requirejs config if the stack was used.
> If it was a service (perhaps exposed through JavaScriptSupport) one could
> also contribute on a page/component level..?
> I have no idea about the implications of this and if it's possible to
> accomplish, but could potentially help solving some more advanced use cases.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (TAP5-2196) RequireJs custom path contribution - via Stacks or JavaScriptSupport
[
https://issues.apache.org/jira/browse/TAP5-2196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13795329#comment-13795329
]
Lenny Primak commented on TAP5-2196:
Why do you need paths for AMD modules?
Its nice to have but not a requirement.
You can just define the dependency directly like this: (example)
http://code.google.com/p/flowlogix/source/browse/tapestry-services/src/main/resources/META-INF/modules/flowlogix/HighlightEffect.js?name=tapestry-5.4
jquery-ui is non AMD (but it works)
and should work for AMD modules even better
> RequireJs custom path contribution - via Stacks or JavaScriptSupport
>
>
> Key: TAP5-2196
> URL: https://issues.apache.org/jira/browse/TAP5-2196
> Project: Tapestry 5
> Issue Type: Improvement
> Components: tapestry-core
>Affects Versions: 5.4
>Reporter: Magnus Kvalheim
> Labels: requirejs
>
> Currently I think there is no way to configure requirejs paths.
> Also - the requirejs config is 'global' and all entries included on every
> page.
> Would be good improvement if there were some more flexibility in config and
> more contributions was possible.
> --
> As part of 5.4 migration process we have some components that make use of
> JQueryFileUpload, https://github.com/blueimp/jQuery-File-Upload .
> This library uses the factory approach for defining the modules to work in
> both AMD and non AMD environments.
> Internally it handles loading of required modules, but work with paths. (And
> does not try to load from a fixed directory structure).
> So I think I need to specify things like
> requirejs.config({
> paths: {
> 'jquery.fileupload':
> '../library/jquery.fileupload/jquery.fileupload', //path to file
> 'jquery.iframe-transport':
> '../library/jquery.fileupload/jquery.iframe-transport', //path to file
> 'jquery.ui.widget':
> '../library/jquery.fileupload/vendor/jquery.ui.widget', //path to file
> }
> });
> Currently, only option is to configure shims through tapestry's
> modulemanager, but that's for non-AMD scripts and is likely to cause problems.
> Also the shim config would be global (all pages) - which I'd like to avoid as
> well.
> In 5.3 I've used a JQueryFileUpload to define all the deps like so..
> public List getJavaScriptLibraries() {
> List ret = new ArrayList();
>
> ret.add(assetSource.getContextAsset("jquery-file-upload/7.2.1/js/vendor/jquery.ui.widget.js",
> null));
>
> ret.add(assetSource.getContextAsset("jquery-file-upload/extra/js/load-image.min.js",
> null));
>
> ret.add(assetSource.getContextAsset("jquery-file-upload/extra/js/canvas-to-blob.min.js",
> null));
>
> ret.add(assetSource.getContextAsset("jquery-file-upload/7.2.1/js/jquery.iframe-transport.js",
> null));
>
> ret.add(assetSource.getContextAsset("jquery-file-upload/7.2.1/js/jquery.fileupload.js",
> null));
>
> ret.add(assetSource.getContextAsset("jquery-file-upload/7.2.1/js/jquery.fileupload-fp.js",
> null));
> It would be useful it was possible somehow to contribute to requirejs
> configuration through stacks.
> That way they could be added to the requirejs config if the stack was used.
> If it was a service (perhaps exposed through JavaScriptSupport) one could
> also contribute on a page/component level..?
> I have no idea about the implications of this and if it's possible to
> accomplish, but could potentially help solving some more advanced use cases.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (TAP5-2182) BeanEditor doesn't look as good in T5.4 as in T5.3
[ https://issues.apache.org/jira/browse/TAP5-2182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13794698#comment-13794698 ] Lenny Primak commented on TAP5-2182: As pointed in this discussion: http://apache-tapestry-mailing-list-archives.1045711.n5.nabble.com/T5-4-BeanEditor-and-Friends-don-t-look-as-good-as-in-Tap-5-3-td5723435.html Bootstrap .form-horizontal class should fix the issue, provided Tapestry produces the correct markup (which it doesn't at the moment) Tapestry needs to wrap each field in bootstrap col-xx-x s Also, BeanEditor should be enhanced to support form-horizontal and form-inline out of the box. > BeanEditor doesn't look as good in T5.4 as in T5.3 > -- > > Key: TAP5-2182 > URL: https://issues.apache.org/jira/browse/TAP5-2182 > Project: Tapestry 5 > Issue Type: Bug > Components: tapestry-core >Affects Versions: 5.4 >Reporter: Lenny Primak > > I noticed something else that's not as pretty out of the box in T5.4 due to > bootstrap probably > In T5.3, beaneditor looks something like this (pretty): > Label [Input Text/Date/etc] > Label [Input Text/Date/etc] > In T5.4, it looks like this (not so pretty or usable): > Label > [Input Text/Date/etc (takes up the whole width of the page)] > Label > [Input Text/Date/etc (takes up the whole width of the page)] > I think this should be fixed out of the box -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (TAP5-2170) constructAssetPath() requires use of internal service
[ https://issues.apache.org/jira/browse/TAP5-2170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lenny Primak updated TAP5-2170: --- Priority: Minor (was: Major) > constructAssetPath() requires use of internal service > - > > Key: TAP5-2170 > URL: https://issues.apache.org/jira/browse/TAP5-2170 > Project: Tapestry 5 > Issue Type: Bug > Components: tapestry-core >Affects Versions: 5.4 >Reporter: Lenny Primak >Priority: Minor > > Since 5.4, constructAssetPath requires an argument that not easily obtained, > and requires a use of internal API. > Thread: > http://apache-tapestry-mailing-list-archives.1045711.n5.nabble.com/T5-4-Alpha-15-constructAssetPath-changes-td5723188.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TAP5-2182) BeanEditor doesn't look as good in T5.4 as in T5.3
[ https://issues.apache.org/jira/browse/TAP5-2182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13777172#comment-13777172 ] Lenny Primak commented on TAP5-2182: Bootstrap 3 has a class .form-inline to fix the old layout Unfortunately, Datepicker calendar button is still misaligned, and if it exists, it misaligns the whole bean editor. This is because Tapestry puts .input-group-btn class on it. I believe its a vestige of bootstrap 2, and breaks the layout yet again. This issue should be linked with the date picker issue. > BeanEditor doesn't look as good in T5.4 as in T5.3 > -- > > Key: TAP5-2182 > URL: https://issues.apache.org/jira/browse/TAP5-2182 > Project: Tapestry 5 > Issue Type: Bug > Components: tapestry-core >Affects Versions: 5.4 >Reporter: Lenny Primak > > I noticed something else that's not as pretty out of the box in T5.4 due to > bootstrap probably > In T5.3, beaneditor looks something like this (pretty): > Label [Input Text/Date/etc] > Label [Input Text/Date/etc] > In T5.4, it looks like this (not so pretty or usable): > Label > [Input Text/Date/etc (takes up the whole width of the page)] > Label > [Input Text/Date/etc (takes up the whole width of the page)] > I think this should be fixed out of the box -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TAP5-2187) CSS relative URL rewriting isn't lenient enough
Lenny Primak created TAP5-2187: -- Summary: CSS relative URL rewriting isn't lenient enough Key: TAP5-2187 URL: https://issues.apache.org/jira/browse/TAP5-2187 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.4 Reporter: Lenny Primak I am trying to integrate an existing GWT framework as tapestry components. One of the .css files its trying to load references an non-existent .png file. Instead of just ignoring it, Tapestry produces a 500 error loading the .css file, which I don't believe there is a workaround for. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TAP5-2185) Problem with the asset checksums and relative paths based on them
Lenny Primak created TAP5-2185: -- Summary: Problem with the asset checksums and relative paths based on them Key: TAP5-2185 URL: https://issues.apache.org/jira/browse/TAP5-2185 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.4 Reporter: Lenny Primak When JavaScript modules reference other (non-tapestry) JS code via relative paths, or absolute paths that have to be configured, the checksum is preventing the other resources from being accessed properly Discussion regarding this can be found here: http://apache-tapestry-mailing-list-archives.1045711.n5.nabble.com/Re-5-4-Problems-with-the-asset-checksums-and-relative-paths-based-on-them-td5723366.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TAP5-2182) BeanEditor doesn't look as good in T5.4 as in T5.3
[ https://issues.apache.org/jira/browse/TAP5-2182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13768556#comment-13768556 ] Lenny Primak commented on TAP5-2182: >From User Experience point of view (I already did an informal study with my >clients) they like the old way much better. Also, if you look at most of the web site forms, the 'new' way isn't as good. Also, from the compatibility point of view, I think the form style should remain the more usable (current) one rather than the label on a separate line. > BeanEditor doesn't look as good in T5.4 as in T5.3 > -- > > Key: TAP5-2182 > URL: https://issues.apache.org/jira/browse/TAP5-2182 > Project: Tapestry 5 > Issue Type: Bug > Components: tapestry-core >Affects Versions: 5.4 >Reporter: Lenny Primak > > I noticed something else that's not as pretty out of the box in T5.4 due to > bootstrap probably > In T5.3, beaneditor looks something like this (pretty): > Label [Input Text/Date/etc] > Label [Input Text/Date/etc] > In T5.4, it looks like this (not so pretty or usable): > Label > [Input Text/Date/etc (takes up the whole width of the page)] > Label > [Input Text/Date/etc (takes up the whole width of the page)] > I think this should be fixed out of the box -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TAP5-2182) BeanEditor doesn't look as good in T5.4 as in T5.3
Lenny Primak created TAP5-2182: -- Summary: BeanEditor doesn't look as good in T5.4 as in T5.3 Key: TAP5-2182 URL: https://issues.apache.org/jira/browse/TAP5-2182 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.4 Reporter: Lenny Primak I noticed something else that's not as pretty out of the box in T5.4 due to bootstrap probably In T5.3, beaneditor looks something like this (pretty): Label [Input Text/Date/etc] Label [Input Text/Date/etc] In T5.4, it looks like this (not so pretty or usable): Label [Input Text/Date/etc (takes up the whole width of the page)] Label [Input Text/Date/etc (takes up the whole width of the page)] I think this should be fixed out of the box -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TAP5-2158) Client-side validation of @Size is not working when only min or max is set
[
https://issues.apache.org/jira/browse/TAP5-2158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13762044#comment-13762044
]
Lenny Primak commented on TAP5-2158:
I would say this is a critical bug, not minor.
> Client-side validation of @Size is not working when only min or max is set
> --
>
> Key: TAP5-2158
> URL: https://issues.apache.org/jira/browse/TAP5-2158
> Project: Tapestry 5
> Issue Type: Bug
> Components: tapestry-beanvalidator
>Affects Versions: 5.4
>Reporter: Balázs Palcsó
>Priority: Minor
>
> Exact version: 5.4-alpha-14
> Server side example:
> {code}
> @Size(min = 3)
> private String name;
> {code}
> On the client side the following function gets executed:
> {code}
> doRangeValidate = function(element, value, memo) {
> var max, min;
> min = rangeValue(element, "data-range-min", 0);
> max = rangeValue(element, "data-range-max", Number.MAX_VALUE);
> if (_.isString(value)) {
> value = value.length;
> }
> if (!((min <= value && value <= max))) {
> memo.error = (element.attribute("data-range-message")) || "RANGE
> ERROR";
> return false;
> }
> return true;
> };
> {code}
> In the above example max is evaluated to NaN and therefore the function
> returns false causing validation error.
> Same applies when you only max is specified in @Size annotation and min is
> evaluated to NaN.
> h3. Workaround
> Specify both min and max.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (TAP5-1730) Ajax Zone is improperly reloaded when a mixin submits form via JavaScript
[ https://issues.apache.org/jira/browse/TAP5-1730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lenny Primak closed TAP5-1730. -- Resolution: Fixed Fix Version/s: 5.4 Since form submission was rewritten in 5.4, there is no need to call submit directly, so this problem is gone > Ajax Zone is improperly reloaded when a mixin submits form via JavaScript > - > > Key: TAP5-1730 > URL: https://issues.apache.org/jira/browse/TAP5-1730 > Project: Tapestry 5 > Issue Type: Bug > Components: tapestry-core >Affects Versions: 5.3, 5.4 >Reporter: Lenny Primak >Priority: Minor > Fix For: 5.4 > > > Tapestry reloads the zone improperly if JS code > Improperly submits the form. It should at least give some kind of an error > or a warning when happens. > Right now, it fails silently leading to an improper zone reload, > which leads to weird errors when app is running subsequently. > If form..setSubmittingElement(() isn't called before form.onsubmit(), > the Tapestry silently fails and the zone is improperly reloaded. > --- > There was an addition of one line: > $(this.formId).setSubmittingElement($(this.elementId)); // *** ADDED > otherwise zone gets improperly reloaded > $(this.formId).onsubmit(); // Submit Ajax form > If you don't add the first line, the form is reloaded improperly after the > zone update, > so it doesn't work the second time. > This is not documented anywhere, and really hard to debug. > See threads: > http://mail-archives.apache.org/mod_mbox/tapestry-users/201110.mbox/%3c21cb9971-ed77-4f37-9c72-501d0f513...@hope.nyc.ny.us%3E > http://tapestry.1045711.n5.nabble.com/Mixins-stop-working-after-a-zone-update-please-help-td4935912.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TAP5-2175) Bean Validation fails when @Size(min) is not specified but max is specified
Lenny Primak created TAP5-2175: -- Summary: Bean Validation fails when @Size(min) is not specified but max is specified Key: TAP5-2175 URL: https://issues.apache.org/jira/browse/TAP5-2175 Project: Tapestry 5 Issue Type: Bug Components: tapestry-beanvalidator Affects Versions: 5.4 Reporter: Lenny Primak Priority: Critical beanvalidator-validation.js has a bug in rangeValue() if(v===null) // should be if(v==null) In the current state, it will return undefined if @Size(min) is not present, thus failing for perfectly valid input -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TAP5-1408) datefield popup does not have option to cancel
[ https://issues.apache.org/jira/browse/TAP5-1408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13759822#comment-13759822 ] Lenny Primak commented on TAP5-1408: This ticket should be re-opened (T5.4-alpha) Users are required to click on the little calendar button in order to cancel the datepicker. This isn't good usability-wise. They should be able to click anywhere on the page > datefield popup does not have option to cancel > -- > > Key: TAP5-1408 > URL: https://issues.apache.org/jira/browse/TAP5-1408 > Project: Tapestry 5 > Issue Type: Bug >Affects Versions: 5.2.4 >Reporter: Paul Stanton >Assignee: Robert Zeigler > Fix For: 5.3 > > > using the datefield component, if a user changes their mind there seems to be > no way for them to close the popup without changing the value in some way. > once the icon has been clicked, there's no option to close the popup > explicitly and selecting the current value is disabled so the user has to > select another date to close the popup. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TAP5-2170) constructAssetPath() requires use of internal service
Lenny Primak created TAP5-2170: -- Summary: constructAssetPath() requires use of internal service Key: TAP5-2170 URL: https://issues.apache.org/jira/browse/TAP5-2170 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.4 Reporter: Lenny Primak Since 5.4, constructAssetPath requires an argument that not easily obtained, and requires a use of internal API. Thread: http://apache-tapestry-mailing-list-archives.1045711.n5.nabble.com/T5-4-Alpha-15-constructAssetPath-changes-td5723188.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TAP5-2169) Core stack is not included by default
Lenny Primak created TAP5-2169: -- Summary: Core stack is not included by default Key: TAP5-2169 URL: https://issues.apache.org/jira/browse/TAP5-2169 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.4 Reporter: Lenny Primak Priority: Minor For simple applications, "core" stack is not included, which breaks the UI, because bootstrap.css and other assets are not loaded. I think "core" stack should be forced to be included (possibly optionally turned off by config) but it should be included by default -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TAP5-2167) Asset location warnings are actually coded as errors
[ https://issues.apache.org/jira/browse/TAP5-2167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lenny Primak updated TAP5-2167: --- Summary: Asset location warnings are actually coded as errors (was: Ass location warnings are actually coded as errors) > Asset location warnings are actually coded as errors > > > Key: TAP5-2167 > URL: https://issues.apache.org/jira/browse/TAP5-2167 > Project: Tapestry 5 > Issue Type: Bug > Components: tapestry-core >Affects Versions: 5.4 >Reporter: Lenny Primak > > T5.4 is supposed to give out warnings when assets are in the classpath and > not in WEB-INF/assets/... directory. In reality its giving out errors (i.e. > logger.error()) instead, which is really annoying -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TAP5-2168) Asset Not Found messages are prompting to put assets into wrong location
Lenny Primak created TAP5-2168: -- Summary: Asset Not Found messages are prompting to put assets into wrong location Key: TAP5-2168 URL: https://issues.apache.org/jira/browse/TAP5-2168 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.4 Reporter: Lenny Primak When looking for assets in the T5.4 directory hierarchy, i.e. META-INF/assets/... if the file name does not match, the error given by Tapestry gives the old (classpath root) location which is very misleading and could lead to a lot of developer frustration. This should be fixed so the new T5.4 asset paths are suggested Here is the thread: http://apache-tapestry-mailing-list-archives.1045711.n5.nabble.com/T5-4-Import-library-xxx-doesn-t-work-for-META-INF-assset-xxx-assets-from-library-tp5723276.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TAP5-2167) Ass location warnings are actually coded as errors
Lenny Primak created TAP5-2167: -- Summary: Ass location warnings are actually coded as errors Key: TAP5-2167 URL: https://issues.apache.org/jira/browse/TAP5-2167 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.4 Reporter: Lenny Primak T5.4 is supposed to give out warnings when assets are in the classpath and not in WEB-INF/assets/... directory. In reality its giving out errors (i.e. logger.error()) instead, which is really annoying -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TAP5-2070) Respond with a HTTP 404 if the page is activated with an activation context not explicitly supported by the page itself
[
https://issues.apache.org/jira/browse/TAP5-2070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13725340#comment-13725340
]
Lenny Primak commented on TAP5-2070:
I would love to get this fix incorporated. I currently use this code in the
index page to work around this issue:
8 /**
9* Restore 404 Not Found errors
10 * @param context
11 * @return
12 */
13 HttpError onActivate(EventContext context)
14 {
15 if (context.getCount() == 0)
16 {
17 return null;
18 }
19
20 return new HttpError(404, "Resource not found.");
21 }
> Respond with a HTTP 404 if the page is activated with an activation context
> not explicitly supported by the page itself
> ---
>
> Key: TAP5-2070
> URL: https://issues.apache.org/jira/browse/TAP5-2070
> Project: Tapestry 5
> Issue Type: Improvement
> Components: tapestry-core
>Affects Versions: 5.4
>Reporter: Massimo Lusetti
>Assignee: Massimo Lusetti
> Attachments:
> 0001-TAP5-2070-Implement-logic-for-recognize-requests-to-.patch
>
>
> The behavior from day one for pages within Tapestry is to being able to serve
> requests that come with an activation context with more parameters that the
> ones declared by the page itself.
> This feature lead the framework to serve requests that comes to URL which are
> not explicitly declared by the pages, for example a page named: Super with an
> activation event handler method like this one:
> onActivate(String character) { ... }
> will finely serve requests for:
> /super/mario
> /super/luigi
> /super/wario
> /super/waluigi
> but it will also serve requests for:
> /super/mario/luigi/wario/waluigi
> This issue is to change that behavior.
> If the page does declare a specific activation event handler method the
> corresponding serving URLs should adhere strictly, otherwise a HTTP 404 is
> raised.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TAP5-1730) Ajax Zone is improperly reloaded when a mixin submits form via JavaScript
[ https://issues.apache.org/jira/browse/TAP5-1730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13720450#comment-13720450 ] Lenny Primak commented on TAP5-1730: I will do this as part of port of FlowLogix to Tap 5.4. How soon that will happen is another story... > Ajax Zone is improperly reloaded when a mixin submits form via JavaScript > - > > Key: TAP5-1730 > URL: https://issues.apache.org/jira/browse/TAP5-1730 > Project: Tapestry 5 > Issue Type: Bug > Components: tapestry-core >Affects Versions: 5.3, 5.4 >Reporter: Lenny Primak >Priority: Minor > > Tapestry reloads the zone improperly if JS code > Improperly submits the form. It should at least give some kind of an error > or a warning when happens. > Right now, it fails silently leading to an improper zone reload, > which leads to weird errors when app is running subsequently. > If form..setSubmittingElement(() isn't called before form.onsubmit(), > the Tapestry silently fails and the zone is improperly reloaded. > --- > There was an addition of one line: > $(this.formId).setSubmittingElement($(this.elementId)); // *** ADDED > otherwise zone gets improperly reloaded > $(this.formId).onsubmit(); // Submit Ajax form > If you don't add the first line, the form is reloaded improperly after the > zone update, > so it doesn't work the second time. > This is not documented anywhere, and really hard to debug. > See threads: > http://mail-archives.apache.org/mod_mbox/tapestry-users/201110.mbox/%3c21cb9971-ed77-4f37-9c72-501d0f513...@hope.nyc.ny.us%3E > http://tapestry.1045711.n5.nabble.com/Mixins-stop-working-after-a-zone-update-please-help-td4935912.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TAP5-707) Yellow highlight remains on updated zone if zone is re-updated too quickly
[ https://issues.apache.org/jira/browse/TAP5-707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13707895#comment-13707895 ] Lenny Primak commented on TAP5-707: --- The FlowLogix tapestry library will contain a fix for this bug in the next release. (1.2.3) which will go out sometime in the next week or so. Ref: FlowLogix Issue http://code.google.com/p/flowlogix/issues/detail?id=43 This is already available as a snapshot release > Yellow highlight remains on updated zone if zone is re-updated too quickly > -- > > Key: TAP5-707 > URL: https://issues.apache.org/jira/browse/TAP5-707 > Project: Tapestry 5 > Issue Type: Bug > Components: tapestry-core >Affects Versions: 5.2, 5.1.0.5 >Reporter: Paul Field >Assignee: Ulrich Stärk > Fix For: 5.2.0, 5.1.0.8 > > Original Estimate: 0h > Remaining Estimate: 0h > > By default when a zone updates it shows a yellow highlight that fades away. > However, if the zone is updated before the highlight has completely faded > then the highlight remains (until the page is completely refreshed). > To see this in action, go to the JumpStart demo application: > http://jumpstart.doublenegative.com.au:8080/jumpstart/examples/javascript/ajax > And *double*-click the link "Refresh time2 only - this is an AJAX-enabled > ActionLink". > (Although JumpStart is currently based on T5.0.18 we see the same behaviour > on T5.1.0.5) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TAP5-2014) Zone highlight leaves behind an explicit background-color which overrides css background-color
[
https://issues.apache.org/jira/browse/TAP5-2014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13707894#comment-13707894
]
Lenny Primak commented on TAP5-2014:
The FlowLogix tapestry library will contain a fix for this bug in the next
release. (1.2.3)
which will go out sometime in the next week or so.
Ref: FlowLogix Issue http://code.google.com/p/flowlogix/issues/detail?id=43
> Zone highlight leaves behind an explicit background-color which overrides css
> background-color
> --
>
> Key: TAP5-2014
> URL: https://issues.apache.org/jira/browse/TAP5-2014
> Project: Tapestry 5
> Issue Type: Bug
> Components: tapestry-core
>Affects Versions: 5.3.6
>Reporter: Geoff Callender
>
> Zone highlighter (i.e. t:update="highlight") leaves behind an explicit
> background-color that overrides the background-color specified in css.
> Instead, I think it should finish by removing the style changes that it added.
> An example consequence: it kills off my hover effect. I have a table row with
> a hover effect, eg.
> tr { background-color: #fff; }
> tr:hover { background-color: #eee; }
> and the row is also a zone with a highlight effect
> t:update="highlight">
> The hover effect works just fine until the zone updates, and then it no
> longer works.
> Here's the row before the zone updates:
>
> Here's the row after the zone updates:
> style="background-image: none; background-color: rgb(255, 255, 255); ">
> The problem would go away if the zone update finished by leaving the row the
> way that it found it:
>
> You can see the problem if you turn on "Highlight zone updates" in this
> example:
>
> http://jumpstart.doublenegative.com.au/jumpstart/examples/ajax/eventlinksinaloop
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (TAP5-2014) Zone highlight leaves behind an explicit background-color which overrides css background-color
[
https://issues.apache.org/jira/browse/TAP5-2014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13707894#comment-13707894
]
Lenny Primak edited comment on TAP5-2014 at 7/14/13 1:11 AM:
-
The FlowLogix tapestry library will contain a fix for this bug in the next
release. (1.2.3)
which will go out sometime in the next week or so.
Ref: FlowLogix Issue http://code.google.com/p/flowlogix/issues/detail?id=43
This is already available as a snapshot release
was (Author: lprimak):
The FlowLogix tapestry library will contain a fix for this bug in the next
release. (1.2.3)
which will go out sometime in the next week or so.
Ref: FlowLogix Issue http://code.google.com/p/flowlogix/issues/detail?id=43
> Zone highlight leaves behind an explicit background-color which overrides css
> background-color
> --
>
> Key: TAP5-2014
> URL: https://issues.apache.org/jira/browse/TAP5-2014
> Project: Tapestry 5
> Issue Type: Bug
> Components: tapestry-core
>Affects Versions: 5.3.6
>Reporter: Geoff Callender
>
> Zone highlighter (i.e. t:update="highlight") leaves behind an explicit
> background-color that overrides the background-color specified in css.
> Instead, I think it should finish by removing the style changes that it added.
> An example consequence: it kills off my hover effect. I have a table row with
> a hover effect, eg.
> tr { background-color: #fff; }
> tr:hover { background-color: #eee; }
> and the row is also a zone with a highlight effect
> t:update="highlight">
> The hover effect works just fine until the zone updates, and then it no
> longer works.
> Here's the row before the zone updates:
>
> Here's the row after the zone updates:
> style="background-image: none; background-color: rgb(255, 255, 255); ">
> The problem would go away if the zone update finished by leaving the row the
> way that it found it:
>
> You can see the problem if you turn on "Highlight zone updates" in this
> example:
>
> http://jumpstart.doublenegative.com.au/jumpstart/examples/ajax/eventlinksinaloop
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TAP5-1892) FormFragment validates non-displayed fragments (reopen)
[ https://issues.apache.org/jira/browse/TAP5-1892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13606057#comment-13606057 ] Lenny Primak commented on TAP5-1892: Has there been any progress on this issue? I think we are running into it. > FormFragment validates non-displayed fragments (reopen) > --- > > Key: TAP5-1892 > URL: https://issues.apache.org/jira/browse/TAP5-1892 > Project: Tapestry 5 > Issue Type: Bug > Components: tapestry-core >Affects Versions: 5.2.1, 5.2.3 >Reporter: Beat Durrer > > (The Issue TAP5-410 is closed, I cannot reopen it) > Fields in FormFragments still get validated when using IE7. > Testcase: > - go to > http://jumpstart.doublenegative.com.au/jumpstart/examples/wizard/usingformfragments/ > - Enter any amount bigger than zero > - The validation for a field of a hidden FormFragment displays an error > message -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TAP5-1779) Tapestry allows directory listing of assets via client browser
[
https://issues.apache.org/jira/browse/TAP5-1779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13504856#comment-13504856
]
Lenny Primak commented on TAP5-1779:
Updated the code to fix the problem with directory listings.
The latest code is always available at:
http://code.google.com/p/flowlogix/source/browse/tapestry-services/src/main/java/com/flowlogix/web/services/SecurityModule.java#70
> Tapestry allows directory listing of assets via client browser
> --
>
> Key: TAP5-1779
> URL: https://issues.apache.org/jira/browse/TAP5-1779
> Project: Tapestry 5
> Issue Type: Bug
> Components: tapestry-core
>Affects Versions: 5.3.1, 5.3, 5.4
>Reporter: Lenny Primak
>
> You can access asset directory listing by going to Tapestry web site
> http://.../assets/{version}/ctx/
> This should be disallowed.
> Here is a Nabble discussion about this:
> http://tapestry.1045711.n5.nabble.com/T5-3-do-we-still-need-AssetProtectionDispatcher-td5055048.html
> I have a fix for this in the flowlogix tapestry library:
> http://code.google.com/p/flowlogix/source/browse/tapestry-services/src/main/java/com/flowlogix/web/services/SecurityModule.java#70
> --- fix for the code
> /**
> * See https://issues.apache.org/jira/browse/TAP5-1779";
> target="_blank">TAP5-1779
> */
> @Contribute(RequestHandler.class)
> public void disableAssetDirListing(OrderedConfiguration
> configuration,
> @Symbol(SymbolConstants.APPLICATION_VERSION) final String
> applicationVersion,
> final Context ctxt)
> {
> configuration.add("DisableDirListing", new RequestFilter() {
> @Override
> public boolean service(Request request, Response response,
> RequestHandler handler) throws IOException
> {
> final String assetFolder = assetPathPrefix +
> applicationVersion + "/"
> + RequestConstants.CONTEXT_FOLDER;
> if (request.getPath().startsWith(assetFolder))
> {
> if(request.getPath().endsWith("/") ||
>
> ctxt.getRealFile(pathProcessor.removeAssetPathPart(
> request.getPath())).isDirectory())
> {
> return false;
> }
> }
> return handler.service(request, response);
> }
> }, "before:AssetDispatcher");
> }
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TAP5-1779) Tapestry allows directory listing of assets via client browser
[
https://issues.apache.org/jira/browse/TAP5-1779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lenny Primak updated TAP5-1779:
---
Description:
You can access asset directory listing by going to Tapestry web site
http://.../assets/{version}/ctx/
This should be disallowed.
Here is a Nabble discussion about this:
http://tapestry.1045711.n5.nabble.com/T5-3-do-we-still-need-AssetProtectionDispatcher-td5055048.html
I have a fix for this in the flowlogix tapestry library:
http://code.google.com/p/flowlogix/source/browse/tapestry-services/src/main/java/com/flowlogix/web/services/SecurityModule.java#70
--- fix for the code
/**
* See https://issues.apache.org/jira/browse/TAP5-1779";
target="_blank">TAP5-1779
*/
@Contribute(RequestHandler.class)
public void disableAssetDirListing(OrderedConfiguration
configuration,
@Symbol(SymbolConstants.APPLICATION_VERSION) final String
applicationVersion,
final Context ctxt)
{
configuration.add("DisableDirListing", new RequestFilter() {
@Override
public boolean service(Request request, Response response,
RequestHandler handler) throws IOException
{
final String assetFolder = assetPathPrefix + applicationVersion
+ "/"
+ RequestConstants.CONTEXT_FOLDER;
if (request.getPath().startsWith(assetFolder))
{
if(request.getPath().endsWith("/") ||
ctxt.getRealFile(pathProcessor.removeAssetPathPart(
request.getPath())).isDirectory())
{
return false;
}
}
return handler.service(request, response);
}
}, "before:AssetDispatcher");
}
was:
You can access asset directory listing by going to Tapestry web site
http://.../assets/{version}/ctx/
This should be disallowed.
Here is a Nabble discussion about this:
http://tapestry.1045711.n5.nabble.com/T5-3-do-we-still-need-AssetProtectionDispatcher-td5055048.html
I have a fix for this in the flowlogix tapestry library:
http://code.google.com/p/flowlogix/source/browse/tapestry-services/src/main/java/com/flowlogix/web/services/SecurityModule.java#70
--- fix for the code
@Contribute(RequestHandler.class)
public void disableAssetDirListing(OrderedConfiguration
configuration,
@Symbol(SymbolConstants.APPLICATION_VERSION) final String
applicationVersion)
{
configuration.add("DisableDirListing", new RequestFilter() {
@Override
public boolean service(Request request, Response response,
RequestHandler handler) throws IOException
{
final String assetFolder = RequestConstants.ASSET_PATH_PREFIX +
applicationVersion + "/" +
RequestConstants.CONTEXT_FOLDER;
if(request.getPath().startsWith(assetFolder) &&
request.getPath().endsWith("/"))
{
return false;
}
else
{
return handler.service(request, response);
}
}
}, "before:AssetDispatcher");
}
> Tapestry allows directory listing of assets via client browser
> --
>
> Key: TAP5-1779
> URL: https://issues.apache.org/jira/browse/TAP5-1779
> Project: Tapestry 5
> Issue Type: Bug
> Components: tapestry-core
>Affects Versions: 5.3.1, 5.3, 5.4
>Reporter: Lenny Primak
>
> You can access asset directory listing by going to Tapestry web site
> http://.../assets/{version}/ctx/
> This should be disallowed.
> Here is a Nabble discussion about this:
> http://tapestry.1045711.n5.nabble.com/T5-3-do-we-still-need-AssetProtectionDispatcher-td5055048.html
> I have a fix for this in the flowlogix tapestry library:
> http://code.google.com/p/flowlogix/source/browse/tapestry-services/src/main/java/com/flowlogix/web/services/SecurityModule.java#70
> --- fix for the code
> /**
> * See https://issues.apache.org/jira/browse/TAP5-1779";
> target="_blank">TAP5-1779
> */
> @Contribute(RequestHandler.class)
> public void disableAssetDirListing(OrderedConfiguration
> configuration,
> @Symbol(SymbolConstants.APPLICATION_VERSION) final String
> applicationVersion,
> final Context ctxt)
> {
> configuration.add("DisableDirListing", new RequestFilter() {
> @Override
> public boolean service(Request request, Response response,
> RequestHandler handler) throw
[jira] [Commented] (TAP5-2027) EntityManagerObjectProvider always provides the initial EntityManger proxy created
[
https://issues.apache.org/jira/browse/TAP5-2027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13498317#comment-13498317
]
Lenny Primak commented on TAP5-2027:
I can reproduce the problem with your code.
DAO injection does not work properly,
while direct injection into pages/components of @PersisgentContext does work.
I still don't see how this fix can possibly work.
> EntityManagerObjectProvider always provides the initial EntityManger proxy
> created
> --
>
> Key: TAP5-2027
> URL: https://issues.apache.org/jira/browse/TAP5-2027
> Project: Tapestry 5
> Issue Type: Bug
> Components: tapestry-jpa
>Affects Versions: 5.3.5, 5.3.6
>Reporter: John Coleman
> Labels: patch
> Attachments: TapestryJPATest.zip
>
>
> When persistence.xml defines multiple persistence units, classes injecting
> EntityManager with @PersistenceContext(unitName=value crash because the
> entities associated with the PU in configuration are not recognised at
> runtime.
> By placing trace in the code I established that the first EntityManager
> injected gets injected to all my other service classes even though I use
> different unitName= annotations.
> The EntityManagerObjectProvider class contains a class variable proxy and
> works like a singleton always injecting the first EntityManager proxy class
> created for any later EntityManager injections.
> The following code fixes the issue and is provided as-is, free and without
> copyright or warranty. This is more like a refactor because I have also
> replaced some depricated code. As a patch it also works just to remove the
> proxy class member variable and the if (proxy == null) condition.
> package org.apache.tapestry5.internal.jpa;
> import javax.persistence.EntityManager;
> import javax.persistence.PersistenceContext;
> import org.apache.tapestry5.ioc.AnnotationProvider;
> import org.apache.tapestry5.ioc.ObjectCreator;
> import org.apache.tapestry5.ioc.ObjectLocator;
> import org.apache.tapestry5.ioc.ObjectProvider;
> import org.apache.tapestry5.ioc.services.PlasticProxyFactory;
> import org.apache.tapestry5.jpa.EntityManagerManager;
> /**
> * A patched version to use PlasticProxyFactory and not cache the
> EntityManager as a class member.
> * @author John Coleman
> */
> public class EntityManagerObjectProvider implements ObjectProvider
> {
> /**
> * {@inheritDoc}
> */
> public T provide(final Class objectType, final AnnotationProvider
> annotationProvider,
> final ObjectLocator locator)
> {
> if (objectType.equals(EntityManager.class))
> return objectType.cast(getOrCreateProxy(annotationProvider,
> locator));
> return null;
> }
> private synchronized EntityManager getOrCreateProxy(
> final AnnotationProvider annotationProvider, final ObjectLocator
> objectLocator)
> {
> final PlasticProxyFactory proxyFactory =
> objectLocator.getService("PlasticProxyFactory",
> PlasticProxyFactory.class);
> final PersistenceContext annotation = annotationProvider
> .getAnnotation(PersistenceContext.class);
> EntityManager proxy =
> proxyFactory.createProxy(EntityManager.class, new
> ObjectCreator()
> {
> public EntityManager createObject()
> {
> final EntityManagerManager entityManagerManager =
> objectLocator
> .getService(EntityManagerManager.class);
> return
> JpaInternalUtils.getEntityManager(entityManagerManager, annotation);
> }
> }, "");
> return proxy;
> }
> }
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TAP5-2027) EntityManagerObjectProvider always provides the initial EntityManger proxy created
[
https://issues.apache.org/jira/browse/TAP5-2027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13497167#comment-13497167
]
Lenny Primak commented on TAP5-2027:
I just tested that second scenario, without DAOs, but a different PU on each
page directly injected into the page,
and that works fine.
The code you provided still should not make any difference.
> EntityManagerObjectProvider always provides the initial EntityManger proxy
> created
> --
>
> Key: TAP5-2027
> URL: https://issues.apache.org/jira/browse/TAP5-2027
> Project: Tapestry 5
> Issue Type: Bug
> Components: tapestry-jpa
>Affects Versions: 5.3.5, 5.3.6
>Reporter: John Coleman
> Labels: patch
>
> When persistence.xml defines multiple persistence units, classes injecting
> EntityManager with @PersistenceContext(unitName=value crash because the
> entities associated with the PU in configuration are not recognised at
> runtime.
> By placing trace in the code I established that the first EntityManager
> injected gets injected to all my other service classes even though I use
> different unitName= annotations.
> The EntityManagerObjectProvider class contains a class variable proxy and
> works like a singleton always injecting the first EntityManager proxy class
> created for any later EntityManager injections.
> The following code fixes the issue and is provided as-is, free and without
> copyright or warranty. This is more like a refactor because I have also
> replaced some depricated code. As a patch it also works just to remove the
> proxy class member variable and the if (proxy == null) condition.
> package org.apache.tapestry5.internal.jpa;
> import javax.persistence.EntityManager;
> import javax.persistence.PersistenceContext;
> import org.apache.tapestry5.ioc.AnnotationProvider;
> import org.apache.tapestry5.ioc.ObjectCreator;
> import org.apache.tapestry5.ioc.ObjectLocator;
> import org.apache.tapestry5.ioc.ObjectProvider;
> import org.apache.tapestry5.ioc.services.PlasticProxyFactory;
> import org.apache.tapestry5.jpa.EntityManagerManager;
> /**
> * A patched version to use PlasticProxyFactory and not cache the
> EntityManager as a class member.
> * @author John Coleman
> */
> public class EntityManagerObjectProvider implements ObjectProvider
> {
> /**
> * {@inheritDoc}
> */
> public T provide(final Class objectType, final AnnotationProvider
> annotationProvider,
> final ObjectLocator locator)
> {
> if (objectType.equals(EntityManager.class))
> return objectType.cast(getOrCreateProxy(annotationProvider,
> locator));
> return null;
> }
> private synchronized EntityManager getOrCreateProxy(
> final AnnotationProvider annotationProvider, final ObjectLocator
> objectLocator)
> {
> final PlasticProxyFactory proxyFactory =
> objectLocator.getService("PlasticProxyFactory",
> PlasticProxyFactory.class);
> final PersistenceContext annotation = annotationProvider
> .getAnnotation(PersistenceContext.class);
> EntityManager proxy =
> proxyFactory.createProxy(EntityManager.class, new
> ObjectCreator()
> {
> public EntityManager createObject()
> {
> final EntityManagerManager entityManagerManager =
> objectLocator
> .getService(EntityManagerManager.class);
> return
> JpaInternalUtils.getEntityManager(entityManagerManager, annotation);
> }
> }, "");
> return proxy;
> }
> }
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TAP5-2027) EntityManagerObjectProvider always provides the initial EntityManger proxy created
[
https://issues.apache.org/jira/browse/TAP5-2027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13496804#comment-13496804
]
Lenny Primak commented on TAP5-2027:
I just took a quick look (but not tested) at your code, and I don't see how not
caching a proxy has any difference.
Since the PlasticProxyFactory calls createObject() upon every method call.
I just tested a simple app with two PUs on the same page and it works fine.
I still say this is not an issue.
> EntityManagerObjectProvider always provides the initial EntityManger proxy
> created
> --
>
> Key: TAP5-2027
> URL: https://issues.apache.org/jira/browse/TAP5-2027
> Project: Tapestry 5
> Issue Type: Bug
> Components: tapestry-jpa
>Affects Versions: 5.3.5, 5.3.6
>Reporter: John Coleman
> Labels: patch
>
> When persistence.xml defines multiple persistence units, classes injecting
> EntityManager with @PersistenceContext(unitName=value crash because the
> entities associated with the PU in configuration are not recognised at
> runtime.
> By placing trace in the code I established that the first EntityManager
> injected gets injected to all my other service classes even though I use
> different unitName= annotations.
> The EntityManagerObjectProvider class contains a class variable proxy and
> works like a singleton always injecting the first EntityManager proxy class
> created for any later EntityManager injections.
> The following code fixes the issue and is provided as-is, free and without
> copyright or warranty. This is more like a refactor because I have also
> replaced some depricated code. As a patch it also works just to remove the
> proxy class member variable and the if (proxy == null) condition.
> package org.apache.tapestry5.internal.jpa;
> import javax.persistence.EntityManager;
> import javax.persistence.PersistenceContext;
> import org.apache.tapestry5.ioc.AnnotationProvider;
> import org.apache.tapestry5.ioc.ObjectCreator;
> import org.apache.tapestry5.ioc.ObjectLocator;
> import org.apache.tapestry5.ioc.ObjectProvider;
> import org.apache.tapestry5.ioc.services.PlasticProxyFactory;
> import org.apache.tapestry5.jpa.EntityManagerManager;
> /**
> * A patched version to use PlasticProxyFactory and not cache the
> EntityManager as a class member.
> * @author John Coleman
> */
> public class EntityManagerObjectProvider implements ObjectProvider
> {
> /**
> * {@inheritDoc}
> */
> public T provide(final Class objectType, final AnnotationProvider
> annotationProvider,
> final ObjectLocator locator)
> {
> if (objectType.equals(EntityManager.class))
> return objectType.cast(getOrCreateProxy(annotationProvider,
> locator));
> return null;
> }
> private synchronized EntityManager getOrCreateProxy(
> final AnnotationProvider annotationProvider, final ObjectLocator
> objectLocator)
> {
> final PlasticProxyFactory proxyFactory =
> objectLocator.getService("PlasticProxyFactory",
> PlasticProxyFactory.class);
> final PersistenceContext annotation = annotationProvider
> .getAnnotation(PersistenceContext.class);
> EntityManager proxy =
> proxyFactory.createProxy(EntityManager.class, new
> ObjectCreator()
> {
> public EntityManager createObject()
> {
> final EntityManagerManager entityManagerManager =
> objectLocator
> .getService(EntityManagerManager.class);
> return
> JpaInternalUtils.getEntityManager(entityManagerManager, annotation);
> }
> }, "");
> return proxy;
> }
> }
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TAP5-1973) :443 added to URLs when using the Link.toAbsoluteURI(true)
[
https://issues.apache.org/jira/browse/TAP5-1973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13481147#comment-13481147
]
Lenny Primak commented on TAP5-1973:
I run my production Tapestry apps behind Apache and AJP/JK2 protocol.
In this setup, serverPort is always 8009, and thus always fails the
expectedPort test.
This means the new way of appending :443. :80 ports to URLs is broken in my
setup.
Since https:// always defaults to :443 and http:// to 80, why is there any
appending going on at all?
This should be removed, or at least make it removed by default, and optionally
turned on.
> :443 added to URLs when using the Link.toAbsoluteURI(true)
> --
>
> Key: TAP5-1973
> URL: https://issues.apache.org/jira/browse/TAP5-1973
> Project: Tapestry 5
> Issue Type: Bug
> Components: tapestry-core
>Affects Versions: 5.3.4, 5.4
>Reporter: Howard M. Lewis Ship
>Assignee: Howard M. Lewis Ship
> Labels: fixed-in-5.4-js-rewrite
> Fix For: 5.3.5
>
>
> An error in the code means that when secure is true and the port is set to
> 443, then ":443" is appended:
> int port = secure ? secureHostPort : hostPort;
> String portSuffix = "";
> if (port <= 0) {
> port = request.getServerPort();
> int schemeDefaultPort = request.isSecure() ? 443 : 80;
> portSuffix = port == schemeDefaultPort ? "" : ":" + port;
> }
> else if (secure && port != 443) portSuffix = ":" + port;
> else if (port != 80) portSuffix = ":" + port;
>
> String hostname = "".equals(this.hostname) ? request.getServerName()
> : this.hostname.startsWith("$") ? System.getenv(this.hostname.substring(1)) :
> this.hostname;
>
> return String.format("%s://%s%s", secure ? "https" : "http",
> hostname, portSuffix);
> secure == true && port != 443 is false, so
> port != 80 is evaluated, it true, so
> ":443" is appended.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TAP5-1661) Grid inPlace=true - Gracedul degradation with JavaScript disabled
Grid inPlace=true - Gracedul degradation with JavaScript disabled - Key: TAP5-1661 URL: https://issues.apache.org/jira/browse/TAP5-1661 Project: Tapestry 5 Issue Type: Improvement Components: tapestry-core Affects Versions: 5.3, 5.4, 5.2 Reporter: Lenny Primak Priority: Minor When JavaScript is disabled on the browser, Grid inPlace="true" pager will not function. It should gracefully degrade and still function with JavaScript disabled, as if inPlace was set to false. I realize this is difficult to do because its really not detectable if JS is enabled on the server side. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TAP5-840) Support character references in tml files with HTML 5 Doctype
[ https://issues.apache.org/jira/browse/TAP5-840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13101946#comment-13101946 ] Lenny Primak commented on TAP5-840: --- The problem with using entity numbers instead of names is that graphical web page editors (e.g. Dreamweaver) still put and such in the html code, so right now html5 templates are not editable by graphic designers, so the whole point of tapestry templates being editable by designers is broken with html5 right now. > Support character references in tml files with HTML 5 Doctype > - > > Key: TAP5-840 > URL: https://issues.apache.org/jira/browse/TAP5-840 > Project: Tapestry 5 > Issue Type: Improvement > Components: tapestry-core >Affects Versions: 5.3, 5.2.6, 5.1.0.5, 5.0.18 >Reporter: Ben Gidley > Attachments: patch.txt > > > Currently to support HTML character references (e.g. ©) you need to put > a HTML Doctype at the top of the TML file. > e.g. "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";> > However for HTML 5 they have stopped using XML doctypes and instead use > > If you change tapestry page to use this you can no longer use entities as the > XML parser doesn't know what to do. > Ideally there should be some kind of logic that detects and > include a suitable DTD to resolve the common HTML entities. The HTML 5 > specification defines the allowed named character references - > http://dev.w3.org/html5/spec/Overview.html#named-character-references. There > doesn't seem to be a DTD of allowed references maintained anymore. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TAP5-1634) Grid, inPlace Update and expired Sessions - Redirect to Login
Grid, inPlace Update and expired Sessions - Redirect to Login
-
Key: TAP5-1634
URL: https://issues.apache.org/jira/browse/TAP5-1634
Project: Tapestry 5
Issue Type: Improvement
Components: tapestry-core
Affects Versions: 5.3, 5.4
Reporter: Lenny Primak
Priority: Minor
I have a basic Grid pulling data from an Entity bean. inPlace = true.
Obviously, when session expires, I get the "there is no data to display"
message.
What I really want to do is to redirect to the current page, so the user gets
to relogin and session
gets re-established.
Here's what I tried:
@SuppressWarnings("unused")
@OnEvent(value="inplaceUpdate", component="usersGrid")
private Object ajaxPageChanged()
{
if(request.getSession(false) != null)
{
return null;
}
else
{
return ps.createPageRenderLink(LoginPage.class).;
}
}
I get an exception:
Caused by: java.lang.IllegalArgumentException: Event 'inplaceupdate' from
test/TapPage:usersgrid.pager received an event handler method return value of
/com.bettaway_baw-website_war_1.2/loginpage. This type of event does not
support return values from event handler methods.
at
org.apache.tapestry5.internal.util.NotificationEventCallback.handleResult(NotificationEventCallback.java:39)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TAP5-1576) JPA Integration 5.3.0 with Primary Key Entity Classes Fails
[
https://issues.apache.org/jira/browse/TAP5-1576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13066729#comment-13066729
]
Lenny Primak commented on TAP5-1576:
Thank you - that works perfectly.
> JPA Integration 5.3.0 with Primary Key Entity Classes Fails
> ---
>
> Key: TAP5-1576
> URL: https://issues.apache.org/jira/browse/TAP5-1576
> Project: Tapestry 5
> Issue Type: Bug
> Components: tapestry-jpa
>Affects Versions: 5.3
>Reporter: Lenny Primak
>Assignee: Igor Drobiazko
> Fix For: 5.3
>
>
> Single Persistence Unit this time, Glassfish 3,1
> This used to work with Tynamo JPA as well.
> Everything works until I introduce a primary key entity reference such as
> this:
> Thanks!
> --- Main Entity --
> /**
> *
> * @author lprimak
> */
> @Entity
> @Table(name = "webstats")
> @XmlRootElement
> @NamedQueries(
> {
> ...
> })
> @Data
> public class WebStats implements Serializable
> {
>public String getDate()
>{
>return webStatsPK.getSdate();
>}
>public String getStatisticName()
>{
>return webStatsPK.getSName();
>}
>private static final long serialVersionUID = 1L;
>@EmbeddedId
>protected WebStatsPK webStatsPK;
>@Basic(optional = false)
>@NotNull
>@Column(name = "nvisit")
>private long nvisit;
>@Column(name = "ncarrier")
>private Long ncarrier;
>@Column(name = "ntrack")
>private Long ntrack;
>@Column(name = "nadmin")
>private Long nadmin;
>@Column(name = "nother")
>private Long nother;
>public WebStats()
>{
>}
>public WebStats(WebStatsPK webstatsPK)
>{
>this.webStatsPK = webstatsPK;
>}
>public WebStats(WebStatsPK webstatsPK, long nvisit)
>{
>this.webStatsPK = webstatsPK;
>this.nvisit = nvisit;
>}
>public WebStats(String sdate, String sName)
>{
>this.webStatsPK = new WebStatsPK(sdate, sName);
>}
> }
> - Embedded Primary Key ---
> /**
> *
> * @author lprimak
> */
> @Embeddable
> @Data
> public class WebStatsPK implements Serializable
> {
>/**
> *
> */
>private static final long serialVersionUID = 1L;
>@Basic(optional = false)
>@NotNull
>@Size(min = 1, max = 8)
>@Column(name = "sdate")
>private String sdate;
>@Basic(optional = false)
>@NotNull
>@Size(min = 1, max = 50)
>@Column(name = "sName")
>private String sName;
>public WebStatsPK()
>{
>}
>public WebStatsPK(String sdate, String sName)
>{
>this.sdate = sdate;
>this.sName = sName;
>}
> }
>
> Here is the error:
> SEVERE: Error invoking service contribution method
> org.apache.tapestry5.jpa.JpaModule.provideValueEncoders(MappedConfiguration,
> boolean, EntityManagerSource, EntityManagerManager, TypeCoercer,
> PropertyAccess, LoggerSource): The type [null] is not the expected
> [EntityType] for the key class [class
> com.flowlogix.website.entities.WebStatsPK].
> SEVERE: Operations trace:
> SEVERE: [ 1] Constructing instance of page class
> org.apache.tapestry5.corelib.pages.ExceptionReport
> SEVERE: [ 2] Realizing service ValueEncoderSource
> SEVERE: [ 3] Invoking
> org.apache.tapestry5.services.TapestryModule.buildValueEncoderSource(Map,
> InvalidationEventHub) (at TapestryModule.java:2337)
> SEVERE: [ 4] Invoking
> org.apache.tapestry5.services.TapestryModule.buildValueEncoderSource(Map,
> InvalidationEventHub) (at TapestryModule.java:2337)
> SEVERE: [ 5] Determining injection value for parameter #1 (java.util.Map)
> SEVERE: [ 6] Collecting mapped configuration for service ValueEncoderSource
> SEVERE: [ 7] Invoking method
> org.apache.tapestry5.jpa.JpaModule.provideValueEncoders(MappedConfiguration,
> boolean, EntityManagerSource, EntityManagerManager, TypeCoercer,
> PropertyAccess, LoggerSource) (at JpaModule.java:180).
> SEVERE: Construction of service ValueEncoderSource failed: Error invoking
> service builder method
> org.apache.tapestry5.services.TapestryModule.buildValueEncoderSource(Map,
> InvalidationEventHub) (at TapestryModule.java:2337) (for service
> 'ValueEncoderSource'): Error invoking service contribution method
> org.apache.tapestry5.jpa.JpaModule.provideValueEncoders(MappedConfiguration,
> boolean, EntityManagerSource, EntityManagerManager, TypeCoercer,
> PropertyAccess, LoggerSource): The type [null] is not the expected
> [EntityType] for the key class [class
> com.flowlogix.website.entities.WebStatsPK].
> java.lang.RuntimeException: Error invoking service builder method
> org.apache.tapestry5.services.TapestryModule.buildValueEncoderSource(Map,
> InvalidationEventHub) (at Tap
[jira] [Commented] (TAP5-1576) JPA Integration 5.3.0 with Primary Key Entity Classes Fails
[
https://issues.apache.org/jira/browse/TAP5-1576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13066715#comment-13066715
]
Lenny Primak commented on TAP5-1576:
The following patch solves the problem for me:
Index: src/main/java/org/apache/tapestry5/jpa/JpaModule.java
===
--- src/main/java/org/apache/tapestry5/jpa/JpaModule.java (revision
1147680)
+++ src/main/java/org/apache/tapestry5/jpa/JpaModule.java (working copy)
@@ -184,14 +184,10 @@
{
final EntityManagerFactory emf =
entityManagerSource.getEntityManagerFactory(info.getPersistenceUnitName());
-for (final String className : info.getManagedClassNames())
+for(final EntityType entity : emf.getMetamodel().getEntities())
+//for (final String className : info.getManagedClassNames())
{
-final Metamodel metamodel = emf.getMetamodel();
-
-final Class clazz = loadClass(info, className);
-
-final EntityType entity = metamodel.entity(clazz);
-
+final Class clazz = entity.getClass();
final ValueEncoderFactory factory = new ValueEncoderFactory()
{
public ValueEncoder create(final Class type)
> JPA Integration 5.3.0 with Primary Key Entity Classes Fails
> ---
>
> Key: TAP5-1576
> URL: https://issues.apache.org/jira/browse/TAP5-1576
> Project: Tapestry 5
> Issue Type: Bug
> Components: tapestry-jpa
>Affects Versions: 5.3, 5.4
>Reporter: Lenny Primak
>Assignee: Igor Drobiazko
>
> Single Persistence Unit this time, Glassfish 3,1
> This used to work with Tynamo JPA as well.
> Everything works until I introduce a primary key entity reference such as
> this:
> Thanks!
> --- Main Entity --
> /**
> *
> * @author lprimak
> */
> @Entity
> @Table(name = "webstats")
> @XmlRootElement
> @NamedQueries(
> {
> ...
> })
> @Data
> public class WebStats implements Serializable
> {
>public String getDate()
>{
>return webStatsPK.getSdate();
>}
>public String getStatisticName()
>{
>return webStatsPK.getSName();
>}
>private static final long serialVersionUID = 1L;
>@EmbeddedId
>protected WebStatsPK webStatsPK;
>@Basic(optional = false)
>@NotNull
>@Column(name = "nvisit")
>private long nvisit;
>@Column(name = "ncarrier")
>private Long ncarrier;
>@Column(name = "ntrack")
>private Long ntrack;
>@Column(name = "nadmin")
>private Long nadmin;
>@Column(name = "nother")
>private Long nother;
>public WebStats()
>{
>}
>public WebStats(WebStatsPK webstatsPK)
>{
>this.webStatsPK = webstatsPK;
>}
>public WebStats(WebStatsPK webstatsPK, long nvisit)
>{
>this.webStatsPK = webstatsPK;
>this.nvisit = nvisit;
>}
>public WebStats(String sdate, String sName)
>{
>this.webStatsPK = new WebStatsPK(sdate, sName);
>}
> }
> - Embedded Primary Key ---
> /**
> *
> * @author lprimak
> */
> @Embeddable
> @Data
> public class WebStatsPK implements Serializable
> {
>/**
> *
> */
>private static final long serialVersionUID = 1L;
>@Basic(optional = false)
>@NotNull
>@Size(min = 1, max = 8)
>@Column(name = "sdate")
>private String sdate;
>@Basic(optional = false)
>@NotNull
>@Size(min = 1, max = 50)
>@Column(name = "sName")
>private String sName;
>public WebStatsPK()
>{
>}
>public WebStatsPK(String sdate, String sName)
>{
>this.sdate = sdate;
>this.sName = sName;
>}
> }
>
> Here is the error:
> SEVERE: Error invoking service contribution method
> org.apache.tapestry5.jpa.JpaModule.provideValueEncoders(MappedConfiguration,
> boolean, EntityManagerSource, EntityManagerManager, TypeCoercer,
> PropertyAccess, LoggerSource): The type [null] is not the expected
> [EntityType] for the key class [class
> com.flowlogix.website.entities.WebStatsPK].
> SEVERE: Operations trace:
> SEVERE: [ 1] Constructing instance of page class
> org.apache.tapestry5.corelib.pages.ExceptionReport
> SEVERE: [ 2] Realizing service ValueEncoderSource
> SEVERE: [ 3] Invoking
> org.apache.tapestry5.services.TapestryModule.buildValueEncoderSource(Map,
> InvalidationEventHub) (at TapestryModule.java:2337)
> SEVERE: [ 4] Invoking
> org.apache.tapestry5.services.TapestryModule.buildValueEncoderSource(Map,
> InvalidationEventHub) (at TapestryModule.java:2337)
> SEVERE: [ 5] Determining injection value for parameter #1 (java.util.Map)
> SEVERE: [ 6]
[jira] [Commented] (TAP5-1576) JPA Integration 5.3.0 with Primary Key Entity Classes Fails
[
https://issues.apache.org/jira/browse/TAP5-1576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13066146#comment-13066146
]
Lenny Primak commented on TAP5-1576:
1
2 http://java.sun.com/xml/ns/persistence";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://java.sun.com/xml/ns/persistence
http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd";>
3
4 jdbc/Billing
5 false
6
7
8
> JPA Integration 5.3.0 with Primary Key Entity Classes Fails
> ---
>
> Key: TAP5-1576
> URL: https://issues.apache.org/jira/browse/TAP5-1576
> Project: Tapestry 5
> Issue Type: Bug
> Components: tapestry-jpa
>Affects Versions: 5.3, 5.4
>Reporter: Lenny Primak
>Assignee: Igor Drobiazko
>
> Single Persistence Unit this time, Glassfish 3,1
> This used to work with Tynamo JPA as well.
> Everything works until I introduce a primary key entity reference such as
> this:
> Thanks!
> --- Main Entity --
> /**
> *
> * @author lprimak
> */
> @Entity
> @Table(name = "webstats")
> @XmlRootElement
> @NamedQueries(
> {
> ...
> })
> @Data
> public class WebStats implements Serializable
> {
>public String getDate()
>{
>return webStatsPK.getSdate();
>}
>public String getStatisticName()
>{
>return webStatsPK.getSName();
>}
>private static final long serialVersionUID = 1L;
>@EmbeddedId
>protected WebStatsPK webStatsPK;
>@Basic(optional = false)
>@NotNull
>@Column(name = "nvisit")
>private long nvisit;
>@Column(name = "ncarrier")
>private Long ncarrier;
>@Column(name = "ntrack")
>private Long ntrack;
>@Column(name = "nadmin")
>private Long nadmin;
>@Column(name = "nother")
>private Long nother;
>public WebStats()
>{
>}
>public WebStats(WebStatsPK webstatsPK)
>{
>this.webStatsPK = webstatsPK;
>}
>public WebStats(WebStatsPK webstatsPK, long nvisit)
>{
>this.webStatsPK = webstatsPK;
>this.nvisit = nvisit;
>}
>public WebStats(String sdate, String sName)
>{
>this.webStatsPK = new WebStatsPK(sdate, sName);
>}
> }
> - Embedded Primary Key ---
> /**
> *
> * @author lprimak
> */
> @Embeddable
> @Data
> public class WebStatsPK implements Serializable
> {
>/**
> *
> */
>private static final long serialVersionUID = 1L;
>@Basic(optional = false)
>@NotNull
>@Size(min = 1, max = 8)
>@Column(name = "sdate")
>private String sdate;
>@Basic(optional = false)
>@NotNull
>@Size(min = 1, max = 50)
>@Column(name = "sName")
>private String sName;
>public WebStatsPK()
>{
>}
>public WebStatsPK(String sdate, String sName)
>{
>this.sdate = sdate;
>this.sName = sName;
>}
> }
>
> Here is the error:
> SEVERE: Error invoking service contribution method
> org.apache.tapestry5.jpa.JpaModule.provideValueEncoders(MappedConfiguration,
> boolean, EntityManagerSource, EntityManagerManager, TypeCoercer,
> PropertyAccess, LoggerSource): The type [null] is not the expected
> [EntityType] for the key class [class
> com.flowlogix.website.entities.WebStatsPK].
> SEVERE: Operations trace:
> SEVERE: [ 1] Constructing instance of page class
> org.apache.tapestry5.corelib.pages.ExceptionReport
> SEVERE: [ 2] Realizing service ValueEncoderSource
> SEVERE: [ 3] Invoking
> org.apache.tapestry5.services.TapestryModule.buildValueEncoderSource(Map,
> InvalidationEventHub) (at TapestryModule.java:2337)
> SEVERE: [ 4] Invoking
> org.apache.tapestry5.services.TapestryModule.buildValueEncoderSource(Map,
> InvalidationEventHub) (at TapestryModule.java:2337)
> SEVERE: [ 5] Determining injection value for parameter #1 (java.util.Map)
> SEVERE: [ 6] Collecting mapped configuration for service ValueEncoderSource
> SEVERE: [ 7] Invoking method
> org.apache.tapestry5.jpa.JpaModule.provideValueEncoders(MappedConfiguration,
> boolean, EntityManagerSource, EntityManagerManager, TypeCoercer,
> PropertyAccess, LoggerSource) (at JpaModule.java:180).
> SEVERE: Construction of service ValueEncoderSource failed: Error invoking
> service builder method
> org.apache.tapestry5.services.TapestryModule.buildValueEncoderSource(Map,
> InvalidationEventHub) (at TapestryModule.java:2337) (for service
> 'ValueEncoderSource'): Error invoking service contribution method
> org.apache.tapestry5.jpa.JpaModule.provideValueEncoders(MappedConfiguration,
> boolean, EntityManagerSource, EntityManagerManager, TypeCoercer,
> PropertyAccess, LoggerSource): The type [null] is not the expected
> [Entity
[jira] [Created] (TAP5-1576) JPA Integration 5.3.0 with Primary Key Entity Classes Fails
JPA Integration 5.3.0 with Primary Key Entity Classes Fails
---
Key: TAP5-1576
URL: https://issues.apache.org/jira/browse/TAP5-1576
Project: Tapestry 5
Issue Type: Bug
Components: tapestry-jpa
Affects Versions: 5.3, 5.4
Reporter: Lenny Primak
Single Persistence Unit this time, Glassfish 3,1
This used to work with Tynamo JPA as well.
Everything works until I introduce a primary key entity reference such as this:
Thanks!
--- Main Entity --
/**
*
* @author lprimak
*/
@Entity
@Table(name = "webstats")
@XmlRootElement
@NamedQueries(
{
...
})
@Data
public class WebStats implements Serializable
{
public String getDate()
{
return webStatsPK.getSdate();
}
public String getStatisticName()
{
return webStatsPK.getSName();
}
private static final long serialVersionUID = 1L;
@EmbeddedId
protected WebStatsPK webStatsPK;
@Basic(optional = false)
@NotNull
@Column(name = "nvisit")
private long nvisit;
@Column(name = "ncarrier")
private Long ncarrier;
@Column(name = "ntrack")
private Long ntrack;
@Column(name = "nadmin")
private Long nadmin;
@Column(name = "nother")
private Long nother;
public WebStats()
{
}
public WebStats(WebStatsPK webstatsPK)
{
this.webStatsPK = webstatsPK;
}
public WebStats(WebStatsPK webstatsPK, long nvisit)
{
this.webStatsPK = webstatsPK;
this.nvisit = nvisit;
}
public WebStats(String sdate, String sName)
{
this.webStatsPK = new WebStatsPK(sdate, sName);
}
}
- Embedded Primary Key ---
/**
*
* @author lprimak
*/
@Embeddable
@Data
public class WebStatsPK implements Serializable
{
/**
*
*/
private static final long serialVersionUID = 1L;
@Basic(optional = false)
@NotNull
@Size(min = 1, max = 8)
@Column(name = "sdate")
private String sdate;
@Basic(optional = false)
@NotNull
@Size(min = 1, max = 50)
@Column(name = "sName")
private String sName;
public WebStatsPK()
{
}
public WebStatsPK(String sdate, String sName)
{
this.sdate = sdate;
this.sName = sName;
}
}
Here is the error:
SEVERE: Error invoking service contribution method
org.apache.tapestry5.jpa.JpaModule.provideValueEncoders(MappedConfiguration,
boolean, EntityManagerSource, EntityManagerManager, TypeCoercer,
PropertyAccess, LoggerSource): The type [null] is not the expected [EntityType]
for the key class [class com.flowlogix.website.entities.WebStatsPK].
SEVERE: Operations trace:
SEVERE: [ 1] Constructing instance of page class
org.apache.tapestry5.corelib.pages.ExceptionReport
SEVERE: [ 2] Realizing service ValueEncoderSource
SEVERE: [ 3] Invoking
org.apache.tapestry5.services.TapestryModule.buildValueEncoderSource(Map,
InvalidationEventHub) (at TapestryModule.java:2337)
SEVERE: [ 4] Invoking
org.apache.tapestry5.services.TapestryModule.buildValueEncoderSource(Map,
InvalidationEventHub) (at TapestryModule.java:2337)
SEVERE: [ 5] Determining injection value for parameter #1 (java.util.Map)
SEVERE: [ 6] Collecting mapped configuration for service ValueEncoderSource
SEVERE: [ 7] Invoking method
org.apache.tapestry5.jpa.JpaModule.provideValueEncoders(MappedConfiguration,
boolean, EntityManagerSource, EntityManagerManager, TypeCoercer,
PropertyAccess, LoggerSource) (at JpaModule.java:180).
SEVERE: Construction of service ValueEncoderSource failed: Error invoking
service builder method
org.apache.tapestry5.services.TapestryModule.buildValueEncoderSource(Map,
InvalidationEventHub) (at TapestryModule.java:2337) (for service
'ValueEncoderSource'): Error invoking service contribution method
org.apache.tapestry5.jpa.JpaModule.provideValueEncoders(MappedConfiguration,
boolean, EntityManagerSource, EntityManagerManager, TypeCoercer,
PropertyAccess, LoggerSource): The type [null] is not the expected [EntityType]
for the key class [class com.flowlogix.website.entities.WebStatsPK].
java.lang.RuntimeException: Error invoking service builder method
org.apache.tapestry5.services.TapestryModule.buildValueEncoderSource(Map,
InvalidationEventHub) (at TapestryModule.java:2337) (for service
'ValueEncoderSource'): Error invoking service contribution method
org.apache.tapestry5.jpa.JpaModule.provideValueEncoders(MappedConfiguration,
boolean, EntityManagerSource, EntityManagerManager, TypeCoercer,
PropertyAccess, LoggerSource): The type [null] is not the expected [EntityType]
for the key class [class com.flowlogix.website.entities.WebStatsPK].
at
org.apache.tapestry5.ioc.internal.ServiceBuilderMethodInvoker$1.invoke(ServiceBuilderMethodInvoker.java:80)
at
org.apache.tapestry5.ioc.internal.OperationTrackerImpl.invoke(OperationTracke
