[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=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=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=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=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-2170) constructAssetPath() requires use of internal service
[ https://issues.apache.org/jira/browse/TAP5-2170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-2170) constructAssetPath() requires use of internal service
[ https://issues.apache.org/jira/browse/TAP5-2170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-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-tabpanelfocusedCommentId=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-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-tabpanelfocusedCommentId=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] [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] [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] [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-tabpanelfocusedCommentId=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] [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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-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-tabpanelfocusedCommentId=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 ListAsset getJavaScriptLibraries() {
ListAsset ret = new ArrayListAsset();
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-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-tabpanelfocusedCommentId=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-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-tabpanelfocusedCommentId=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-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-tabpanelfocusedCommentId=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.
{{{
t:beaneditform object=xxx
p:CreateTextRecord
!-- this DIV should be generated automatically
div class=form-group
--
t:label id=lbCreateTextRecord
for=CreateTextRecord
Create Text Record?
/t:label
input t:type=CheckBox
t:id=CreateTextRecord
value=rr.createTextRecord /
!-- END form-group DIV
/div
--
/p: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-tabpanelfocusedCommentId=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.
{{{
t:beaneditform object=xxx
p:CreateTextRecord
!-- this DIV should be generated automatically
div class=form-group
--
t:label id=lbCreateTextRecord
for=CreateTextRecord
Create Text Record?
/t:label
input t:type=CheckBox
t:id=CreateTextRecord
value=rr.createTextRecord /
!-- END form-group DIV
/div
--
/p: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-tabpanelfocusedCommentId=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.
{{{
t:beaneditform object=xxx
p:CreateTextRecord
!-- this DIV should be generated automatically
div class=form-group
--
t:label id=lbCreateTextRecord
for=CreateTextRecord
Create Text Record?
/t:label
input t:type=CheckBox
t:id=CreateTextRecord
value=rr.createTextRecord /
!-- END form-group DIV
/div
--
/p: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-tabpanelfocusedCommentId=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.
{{{
t:beaneditform object=xxx
p:CreateTextRecord
!-- this DIV should be generated automatically
div class=form-group
--
t:label id=lbCreateTextRecord
for=CreateTextRecord
Create Text Record?
/t:label
input t:type=CheckBox
t:id=CreateTextRecord
value=rr.createTextRecord /
!-- END form-group DIV
/div
--
/p: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-tabpanelfocusedCommentId=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 div
class=form-group
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.
{{{
t:beaneditform object=xxx
p:CreateTextRecord
!-- this DIV should be generated automatically
div class=form-group
--
t:label id=lbCreateTextRecord
for=CreateTextRecord
Create Text Record?
/t:label
input t:type=CheckBox
t:id=CreateTextRecord
value=rr.createTextRecord /
!-- END form-group DIV
/div
--
/p: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.
{{{
t:beaneditform object=xxx
p:CreateTextRecord
!-- this DIV should be generated automatically
div class=form-group
--
t:label id=lbCreateTextRecord
for=CreateTextRecord
Create Text Record?
/t:label
input t:type=CheckBox
t:id=CreateTextRecord
value=rr.createTextRecord /
!-- END form-group DIV
/div
--
/p: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.
{{{
t:beaneditform object=xxx
p:CreateTextRecord
!-- this DIV should be generated automatically
div class=form-group
--
t:label id=lbCreateTextRecord
for=CreateTextRecord
Create Text Record?
/t:label
input t:type=CheckBox
t:id=CreateTextRecord
value=rr.createTextRecord /
!-- END form-group DIV
/div
--
/p: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] [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.
{{{
t:beaneditform object=xxx
p:CreateTextRecord
!-- this DIV should be generated automatically
div class=form-group
--
t:label id=lbCreateTextRecord
for=CreateTextRecord
Create Text Record?
/t:label
input t:type=CheckBox
t:id=CreateTextRecord
value=rr.createTextRecord /
!-- END form-group DIV
/div
--
/p: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-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-tabpanelfocusedCommentId=13811023#comment-13811023 ] Lenny Primak commented on TAP5-2182: The fix should be able to modify all t:beaneditform 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] [Commented] (TAP5-2211) Replace DatePicker with JQueryUI DatePicker
[ https://issues.apache.org/jira/browse/TAP5-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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] [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 Bootstrap or JQueryUI DatePicker
[ https://issues.apache.org/jira/browse/TAP5-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] [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-2211) Replace DatePicker with JQueryUI DatePicker
[ https://issues.apache.org/jira/browse/TAP5-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] [Commented] (TAP5-2197) Overriding core css - bug?
[
https://issues.apache.org/jira/browse/TAP5-2197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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. p:fieldNamemy field/p:fieldName 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-2211) Replace DatePicker with JQueryUI DatePicker
[ https://issues.apache.org/jira/browse/TAP5-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-2211) Replace DatePicker with JQueryUI DatePicker
[ https://issues.apache.org/jira/browse/TAP5-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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] [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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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] [Commented] (TAP5-2211) Replace DatePicker with JQueryUI DatePicker
[ https://issues.apache.org/jira/browse/TAP5-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-2080) Default BaseURLSource does not handle all scenarios
[
https://issues.apache.org/jira/browse/TAP5-2080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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(
MappedConfigurationClass?, 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] [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-tabpanelfocusedCommentId=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 ListAsset getJavaScriptLibraries() {
ListAsset ret = new ArrayListAsset();
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-tabpanelfocusedCommentId=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 ListAsset getJavaScriptLibraries() {
ListAsset ret = new ArrayListAsset();
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-tabpanelfocusedCommentId=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 ListAsset getJavaScriptLibraries() {
ListAsset ret = new ArrayListAsset();
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-tabpanelfocusedCommentId=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 divs 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-tabpanelfocusedCommentId=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] [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-tabpanelfocusedCommentId=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-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] [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-tabpanelfocusedCommentId=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] [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] [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-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] [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] [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-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] [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-tabpanelfocusedCommentId=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] [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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-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-tabpanelfocusedCommentId=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
tr t:type=Zone t:id=rowZone id=prop:currentRowZoneId
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:
tr class=even t-zone tapestry-zone id=rowZone_5
Here's the row after the zone updates:
tr class=even t-zone tapestry-zone id=rowZone_5
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:
tr class=even t-zone tapestry-zone id=rowZone_5
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-tabpanelfocusedCommentId=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] [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 a href=https://issues.apache.org/jira/browse/TAP5-1779;
target=_blankTAP5-1779/a
*/
@Contribute(RequestHandler.class)
public void disableAssetDirListing(OrderedConfigurationRequestFilter
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(OrderedConfigurationRequestFilter
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 a href=https://issues.apache.org/jira/browse/TAP5-1779;
target=_blankTAP5-1779/a
*/
@Contribute(RequestHandler.class)
public void disableAssetDirListing(OrderedConfigurationRequestFilter
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
[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-tabpanelfocusedCommentId=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 a href=https://issues.apache.org/jira/browse/TAP5-1779;
target=_blankTAP5-1779/a
*/
@Contribute(RequestHandler.class)
public void disableAssetDirListing(OrderedConfigurationRequestFilter
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] [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-tabpanelfocusedCommentId=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 T provide(final ClassT 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
ObjectCreatorEntityManager()
{
public EntityManager createObject()
{
final EntityManagerManager entityManagerManager =
objectLocator
.getService(EntityManagerManager.class);
return
JpaInternalUtils.getEntityManager(entityManagerManager, annotation);
}
}, EntityManagerProxy);
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-tabpanelfocusedCommentId=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 T provide(final ClassT 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
ObjectCreatorEntityManager()
{
public EntityManager createObject()
{
final EntityManagerManager entityManagerManager =
objectLocator
.getService(EntityManagerManager.class);
return
JpaInternalUtils.getEntityManager(entityManagerManager, annotation);
}
}, EntityManagerProxy);
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-tabpanelfocusedCommentId=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 T provide(final ClassT 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
ObjectCreatorEntityManager()
{
public EntityManager createObject()
{
final EntityManagerManager entityManagerManager =
objectLocator
.getService(EntityManagerManager.class);
return
JpaInternalUtils.getEntityManager(entityManagerManager, annotation);
}
}, EntityManagerProxy);
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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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 nbsp; 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. copy;) you need to put a HTML Doctype at the top of the TML file. e.g. !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Strict//EN http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd; However for HTML 5 they have stopped using XML doctypes and instead use !DOCTYPE html 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 !DOCTYPE html 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-tabpanelfocusedCommentId=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] Collecting mapped configuration for service ValueEncoderSource
SEVERE: [ 7] Invoking method
[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-tabpanelfocusedCommentId=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 TapestryModule.java:2337) (for service
'ValueEncoderSource'): Error invoking service contribution method
[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-tabpanelfocusedCommentId=13066146#comment-13066146
]
Lenny Primak commented on TAP5-1576:
1 ?xml version=1.0 encoding=UTF-8?
2 persistence version=2.0
xmlns=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 persistence-unit name=Hope transaction-type=JTA
4 jta-data-sourcejdbc/Billing/jta-data-source
5 exclude-unlisted-classesfalse/exclude-unlisted-classes
6 properties/
7 /persistence-unit
8 /persistence
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,
