[jira] [Commented] (TAP5-1730) Ajax Zone is improperly reloaded when a mixin submits form via JavaScript

2013-07-25 Thread Lenny Primak (JIRA)

[ 
https://issues.apache.org/jira/browse/TAP5-1730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13720450#comment-13720450
 ] 

Lenny Primak commented on TAP5-1730:


I will do this as part of port of FlowLogix to Tap 5.4.
How soon that will happen is another story...  

> Ajax Zone is improperly reloaded when a mixin submits form via JavaScript
> -
>
> Key: TAP5-1730
> URL: https://issues.apache.org/jira/browse/TAP5-1730
> Project: Tapestry 5
>  Issue Type: Bug
>  Components: tapestry-core
>Affects Versions: 5.3, 5.4
>Reporter: Lenny Primak
>Priority: Minor
>
> Tapestry reloads the zone improperly if JS code 
> Improperly submits the form.  It should at least give some kind of an error
> or a warning when happens.
> Right now, it fails silently leading to an improper zone reload,
> which leads to weird errors when app is running subsequently.
> If form..setSubmittingElement(() isn't called before form.onsubmit(),
> the Tapestry silently fails and the zone is improperly reloaded.
> ---
> There was an addition of one line:
> $(this.formId).setSubmittingElement($(this.elementId)); // *** ADDED 
> otherwise zone gets improperly reloaded
>  $(this.formId).onsubmit();  // Submit Ajax form
> If you don't add the first line, the form is reloaded improperly after the 
> zone update,
> so it doesn't work the second time.
> This is not documented anywhere, and really hard to debug.
> See threads:
> http://mail-archives.apache.org/mod_mbox/tapestry-users/201110.mbox/%3c21cb9971-ed77-4f37-9c72-501d0f513...@hope.nyc.ny.us%3E
> http://tapestry.1045711.n5.nabble.com/Mixins-stop-working-after-a-zone-update-please-help-td4935912.html

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Reopened] (TAP5-2144) Validation messages do not show from a DateField if the value is unparsable.

2013-07-25 Thread Yunhua Sang (JIRA)

 [ 
https://issues.apache.org/jira/browse/TAP5-2144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Yunhua Sang reopened TAP5-2144:
---


I found the problem is still there. Actually if there is server side exception 
occurred, the zone linked to the form would not get updated. The unparsable 
date exception is server side exception.


> Validation messages do not show from a DateField if the value is unparsable.
> 
>
> Key: TAP5-2144
> URL: https://issues.apache.org/jira/browse/TAP5-2144
> Project: Tapestry 5
>  Issue Type: Bug
>  Components: tapestry-core
>Affects Versions: 5.4
>Reporter: Yunhua Sang
>
> It happens when the Form has a zone parameter. 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> When the form gets submitted, no error message displays if the input is a bad 
> value. Seems the validation does work, just the error message is missing.

--
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-1405) XHR requests should be easily callable from javascript and not rely on a zone

2013-07-25 Thread Paul Stanton (JIRA)

[ 
https://issues.apache.org/jira/browse/TAP5-1405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13720185#comment-13720185
 ] 

Paul Stanton commented on TAP5-1405:


does it handle encoding context parameters?

> XHR requests should be easily callable from javascript and not rely on a zone
> -
>
> Key: TAP5-1405
> URL: https://issues.apache.org/jira/browse/TAP5-1405
> Project: Tapestry 5
>  Issue Type: Improvement
>  Components: tapestry-core
>Affects Versions: 5.2
>Reporter: Paul Stanton
>Assignee: Howard M. Lewis Ship
> Fix For: 5.4
>
>
> I quite often needed to initialise an XHR request-response from javascript. I 
> think it would be a very useful feature for tapestry to expose to it's users.
> The ideal solution would
> 1. not require a zone for wiring (see #TAP5-1404)
> 2. encode context parameters as per server side
> EG
> I ended up writing a function to facilitate this. It handles:
>   1. the zone wiring
>   2. context parameters (unfortunately does not properly conform to encoding 
> rules as per server side generated params)
>   3. query strings (sometimes useful)
>   4. url based session ids (for when cookies are disabled)
> note that the url is usually generated at the server side via 
> ComponentResources.createEventLink.
> function multiZoneUpdate(url, params, zoneId)
> {
> // wire up zone, use dummy if none supplied
> if (typeof(zoneId) == "undefined")
> zoneId = "dummyZone";
> var zoneObject = Tapestry.findZoneManagerForZone(zoneId);
> if (!zoneObject)
> throw "unknown zone: " + zoneId;
> // context params must be an array
> if (!(params instanceof Array))
> params = [params];
> // include query string if supplied
> var qs = "";
> var qsInd = url.indexOf("?");
> if (qsInd != -1)
> {
> qs = url.substring(qsInd);
> url = url.substring(0, qsInd);
> }
> // include jsessionid if exists
> var jsId = "";
> var jsInd = url.indexOf(";");
> if (jsInd != -1)
> {
> jsId = url.substring(jsInd);
> url = url.substring(0, jsInd);
> }
> // build url
> if (params != null)
> for (var p = 0; p < params.length; p++)
> url += "/" + params[p];
> // request
> zoneObject.updateFromURL(url + jsId + qs);
> }

--
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-1861) Wrap javascript call rendering apis for interoperability and convenience

2013-07-25 Thread Paul Stanton (JIRA)

[ 
https://issues.apache.org/jira/browse/TAP5-1861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13720180#comment-13720180
 ] 

Paul Stanton commented on TAP5-1861:


Hi Howard,

I've made some discoveries which make the implementation posted here out of 
date; i'm sure you are aware of the following:

1. if in the render or event handling phase of a normal request, 
JavaScriptSupport must be used over AjaxResponseRenderer
2. if in the event handling phase of an ajax request AjaxResponseRenderer must 
be used over JavaScriptSupport
however this was news to me:
3. if in the 'render phase' of an ajax request, JavaScriptSupport must be used 
over AjaxResponseRenderer

.. and in this third case, the 'isXHR' test is not sufficient; the only way to 
determine this case is to 'peek' for JavaScriptSupport.

therefore, my current implementation of the previously posted utility looks 
like this:

public void addScript(final InitializationPriority priority, final 
String format, final Object... args)
{
if (!request.isXHR()
|| env.peek(JavaScriptSupport.class) != null)
{
jsSupport.addScript(priority, format, args);
return;
}

ajaxResponseRenderer.addCallback(new JavaScriptCallback()
{
@Override
public void run(JavaScriptSupport javascriptSupport)
{
javascriptSupport.addScript(priority, format, 
args);
}
});
}

I hope this helps design whatever solution you come up with.

Regards, Paul.

> Wrap javascript call rendering apis for interoperability and convenience
> 
>
> Key: TAP5-1861
> URL: https://issues.apache.org/jira/browse/TAP5-1861
> Project: Tapestry 5
>  Issue Type: Improvement
>  Components: tapestry-core
>Affects Versions: 5.3.2
>Reporter: Paul Stanton
>Assignee: Howard M. Lewis Ship
>  Labels: ajax, javascript
>
> Vast improvements to the ajax and javascript rendering API's have made things 
> much easier to use in tapestry 5.2+, however I still think there is room for 
> improvement. I find I can't work without this 'helper' service I designed to 
> standardise script call rendering between xhr and non-xhr requests. The main 
> motivation/benefit is that a set of functionality can now be called in either 
> (xhr/non-xhr) context and still work. It also has the benefit of building the 
> necessary JavaScriptCallback in the xhr context. In my opinion, this makes 
> user code much tidier:
> public class JavascriptHelperImpl implements JavascriptHelper
> {
> @Inject
> private AjaxResponseRenderer ajaxResponseRenderer;
> @Inject
> private Request request;
> @Inject
> private JavaScriptSupport jsSupport;
> @Override
> public void addScript(final String format, final Object... args)
> {
> if (!request.isXHR())
> {
> jsSupport.addScript(format, args);
> return;
> }
> ajaxResponseRenderer.addCallback(new JavaScriptCallback()
> {
> @Override
> public void run(JavaScriptSupport javascriptSupport)
> {
> javascriptSupport.addScript(format, args);
> }
> });
> }
> }
> There may or may not be additional opportunity with the other methods such as 
> 'addInitializerCall' but I haven't needed to.
> This code is free for anyone (including apache/tapestry) to use.

--
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-1739) Remove Javassist dependency and related services: CallFactory, ClassFab, etc.

2013-07-25 Thread Howard M. Lewis Ship (JIRA)

 [ 
https://issues.apache.org/jira/browse/TAP5-1739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Howard M. Lewis Ship closed TAP5-1739.
--

   Resolution: Duplicate
Fix Version/s: (was: 5.4)

> Remove Javassist dependency and related services: CallFactory, ClassFab, etc.
> -
>
> Key: TAP5-1739
> URL: https://issues.apache.org/jira/browse/TAP5-1739
> Project: Tapestry 5
>  Issue Type: Sub-task
>Reporter: Howard M. Lewis Ship
>Assignee: Howard M. Lewis Ship
>


--
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] [Reopened] (TAP5-1739) Remove Javassist dependency and related services: CallFactory, ClassFab, etc.

2013-07-25 Thread Howard M. Lewis Ship (JIRA)

 [ 
https://issues.apache.org/jira/browse/TAP5-1739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Howard M. Lewis Ship reopened TAP5-1739:



> Remove Javassist dependency and related services: CallFactory, ClassFab, etc.
> -
>
> Key: TAP5-1739
> URL: https://issues.apache.org/jira/browse/TAP5-1739
> Project: Tapestry 5
>  Issue Type: Sub-task
>Reporter: Howard M. Lewis Ship
>Assignee: Howard M. Lewis Ship
> Fix For: 5.4
>
>


--
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-775) AjaxFormLoop should expose (via properties and/or a method on AjaxFormLoopContext) the id of the FormInjector or FormFragment that is rendering (to faciliate JavaScript gene

2013-07-25 Thread Howard M. Lewis Ship (JIRA)

 [ 
https://issues.apache.org/jira/browse/TAP5-775?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Howard M. Lewis Ship closed TAP5-775.
-

Resolution: Won't Fix

> AjaxFormLoop should expose (via properties and/or a method on 
> AjaxFormLoopContext) the id of the FormInjector or FormFragment that is 
> rendering (to faciliate JavaScript generation)
> 
>
> Key: TAP5-775
> URL: https://issues.apache.org/jira/browse/TAP5-775
> Project: Tapestry 5
>  Issue Type: Improvement
>  Components: tapestry-core
>Affects Versions: 5.0.19
>Reporter: Howard M. Lewis Ship
>  Labels: bulk-close-candidate
>
> Context: trying to make FormFragments within an AjaxFormLoop draggable (for 
> re-ordering purposes).

--
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-999) Implement an agnostic tapestry.js layer + adapters to allow developers to switch from prototype to jquery

2013-07-25 Thread Howard M. Lewis Ship (JIRA)

 [ 
https://issues.apache.org/jira/browse/TAP5-999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Howard M. Lewis Ship updated TAP5-999:
--

Issue Type: New Feature  (was: Wish)

> Implement an agnostic tapestry.js layer + adapters to allow developers to 
> switch from prototype to jquery
> -
>
> Key: TAP5-999
> URL: https://issues.apache.org/jira/browse/TAP5-999
> Project: Tapestry 5
>  Issue Type: New Feature
>  Components: tapestry-core
>Affects Versions: 5.1.0.7, 5.0.19
>Reporter: Christophe Cordenier
>Assignee: Howard M. Lewis Ship
> Fix For: 5.4
>
>
> As per the discussion on the mailing about Tapestry 5 and jQuery, i create 
> this JIRA to compile the toughts of everyone for this feature.
> As Howard said on the mailing list, goals are :
> Goal #1: Backwards compatibility
> Goal #2: Documented
> Goal #3: Plugability / Extensibility / Overridablilty
> First design thoughts suggested by howard are (extracted from Howard's 
> answer) :
> 1. tapestry.js defines a Tapestry namespace with key function properties for 
> the standard stuff
> 2. split current tapestry.js into more smaller files
> 3. In addition to tapestry.js, ... include either 
> tapestry-prototype-adapter.js (plus prototype.js and scriptaculous.js) OR 
> tapestry-jquery-adapter.js (plus jquery.js).
> 4. tapestry.js [should] be smaller handlers that often just fire additional 
> events; a cascade of events that eventually results in server-side requests
> Objectives :
> 1. make certain parts more pluggable i.e. Popup Bubbles
> 2. write javascript with functional closures
> 3. ... element could have at most one active animation; the animation would 
> have to complete before the next one (cf. jQuery animation and queuing 
> mechanism)
> Challenges :
> 1. Remove prototype code from tapestry.js
> 2. Keep backward compatibility with existing Tapestry object

--
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-776) Tapestry.FormFragment (client side) should be refactored to be easier to modify

2013-07-25 Thread Howard M. Lewis Ship (JIRA)

 [ 
https://issues.apache.org/jira/browse/TAP5-776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Howard M. Lewis Ship closed TAP5-776.
-

Resolution: Invalid

I don't believe this makes sense anymore, in the context of Tapestry 5.4.

> Tapestry.FormFragment (client side) should be refactored to be easier to 
> modify
> ---
>
> Key: TAP5-776
> URL: https://issues.apache.org/jira/browse/TAP5-776
> Project: Tapestry 5
>  Issue Type: Improvement
>  Components: tapestry-core
>Affects Versions: 5.1.0.5
>Reporter: Howard M. Lewis Ship
>  Labels: bulk-close-candidate
>
> It would be nice if:
> a) The DOM element has a property pointing to the Tapestry.FormInjector 
> object.  I.e. $T(div).formFragment.
> b) Tapestry.FormFragment had methods for adding new content (ala 
> FormInjector) above or below the existing FormFragment.
> c) implicit in above: mix and match of FormInjector and FormFragment, to 
> allow easier ability to build AjaxFormLoop with buttons to add new rows above 
> or below existing rows.

--
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] [Reopened] (TAP5-999) Implement an agnostic tapestry.js layer + adapters to allow developers to switch from prototype to jquery

2013-07-25 Thread Howard M. Lewis Ship (JIRA)

 [ 
https://issues.apache.org/jira/browse/TAP5-999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Howard M. Lewis Ship reopened TAP5-999:
---


> Implement an agnostic tapestry.js layer + adapters to allow developers to 
> switch from prototype to jquery
> -
>
> Key: TAP5-999
> URL: https://issues.apache.org/jira/browse/TAP5-999
> Project: Tapestry 5
>  Issue Type: Wish
>  Components: tapestry-core
>Affects Versions: 5.1.0.7, 5.0.19
>Reporter: Christophe Cordenier
>Assignee: Howard M. Lewis Ship
> Fix For: 5.4
>
>
> As per the discussion on the mailing about Tapestry 5 and jQuery, i create 
> this JIRA to compile the toughts of everyone for this feature.
> As Howard said on the mailing list, goals are :
> Goal #1: Backwards compatibility
> Goal #2: Documented
> Goal #3: Plugability / Extensibility / Overridablilty
> First design thoughts suggested by howard are (extracted from Howard's 
> answer) :
> 1. tapestry.js defines a Tapestry namespace with key function properties for 
> the standard stuff
> 2. split current tapestry.js into more smaller files
> 3. In addition to tapestry.js, ... include either 
> tapestry-prototype-adapter.js (plus prototype.js and scriptaculous.js) OR 
> tapestry-jquery-adapter.js (plus jquery.js).
> 4. tapestry.js [should] be smaller handlers that often just fire additional 
> events; a cascade of events that eventually results in server-side requests
> Objectives :
> 1. make certain parts more pluggable i.e. Popup Bubbles
> 2. write javascript with functional closures
> 3. ... element could have at most one active animation; the animation would 
> have to complete before the next one (cf. jQuery animation and queuing 
> mechanism)
> Challenges :
> 1. Remove prototype code from tapestry.js
> 2. Keep backward compatibility with existing Tapestry object

--
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-999) Implement an agnostic tapestry.js layer + adapters to allow developers to switch from prototype to jquery

2013-07-25 Thread Howard M. Lewis Ship (JIRA)

 [ 
https://issues.apache.org/jira/browse/TAP5-999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Howard M. Lewis Ship closed TAP5-999.
-

Resolution: Fixed

> Implement an agnostic tapestry.js layer + adapters to allow developers to 
> switch from prototype to jquery
> -
>
> Key: TAP5-999
> URL: https://issues.apache.org/jira/browse/TAP5-999
> Project: Tapestry 5
>  Issue Type: New Feature
>  Components: tapestry-core
>Affects Versions: 5.1.0.7, 5.0.19
>Reporter: Christophe Cordenier
>Assignee: Howard M. Lewis Ship
> Fix For: 5.4
>
>
> As per the discussion on the mailing about Tapestry 5 and jQuery, i create 
> this JIRA to compile the toughts of everyone for this feature.
> As Howard said on the mailing list, goals are :
> Goal #1: Backwards compatibility
> Goal #2: Documented
> Goal #3: Plugability / Extensibility / Overridablilty
> First design thoughts suggested by howard are (extracted from Howard's 
> answer) :
> 1. tapestry.js defines a Tapestry namespace with key function properties for 
> the standard stuff
> 2. split current tapestry.js into more smaller files
> 3. In addition to tapestry.js, ... include either 
> tapestry-prototype-adapter.js (plus prototype.js and scriptaculous.js) OR 
> tapestry-jquery-adapter.js (plus jquery.js).
> 4. tapestry.js [should] be smaller handlers that often just fire additional 
> events; a cascade of events that eventually results in server-side requests
> Objectives :
> 1. make certain parts more pluggable i.e. Popup Bubbles
> 2. write javascript with functional closures
> 3. ... element could have at most one active animation; the animation would 
> have to complete before the next one (cf. jQuery animation and queuing 
> mechanism)
> Challenges :
> 1. Remove prototype code from tapestry.js
> 2. Keep backward compatibility with existing Tapestry object

--
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] [Assigned] (TAP5-952) Make tapestry-core independent from test dependencies

2013-07-25 Thread Howard M. Lewis Ship (JIRA)

 [ 
https://issues.apache.org/jira/browse/TAP5-952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Howard M. Lewis Ship reassigned TAP5-952:
-

Assignee: Howard M. Lewis Ship  (was: Igor Drobiazko)

> Make tapestry-core independent from test dependencies
> -
>
> Key: TAP5-952
> URL: https://issues.apache.org/jira/browse/TAP5-952
> Project: Tapestry 5
>  Issue Type: Improvement
>  Components: tapestry-core, tapestry-test
>Affects Versions: 5.1.0.5
>Reporter: Igor Drobiazko
>Assignee: Howard M. Lewis Ship
>
> In tapestry-core we provide a few classes which depenend on EasyMock and 
> TestNG. This is very annoying when creating a Tapestry OSGi bundle with the 
> BND tool. 
> Following is needed:
> - Move package org.apache.tapestry5.test from tapestry-core into tapestry-test
> - Set scope of tapestry-test to test
> This issue is conflicting with TAP5-758

--
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] [Assigned] (TAP5-902) GridDataSource does not allow performing less than 2 queries if returning results

2013-07-25 Thread Howard M. Lewis Ship (JIRA)

 [ 
https://issues.apache.org/jira/browse/TAP5-902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Howard M. Lewis Ship reassigned TAP5-902:
-

Assignee: Howard M. Lewis Ship

> GridDataSource does not allow performing less than 2 queries if returning 
> results
> -
>
> Key: TAP5-902
> URL: https://issues.apache.org/jira/browse/TAP5-902
> Project: Tapestry 5
>  Issue Type: Improvement
>  Components: tapestry-core
>Affects Versions: 5.1.0.5
>Reporter: Dan Adams
>Assignee: Howard M. Lewis Ship
>  Labels: bulk-close-candidate
>
> By having getAvailableRows() and prepare() separate, any implementation is 
> forced to perform 2 queries. Many systems allow getting the results of a 
> query and the total count in one query so that you don't have to perform 2 
> queries. Getting around this requires some pretty gross hacks (unless you 
> just don't use grid at all which is unfortunate).

--
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-809) Spring services should be decoratable

2013-07-25 Thread Howard M. Lewis Ship (JIRA)

 [ 
https://issues.apache.org/jira/browse/TAP5-809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Howard M. Lewis Ship closed TAP5-809.
-

Resolution: Won't Fix

> Spring services should be decoratable
> -
>
> Key: TAP5-809
> URL: https://issues.apache.org/jira/browse/TAP5-809
> Project: Tapestry 5
>  Issue Type: Improvement
>  Components: tapestry-spring
>Affects Versions: 5.1.0.5
>Reporter: Carl Crowder
>  Labels: bulk-close-candidate
> Attachments: spring_service_decoration.patch
>
>
> SpringBeanServiceDef returns "true" for isPreventDecoration() which causes 
> any attempts to decorate services created in Spring to fail silently.
> As far as I can tell there's no need for them to not be decoratable - I asked 
> on the mailing list and noone objected, and having changed it locally the 
> tests all run fine.
> If there is a valid reason then at least the service builder should log a 
> warning rather than plunge on ignoring the decoration method.
> I've attached a (very simple) patch to enable decoration of spring services.

--
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-882) It would be great if someof the logic for resolving a vallidation message could be made public, perhaps as part of ValidationMessagesSource

2013-07-25 Thread Howard M. Lewis Ship (JIRA)

 [ 
https://issues.apache.org/jira/browse/TAP5-882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Howard M. Lewis Ship closed TAP5-882.
-

Resolution: Won't Fix

> It would be great if someof the logic for resolving a vallidation message 
> could be made public, perhaps as part of ValidationMessagesSource
> ---
>
> Key: TAP5-882
> URL: https://issues.apache.org/jira/browse/TAP5-882
> Project: Tapestry 5
>  Issue Type: Improvement
>  Components: tapestry-core
>Affects Versions: 5.2
>Reporter: Howard M. Lewis Ship
>
> I often write special-purpose mixins that act much like a validator, and I'd 
> like to have the same lookup capabilities for finding the error message for 
> the validator that is available for true validators.

--
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-1063) exception is thrown if web-browser closes HTTP connection prematurely

2013-07-25 Thread Howard M. Lewis Ship (JIRA)

 [ 
https://issues.apache.org/jira/browse/TAP5-1063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Howard M. Lewis Ship closed TAP5-1063.
--

Resolution: Invalid

> exception is thrown if web-browser closes HTTP connection prematurely
> -
>
> Key: TAP5-1063
> URL: https://issues.apache.org/jira/browse/TAP5-1063
> Project: Tapestry 5
>  Issue Type: Improvement
>  Components: tapestry-core
>Affects Versions: 5.1.0.5
>Reporter: Neeme Praks
>  Labels: bulk-close-candidate
>
> Sometimes we see exceptions such as below in our logs.
> I suspect this is due to the fact that client browser has closed HTTP 
> connection (navigated to different page already or something like that) and 
> jetty then throws exception as it cannot write the response out.
> I guess the best solution to this would be to add a configuration flag to 
> suppress this kind of errors (just swallow them or log on DEBUG level).
> The stacktrace:
> {noformat}
> 2010-03-13 14:10:40,710 ERROR [btpool0-110] 
> [tapestry.render.com.mycompany.zps.web.admin.pages.ViewPrivateZone]
> - Render queue error in BeginRender[ViewPrivateZone:layout.logoutlink]: 
> Committed
> org.apache.tapestry5.ioc.internal.util.TapestryException: Committed [at 
> classpath:com/mycompany/zps/web/admin/components/Layout.tml, line 24]
> at 
> org.apache.tapestry5.internal.structure.ComponentPageElementImpl.invoke(ComponentPageElementImpl.java:948)
> at 
> org.apache.tapestry5.internal.structure.ComponentPageElementImpl.access$400(ComponentPageElementImpl.java:49)
> at 
> org.apache.tapestry5.internal.structure.ComponentPageElementImpl$AbstractPhase.callback(ComponentPageElementImpl.java:159)
> at 
> org.apache.tapestry5.internal.structure.ComponentPageElementImpl$BeginRenderPhase.render(ComponentPageElementImpl.java:211)
> at 
> org.apache.tapestry5.internal.services.RenderQueueImpl.run(RenderQueueImpl.java:74)
> at 
> org.apache.tapestry5.internal.services.PageRenderQueueImpl.render(PageRenderQueueImpl.java:121)
> at 
> $PageRenderQueue_1275673a10e.render($PageRenderQueue_1275673a10e.java)
> at 
> $PageRenderQueue_1275673a0f6.render($PageRenderQueue_1275673a0f6.java)
> at 
> org.apache.tapestry5.internal.services.MarkupRendererTerminator.renderMarkup(MarkupRendererTerminator.java:37)
> at 
> org.apache.tapestry5.services.TapestryModule$27.renderMarkup(TapestryModule.java:1748)
> at 
> $MarkupRenderer_1275673a110.renderMarkup($MarkupRenderer_1275673a110.java)
> at 
> org.apache.tapestry5.services.TapestryModule$26.renderMarkup(TapestryModule.java:1732)
> at 
> $MarkupRenderer_1275673a110.renderMarkup($MarkupRenderer_1275673a110.java)
> at 
> org.apache.tapestry5.services.TapestryModule$25.renderMarkup(TapestryModule.java:1714)
> at 
> $MarkupRenderer_1275673a110.renderMarkup($MarkupRenderer_1275673a110.java)
> at 
> org.apache.tapestry5.services.TapestryModule$24.renderMarkup(TapestryModule.java:1700)
> at 
> $MarkupRenderer_1275673a110.renderMarkup($MarkupRenderer_1275673a110.java)
> at 
> org.apache.tapestry5.services.TapestryModule$23.renderMarkup(TapestryModule.java:1681)
> at 
> $MarkupRenderer_1275673a110.renderMarkup($MarkupRenderer_1275673a110.java)
> at 
> org.apache.tapestry5.services.TapestryModule$22.renderMarkup(TapestryModule.java:1662)
> at 
> $MarkupRenderer_1275673a110.renderMarkup($MarkupRenderer_1275673a110.java)
> at 
> $MarkupRenderer_1275673a10d.renderMarkup($MarkupRenderer_1275673a10d.java)
> at 
> org.apache.tapestry5.internal.services.PageMarkupRendererImpl.renderPageMarkup(PageMarkupRendererImpl.java:64)
> at 
> $PageMarkupRenderer_1275673a10b.renderPageMarkup($PageMarkupRenderer_1275673a10b.java)
> at 
> org.apache.tapestry5.internal.services.PageResponseRendererImpl.renderPageResponse(PageResponseRendererImpl.java:61)
> at 
> $PageResponseRenderer_1275673a08e.renderPageResponse($PageResponseRenderer_1275673a08e.java)
> at 
> org.apache.tapestry5.internal.services.PageRenderRequestHandlerImpl.handle(PageRenderRequestHandlerImpl.java:63)
> at 
> org.apache.tapestry5.services.TapestryModule$33.handle(TapestryModule.java:1943)
> at 
> $PageRenderRequestHandler_1275673a109.handle($PageRenderRequestHandler_1275673a109.java)
> at 
> com.mycompany.zps.web.admin.services.PageAccessController.handle(PageAccessController.java:60)
> at 
> $PageRenderRequestHandler_1275673a109.handle($PageRenderRequestHandler_1275673a109.java)
> at 
> $PageRenderRequestHandler_1275673a07a.handle($PageRenderRequestHandler_1275673a07a.java)
> at 
> org.apache.tapestry5.internal.services.ComponentReq

[jira] [Closed] (TAP5-1103) Add "SeleniumOnlyLauncher" (code provided)

2013-07-25 Thread Howard M. Lewis Ship (JIRA)

 [ 
https://issues.apache.org/jira/browse/TAP5-1103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Howard M. Lewis Ship closed TAP5-1103.
--

Resolution: Won't Fix

> Add "SeleniumOnlyLauncher" (code provided)
> --
>
> Key: TAP5-1103
> URL: https://issues.apache.org/jira/browse/TAP5-1103
> Project: Tapestry 5
>  Issue Type: Improvement
>Reporter: Pierce Wetter
>
> Include a class in tapestry-test that only launches Selenium, not Jetty or 
> any other server. This lets you run tests where you've launched the 
> application in some other way (various maven plugins, etc. )
> /**
>  * Override of SeleniumLauncher to skip the webserver launch entirely. 
>  *
>  * @author  pierce
>  */
> public class SeleniumOnly extends SeleniumLauncher
> {
> 
> @Override
> protected Runnable launchWebServer(
> String webAppFolder, String contextPath, int port, int sslPort
> ) throws Exception
> {
> System.out.println(" webserver start");
> return new Runnable()
> {
> @Override
> public void run()
> {
> System.out.println(" webserver stop");
> }
> };
> }
> }

--
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-1078) Refactor the management of ServiceProxyProvider

2013-07-25 Thread Howard M. Lewis Ship (JIRA)

 [ 
https://issues.apache.org/jira/browse/TAP5-1078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Howard M. Lewis Ship closed TAP5-1078.
--

Resolution: Won't Fix

> Refactor the management of ServiceProxyProvider
> ---
>
> Key: TAP5-1078
> URL: https://issues.apache.org/jira/browse/TAP5-1078
> Project: Tapestry 5
>  Issue Type: Improvement
>  Components: tapestry-ioc
>Affects Versions: 5.1.0.5
>Reporter: Igor Drobiazko
>
> Currently the ServiceProxyProvider/Registry is stored in a static field of 
> SerializationSupport and retrieved via static methods. This approach works 
> fine if Tapestry IoC JAR is located in WEB-INF/lib of an application. 
> Unfortunately this approach is not compatible with OSGi where Tapestry IoC 
> bundle is shared by several bundles, each creating its own Registry. The 
> registry does a SerializationSupport #setProvider() at startup. Starting 
> several Registries inside a JVM it is not possible to make sure that the 
> Registry reference in SerializationSupport  is always the same.
> I realized the problem starting two OSGi bundles, each starting its own 
> Registry. When one of these bundles is stopped, its Registry is shut down. In 
> this case we see the following log message:
> 25.03.2010 10:47:04,680 # ERROR # 
> org.apache.tapestry5.ioc.internal.SerializationSupport # 
> [SerializationSupport.setProvider] # Setting a new service proxy provider 
> when there's already an existing provider. This may indicate that you have 
> multiple IoC Registries.
> We should refactor the management of ServiceProxyProvider. I think it is 
> sufficient to move the logic of SerializationSupport into InternalRegistry.

--
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] [Assigned] (TAP5-1007) When Tapestry is loading templates or other files on case-insensitive OSs (Windows) it should trigger an error if the file name case is incorrect (which will result in a

2013-07-25 Thread Howard M. Lewis Ship (JIRA)

 [ 
https://issues.apache.org/jira/browse/TAP5-1007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Howard M. Lewis Ship reassigned TAP5-1007:
--

Assignee: Howard M. Lewis Ship

> When Tapestry is loading templates or other files on case-insensitive OSs 
> (Windows) it should trigger an error if the file name case is incorrect 
> (which will result in a runtime failure on case-sensitive OSs, such as Linux)
> ---
>
> Key: TAP5-1007
> URL: https://issues.apache.org/jira/browse/TAP5-1007
> Project: Tapestry 5
>  Issue Type: Improvement
>  Components: tapestry-core
>Affects Versions: 5.2
>Reporter: Howard M. Lewis Ship
>Assignee: Howard M. Lewis Ship
>
> In other words, on Windows you might find file "myComponent.tml" when it 
> should be named "MyComponent.tml" (to match the name of the class, 
> MyComponent).  This is irritating to find in testing or production, and 
> Tapestry should be able to add a check that the case of the file name does 
> not match the expected case.

--
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-1119) The various AssetRequestHandlers in 5.2 and VirtualAssetDispatcher in 5.1 should send 304 Not Modified if asset not modified since last downloaded.

2013-07-25 Thread Howard M. Lewis Ship (JIRA)

 [ 
https://issues.apache.org/jira/browse/TAP5-1119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Howard M. Lewis Ship closed TAP5-1119.
--

Resolution: Invalid

Asset processing has changed completely since 5.2; your concerns have been 
addressed ... and then some.

> The various AssetRequestHandlers in 5.2 and  VirtualAssetDispatcher in 5.1 
> should send 304 Not Modified if asset not modified since last downloaded.
> 
>
> Key: TAP5-1119
> URL: https://issues.apache.org/jira/browse/TAP5-1119
> Project: Tapestry 5
>  Issue Type: Improvement
>  Components: tapestry-core
>Affects Versions: 5.2
>Reporter: Paudi Moriarty
>


--
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-1140) Extend the support for JS localization from within the framework to users of the framework.

2013-07-25 Thread Howard M. Lewis Ship (JIRA)

 [ 
https://issues.apache.org/jira/browse/TAP5-1140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Howard M. Lewis Ship closed TAP5-1140.
--

Resolution: Invalid

Please define more exactly what you need. Also 5.4 goes a long way towards this 
by exposing the application message catalog to the client side via the 
t5/core/messages module.

> Extend the support for JS localization from within the framework to users of 
> the framework.
> ---
>
> Key: TAP5-1140
> URL: https://issues.apache.org/jira/browse/TAP5-1140
> Project: Tapestry 5
>  Issue Type: Improvement
>  Components: tapestry-core
>Reporter: Shankar Prasad Jha
>
> The support for picking up the appropriate js file for localization exists in 
> the tapestry framework and is being used for localization of tapestry.js. But 
> this feature is not exposed to the applications using tapestry. The methods 
> of RenderSupport interface which provide the ability to add the JavaScripts 
> and CSS do not take locale as the argument. For applications using JS 
> libraries like extJS it would become very simple to localize their 
> applications after addition of this support. 

--
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-1167) LinkSubmit should be a generic mixin

2013-07-25 Thread Howard M. Lewis Ship (JIRA)

 [ 
https://issues.apache.org/jira/browse/TAP5-1167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Howard M. Lewis Ship closed TAP5-1167.
--

Resolution: Won't Fix

> LinkSubmit should be a generic mixin
> 
>
> Key: TAP5-1167
> URL: https://issues.apache.org/jira/browse/TAP5-1167
> Project: Tapestry 5
>  Issue Type: Improvement
>  Components: tapestry-core
>Reporter: Inge
>
> See 
> http://tinybits.blogspot.com/2010/05/mixin-to-allow-any-element-to-submit.html
> With minor changes, the LinkSubmit component can be much more flexible, 
> allowing for example dropdowns and checkboxes to submit forms.

--
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-1183) Factor out TestUtils methods that aren't assertion-related so they can be used wihout requiring TestNG in teh classpath.

2013-07-25 Thread Howard M. Lewis Ship (JIRA)

 [ 
https://issues.apache.org/jira/browse/TAP5-1183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Howard M. Lewis Ship closed TAP5-1183.
--

Resolution: Won't Fix

The Selenium and TestNG support in Tapestry can be considered "for internal use 
only" in 5.4; I favor Spock and Geb now and encourage their use.

> Factor out TestUtils methods that aren't assertion-related so they can be 
> used wihout requiring TestNG in teh classpath.
> 
>
> Key: TAP5-1183
> URL: https://issues.apache.org/jira/browse/TAP5-1183
> Project: Tapestry 5
>  Issue Type: Improvement
>  Components: tapestry-ioc
>Affects Versions: 5.2
>Reporter: Christian E Gruber
> Attachments: extract-property-utils.patch
>
>
> TestUtils provides two classes of functionality - one which provides 
> additional Assertions, and other which provides methods for handling 
> components containing @Property annotations.
> TestUtils forms the base class for TestBase, in order to conveniently provide 
> access to the assertion methods, and to that end also inherits 
> org.testng.Assert.  The second class of functionality is valuable regardless 
> of your testing framework, but requires that TestNG be in the classpath to 
> satisfy the structural dependency.  It would be preferable for these three 
> (plus one private) methods to be pulled out of TestUtils into another class, 
> perhaps with delegating methods retained for backwards compatibility.

--
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-1231) Exception message about wrong configuration type should be more precise

2013-07-25 Thread Howard M. Lewis Ship (JIRA)

 [ 
https://issues.apache.org/jira/browse/TAP5-1231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Howard M. Lewis Ship closed TAP5-1231.
--

Resolution: Invalid

What else could it say?  You used Configuration not MappedConfiguration.

> Exception message about wrong configuration type should be more precise
> ---
>
> Key: TAP5-1231
> URL: https://issues.apache.org/jira/browse/TAP5-1231
> Project: Tapestry 5
>  Issue Type: Improvement
>  Components: tapestry-core
>Affects Versions: 5.2
>Reporter: Igor Drobiazko
>
> Currently the message is 
> Service 'XYZ' is configured using 
> org.apache.tapestry5.ioc.MappedConfiguration, not 
> org.apache.tapestry5.ioc.Configuration.
> This message is not precise enough. It should be emphasize which 
> configuration type is actually expected and configuration type is used.

--
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-1268) Have Tapestry's core library contribute to the global message catalog; move all validation messages and component catalogs to the single file

2013-07-25 Thread Howard M. Lewis Ship (JIRA)

 [ 
https://issues.apache.org/jira/browse/TAP5-1268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Howard M. Lewis Ship closed TAP5-1268.
--

   Resolution: Fixed
Fix Version/s: 5.4
 Assignee: Howard M. Lewis Ship

> Have Tapestry's core library contribute to the global message catalog; move 
> all validation messages and component catalogs to the single file
> -
>
> Key: TAP5-1268
> URL: https://issues.apache.org/jira/browse/TAP5-1268
> Project: Tapestry 5
>  Issue Type: Improvement
>  Components: tapestry-core
>Affects Versions: 5.2
>Reporter: Howard M. Lewis Ship
>Assignee: Howard M. Lewis Ship
> Fix For: 5.4
>
>
> I see this as something for 5.3.
> Basically, combine all the localized messages for the core library into a 
> single message catalog. This includes content that is currently in component 
> message catalogs, as well as content in validation  message catalogs.
> The core message catalog could be contributed to the global message catalog, 
> ahead of the applications' message catalog. This would allow an application 
> to easily override any of these messages from the core library.
> It would also make adding and maintaining localizations easier, as there 
> would be just a single file's content to be translated.
> It may be a good chance to up∂ate the various message keys to be unique and 
> unambiguous. Possilby adding a "t-" prefix as well.

--
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-1316) Quickstart should include a Selenium based smoke test

2013-07-25 Thread Howard M. Lewis Ship (JIRA)

[ 
https://issues.apache.org/jira/browse/TAP5-1316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13720080#comment-13720080
 ] 

Howard M. Lewis Ship commented on TAP5-1316:


At this point, the test would almost certainly be written in Geb.  We've been 
making progress on removing the tapestry testing stuff in favor of Geb.

> Quickstart should include a Selenium based smoke test
> -
>
> Key: TAP5-1316
> URL: https://issues.apache.org/jira/browse/TAP5-1316
> Project: Tapestry 5
>  Issue Type: Improvement
>  Components: quickstart
>Affects Versions: 5.2
>Reporter: Howard M. Lewis Ship
> Attachments: TAP-1316.diff
>
>
> ... including testng.xml and src/test/conf/ff_profile_template if that's 
> applicable.  Just enough to get people started.

--
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] [Assigned] (TAP5-1290) Add required flag to @ActivationRequestParameter annotation

2013-07-25 Thread Howard M. Lewis Ship (JIRA)

 [ 
https://issues.apache.org/jira/browse/TAP5-1290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Howard M. Lewis Ship reassigned TAP5-1290:
--

Assignee: Howard M. Lewis Ship

> Add required flag to @ActivationRequestParameter annotation
> ---
>
> Key: TAP5-1290
> URL: https://issues.apache.org/jira/browse/TAP5-1290
> Project: Tapestry 5
>  Issue Type: Improvement
>Affects Versions: 5.2
> Environment: Tapestry 5.2.0 alpha
>Reporter: Vjeran Marcinko
>Assignee: Howard M. Lewis Ship
>
> It would be really nice to have "required" argument in 
> @ActivationRequestParameter so one doesn't have to check it manually before 
> page rendering begins.
> I guess many people such as me, who don't care about RESTful URLs, will find 
> @ActivationRequestParameter much easier way to pass render parameters than 
> standard activation context, not just because it offers naming and 
> optionality, but also because one have clean separation between parameter 
> setting process (through this annotation) and preprocessing logic needed for 
> some pages (placed in onActivate, such as security check or other mutli page 
> preprocesing logic; request filters is sometimes too cumbersome way to 
> achieve the same). Required flag would be nice addition to make it truly 
> top-level way to pass render params.

--
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-1358) GridPager links need to send page's request parameters

2013-07-25 Thread Howard M. Lewis Ship (JIRA)

 [ 
https://issues.apache.org/jira/browse/TAP5-1358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Howard M. Lewis Ship closed TAP5-1358.
--

Resolution: Invalid

I believe this is addressed using the @ActivationRequestParameter annotation.

> GridPager links need to send page's request parameters
> --
>
> Key: TAP5-1358
> URL: https://issues.apache.org/jira/browse/TAP5-1358
> Project: Tapestry 5
>  Issue Type: Improvement
>  Components: tapestry-core
>Affects Versions: 5.1.0.5
>Reporter: Geoff Callender
>  Labels: bulk-close-candidate
>
> GridPager uses EventLinks, but EventLink has a problem: even though it DOES 
> send the page's activation context (which is good), it DOESN'T send the 
> page's request parameters (which is bad)!  
> Does this happen in 5.2 too?
> This is a real problem since I like to put search/filter criteria into 
> request parameters and not the context. The problem is that when I click on a 
> GridPager link I lose the search/filter criteria. Why do I use request 
> parameters for search/filter criteria? Because it is arguably more RESTful. 
> See 
> 
> http://jumpstart.doublenegative.com.au/jumpstart/examples/state/passingdatabetweenpages1
> 
> http://blpsilva.wordpress.com/2008/04/05/query-strings-in-restful-web-services/
> Example
> A page has enterable search criteria fields (name, department, status). 
> Type in a name and submit the page. We redisplay with the Grid populated and 
> more than one grid page.
> If the page puts the search criteria in the activation context then the 
> GridPager's link to page 2 looks fine - like this...
> http://localhost/myapp/things/index.grid.pager/2?t:ac=jack/$N/ACTIVE
> ...however if the page puts the search criteria in the request parameters, 
> then the GridPager's link to page 2 looks inadequate - like this...
> https://localhost/myapp/things/index.grid.pager/2
> ...but to prevent losing the request parameters it should be like this...
> 
> https://localhost/myapp/things/index.grid.pager/2?name=jack&status=ACTIVE
> I wasted a lot of time figuring out this was what was going wrong, even 
> though I could see this what was happening, because I was refusing to believe 
> that request parameters weren't getting equal treatment in this situation!

--
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-1388) GridPager should be able to display which items are displayed

2013-07-25 Thread Howard M. Lewis Ship (JIRA)

 [ 
https://issues.apache.org/jira/browse/TAP5-1388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Howard M. Lewis Ship closed TAP5-1388.
--

Resolution: Won't Fix

> GridPager should be able to display which items are displayed
> -
>
> Key: TAP5-1388
> URL: https://issues.apache.org/jira/browse/TAP5-1388
> Project: Tapestry 5
>  Issue Type: Improvement
>Affects Versions: 5.3.6, 5.0.15
>Reporter: Nicolas Bouillon
>  Labels: bulk-close-candidate
>
> Would be nice if the Grid Pager could be able to display not just the page 
> number, but also that it's displaying « item 50 to 100 of 2161 ». 

--
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-1364) Documentation about ExtJS integration

2013-07-25 Thread Howard M. Lewis Ship (JIRA)

 [ 
https://issues.apache.org/jira/browse/TAP5-1364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Howard M. Lewis Ship closed TAP5-1364.
--

Resolution: Won't Fix

This has all changed in 5.4; perhaps an issue to allow ExtJS as the foundation 
framework would be appropriate ... though it would likely require some patch to 
let RequireJS be used as the module loader.

> Documentation about ExtJS integration
> -
>
> Key: TAP5-1364
> URL: https://issues.apache.org/jira/browse/TAP5-1364
> Project: Tapestry 5
>  Issue Type: Improvement
>  Components: documentation
>Reporter: Borut Bolcina
>
> Maybe there should be some docs about integrating with other JS libraries at 
> the http://tapestry.apache.org/user-guide.html. Maybe the chapter "Ajax & 
> JavaScript" should be separated. Some clear examples of how to include other 
> js libs would be very helpful.
> I saw a very short email on the user list about extjs integration issue 
> (http://tapestry.markmail.org/thread/6zz7zz7ewuzkengv), but I doubt this 
> "hidden" info will be found early enough for someone trying to start with T5 
> and extjs, before he/she gets in the bad mood.
> I am writing this beforehand - I haven't even tried T5 & ExtJS web app yet, 
> but I am doing a field research as what troubles I might have. I just bought 
> a book "ExtJS in action" so there will be plenty of info from the Extjs side, 
> now I wish there would be some from the T5 side also.
> Thanks!

--
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-1404) Should be possible to perform an Ajax request without linking the component (link or form) to a Zone

2013-07-25 Thread Howard M. Lewis Ship (JIRA)

 [ 
https://issues.apache.org/jira/browse/TAP5-1404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Howard M. Lewis Ship updated TAP5-1404:
---

Summary: Should be possible to perform an Ajax request without linking the 
component (link or form) to a Zone  (was: add 'xhr' parameter to components 
which perform navigation - make zone parameter optional)

> Should be possible to perform an Ajax request without linking the component 
> (link or form) to a Zone
> 
>
> Key: TAP5-1404
> URL: https://issues.apache.org/jira/browse/TAP5-1404
> Project: Tapestry 5
>  Issue Type: Improvement
>Affects Versions: 5.3, 5.2
>Reporter: Paul Stanton
>Assignee: Howard M. Lewis Ship
>
> To specify that you want to perform an XHR request (EventLink, ActionLink, 
> Form etc), you need to supply the zone parameter. The existence of this 
> parameter is a flag that tells the component to use XHR. In some cases this 
> may be useful (although I'm yet to find one). This strikes me as bad design 
> since there is not necessarily a known One-to-One relationship between the 
> event and the zone(s) updated.
> If you return a Zone or MultiZoneUpdate from your event handler, the actual 
> zone you supply the requesting component is irrelevant.
> Since all of my XHR event handlers return a MultiZoneUpdate, I ended up 
> creating a dummy zone on every page and component and supplying that to every 
> zone parameter. The dummy zone was always hidden and never actually updated. 
> This hack made it easier to code and maintain my pages because without it i 
> would need to search for an arbitrary zone on each page when creating 
> callbacks.
> The solution would be to add a 'xhr' parameter to the components (EventLink, 
> Form etc) and for the zone parameter to be an optional if xhr is true.
> You could even hard set xhr=true if zone!=null for backwards compatibility.
> This would require Tapestry to lose the dependency on zones to create 
> contextual XHR requests which I think is the limiting design decision 
> plaguing this area of tapestry.

--
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-1405) XHR requests should be easily callable from javascript and not rely on a zone

2013-07-25 Thread Howard M. Lewis Ship (JIRA)

 [ 
https://issues.apache.org/jira/browse/TAP5-1405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Howard M. Lewis Ship closed TAP5-1405.
--

   Resolution: Fixed
Fix Version/s: 5.4
 Assignee: Howard M. Lewis Ship

Under 5.4, there is now a t5/core/ajax module that makes it easy to perform an 
Ajax request; Tapestry handles things like page initialization, redirects, and 
presenting a server-side exception in the popup iframe.

> XHR requests should be easily callable from javascript and not rely on a zone
> -
>
> Key: TAP5-1405
> URL: https://issues.apache.org/jira/browse/TAP5-1405
> Project: Tapestry 5
>  Issue Type: Improvement
>  Components: tapestry-core
>Affects Versions: 5.2
>Reporter: Paul Stanton
>Assignee: Howard M. Lewis Ship
> Fix For: 5.4
>
>
> I quite often needed to initialise an XHR request-response from javascript. I 
> think it would be a very useful feature for tapestry to expose to it's users.
> The ideal solution would
> 1. not require a zone for wiring (see #TAP5-1404)
> 2. encode context parameters as per server side
> EG
> I ended up writing a function to facilitate this. It handles:
>   1. the zone wiring
>   2. context parameters (unfortunately does not properly conform to encoding 
> rules as per server side generated params)
>   3. query strings (sometimes useful)
>   4. url based session ids (for when cookies are disabled)
> note that the url is usually generated at the server side via 
> ComponentResources.createEventLink.
> function multiZoneUpdate(url, params, zoneId)
> {
> // wire up zone, use dummy if none supplied
> if (typeof(zoneId) == "undefined")
> zoneId = "dummyZone";
> var zoneObject = Tapestry.findZoneManagerForZone(zoneId);
> if (!zoneObject)
> throw "unknown zone: " + zoneId;
> // context params must be an array
> if (!(params instanceof Array))
> params = [params];
> // include query string if supplied
> var qs = "";
> var qsInd = url.indexOf("?");
> if (qsInd != -1)
> {
> qs = url.substring(qsInd);
> url = url.substring(0, qsInd);
> }
> // include jsessionid if exists
> var jsId = "";
> var jsInd = url.indexOf(";");
> if (jsInd != -1)
> {
> jsId = url.substring(jsInd);
> url = url.substring(0, jsInd);
> }
> // build url
> if (params != null)
> for (var p = 0; p < params.length; p++)
> url += "/" + params[p];
> // request
> zoneObject.updateFromURL(url + jsId + qs);
> }

--
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] [Assigned] (TAP5-1404) add 'xhr' parameter to components which perform navigation - make zone parameter optional

2013-07-25 Thread Howard M. Lewis Ship (JIRA)

 [ 
https://issues.apache.org/jira/browse/TAP5-1404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Howard M. Lewis Ship reassigned TAP5-1404:
--

Assignee: Howard M. Lewis Ship

> add 'xhr' parameter to components which perform navigation - make zone 
> parameter optional
> -
>
> Key: TAP5-1404
> URL: https://issues.apache.org/jira/browse/TAP5-1404
> Project: Tapestry 5
>  Issue Type: Improvement
>Affects Versions: 5.3, 5.2
>Reporter: Paul Stanton
>Assignee: Howard M. Lewis Ship
>
> To specify that you want to perform an XHR request (EventLink, ActionLink, 
> Form etc), you need to supply the zone parameter. The existence of this 
> parameter is a flag that tells the component to use XHR. In some cases this 
> may be useful (although I'm yet to find one). This strikes me as bad design 
> since there is not necessarily a known One-to-One relationship between the 
> event and the zone(s) updated.
> If you return a Zone or MultiZoneUpdate from your event handler, the actual 
> zone you supply the requesting component is irrelevant.
> Since all of my XHR event handlers return a MultiZoneUpdate, I ended up 
> creating a dummy zone on every page and component and supplying that to every 
> zone parameter. The dummy zone was always hidden and never actually updated. 
> This hack made it easier to code and maintain my pages because without it i 
> would need to search for an arbitrary zone on each page when creating 
> callbacks.
> The solution would be to add a 'xhr' parameter to the components (EventLink, 
> Form etc) and for the zone parameter to be an optional if xhr is true.
> You could even hard set xhr=true if zone!=null for backwards compatibility.
> This would require Tapestry to lose the dependency on zones to create 
> contextual XHR requests which I think is the limiting design decision 
> plaguing this area of tapestry.

--
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-1470) Group CSS together to avoid IE's restriction of 31 external css files

2013-07-25 Thread Howard M. Lewis Ship (JIRA)

[ 
https://issues.apache.org/jira/browse/TAP5-1470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13720069#comment-13720069
 ] 

Howard M. Lewis Ship commented on TAP5-1470:


I'm thinking about some CSS aggregation for JavaScriptStacks (wow, a better 
name for them might be ClientResourceStack, but that ship has sailed).

> Group CSS together to avoid IE's restriction of 31 external css files
> -
>
> Key: TAP5-1470
> URL: https://issues.apache.org/jira/browse/TAP5-1470
> Project: Tapestry 5
>  Issue Type: Improvement
>  Components: tapestry-core
>Affects Versions: 5.2, 5.1
>Reporter: Michael Wyraz
>
> IE is restricted to load 31 external CSS per page. All other are ignored.
> Also the number of @import declarations are restricted to 30 per css 
> declaration.
> The following change to DocumentLinkerImpl beraks the imported css into 
> blocks. A new block starts when more than 30 @import occured of when the 
> "media" attribute changes.
> protected void addStylesheetsToHead(Element root, 
> List stylesheets)
> {
> int count = stylesheets.size();
> if (count == 0) return;
> // This only applies when the document is an HTML document. This may 
> need to change in the
> // future, perhaps configurable, to allow for html and xhtml and 
> perhaps others. Does SVG
> // use stylesheets?
> String rootElementName = root.getName();
> // Not an html document, don't add anything. 
> if (!rootElementName.equals("html")) return;
> Element head = findOrCreateElement(root, "head", true);
> Element existing = findExistingElement(head, "link");
> // Create a temporary container element.
> Element tempContainer = head.element("temp-container");
> for (int i = 0; i < count; i++)
> stylesheets.get(i).add(tempContainer);
> tempContainer.remove();
> 
> Element container = head.element("css-container");
> // Fix für IE: Immer wenn der "media" Typ wechselt oder 30 CSS 
> erreicht sind, wird ein neues CSS-Tag aufgemacht
> Element style=null;
> int cssCount=Integer.MAX_VALUE;
> String lastMedia="all";
> 
> for (Node _css: tempContainer.getChildren())
> {
> if (!(_css instanceof Element)) continue;
> Element css=(Element) _css;
> String href=css.getAttribute("href");
> String media=css.getAttribute("media");
> if (media==null) media="all";
> 
> if (cssCount>30 || !media.equalsIgnoreCase(lastMedia))
> {
>   style=container.element("style", "type","text/css", 
> "media",media);
>   lastMedia=media;
>   cssCount=0;
> }
> style.text("@import url("+href+");");
> cssCount++;
> }
> if (existing != null)
> container.moveBefore(existing);
> container.pop();
> }

--
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] [Assigned] (TAP5-1446) Improve coercion List -> SelectModel

2013-07-25 Thread Howard M. Lewis Ship (JIRA)

 [ 
https://issues.apache.org/jira/browse/TAP5-1446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Howard M. Lewis Ship reassigned TAP5-1446:
--

Assignee: Howard M. Lewis Ship

> Improve coercion List -> SelectModel
> 
>
> Key: TAP5-1446
> URL: https://issues.apache.org/jira/browse/TAP5-1446
> Project: Tapestry 5
>  Issue Type: Improvement
>  Components: tapestry-core
>Affects Versions: 5.2
>Reporter: Denis Stepanov
>Assignee: Howard M. Lewis Ship
> Attachments: TAP5-1446.patch
>
>
> It should use SelectModelFactory. Labels are extracted from objects using 
> strategy pattern. Users can contribute providers for their own objects. 

--
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-1446) Coercion from List to SelectModel should use the SelectModelFactory service

2013-07-25 Thread Howard M. Lewis Ship (JIRA)

 [ 
https://issues.apache.org/jira/browse/TAP5-1446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Howard M. Lewis Ship updated TAP5-1446:
---

Summary: Coercion from List to SelectModel should use the 
SelectModelFactory service  (was: Improve coercion List -> SelectModel)

> Coercion from List to SelectModel should use the SelectModelFactory service
> ---
>
> Key: TAP5-1446
> URL: https://issues.apache.org/jira/browse/TAP5-1446
> Project: Tapestry 5
>  Issue Type: Improvement
>  Components: tapestry-core
>Affects Versions: 5.2
>Reporter: Denis Stepanov
>Assignee: Howard M. Lewis Ship
> Attachments: TAP5-1446.patch
>
>
> It should use SelectModelFactory. Labels are extracted from objects using 
> strategy pattern. Users can contribute providers for their own objects. 

--
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] [Assigned] (TAP5-1481) ComponentPageElementImpl to throw a special exception when a component cannot be found by id

2013-07-25 Thread Howard M. Lewis Ship (JIRA)

 [ 
https://issues.apache.org/jira/browse/TAP5-1481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Howard M. Lewis Ship reassigned TAP5-1481:
--

Assignee: Howard M. Lewis Ship

> ComponentPageElementImpl to throw a special exception when a component cannot 
> be found by id
> 
>
> Key: TAP5-1481
> URL: https://issues.apache.org/jira/browse/TAP5-1481
> Project: Tapestry 5
>  Issue Type: Improvement
>  Components: tapestry-core
>Affects Versions: 5.2
>Reporter: Anton Litvinenko
>Assignee: Howard M. Lewis Ship
>
> when an embedded component cannot be found by id, then 
> ComponentPageElementImpl throws a TapestryException at line 841 for 5.1.0.5 
> (UnknownValueException for 5.2.4).
> I suggest throwing a special kind of exception in such case (e.g. 
> EmbeddedComponentNotFoundException or ComponentNotFoundException), so that 
> application would be able to handle such cases separately (e.g. by serving a 
> 404 error page).
> Particular use-case: google indexing bot cached a tapestry page and tries 
> indexing links that are included on this page. If links are actionlinks, then 
> they include id of the component. When one changes the id of the component 
> (or renames the component), then the "old" link doesn't work anymore as it 
> contains old id of the component -> google indexing bot is served with 
> Tapestry error page (which is a typical page). Instead, it makes sense to 
> send a 404 error as result and let google bot know that there is no such 
> resource anymore. 

--
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-1537) Improve js processing time for pages with huge number of zones

2013-07-25 Thread Howard M. Lewis Ship (JIRA)

 [ 
https://issues.apache.org/jira/browse/TAP5-1537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Howard M. Lewis Ship closed TAP5-1537.
--

Resolution: Invalid

The new approach in 5.4 is much "lighter" (just a single global event handler 
for all zones on the page) and should address your performance concerns.

> Improve js processing time for pages with huge number of zones
> --
>
> Key: TAP5-1537
> URL: https://issues.apache.org/jira/browse/TAP5-1537
> Project: Tapestry 5
>  Issue Type: Improvement
>  Components: tapestry-core
>Affects Versions: 5.2
>Reporter: Pedro Ayala
>  Labels: ajax,, javascript,, performance, zone,
> Attachments: tapestry-zone-improvement.txt
>
>
> When creating a new page with a huge number of zones we are initializing all 
> them in javascript calling Tapestry.ZoneManager.initialize. This is not 
> affecting modern browser, but for some old browser like internet explorer 6 
> or 7, this method can take a long time to be executed.
> In order to prevent this overhead in the javascript load in the user browser, 
> we can lazily create the zoneManager object when it is needed. For doing this 
> we should only create the js zone object when there is some special parameter 
> for creating it. The only time we need to create the zone in load time, is 
> when we have some special setup for creating the zone.
> The zone can be created when calling findZoneManagerForZone. If it fails to 
> find the zone, we can try to create it, and only if it fails we will fire the 
> error message.
> Once the zone has been lazily created, findZoneManagerForZone it will find 
> the zone following the normal behaviour.
> ### Eclipse Workspace Patch 1.0
> #P tapestry-core
> Index: src/main/resources/org/apache/tapestry5/tapestry.js
> ===
> --- src/main/resources/org/apache/tapestry5/tapestry.js   (revision 
> 1129658)
> +++ src/main/resources/org/apache/tapestry5/tapestry.js   (working copy)
> @@ -492,6 +492,9 @@
>   var manager = $T(element).zoneManager;
>  
>   if (!manager) {
> + var mgr = new 
> Tapestry.ZoneManager({"element":zoneElement});
> + if (mgr)
> + return mgr;
>   Tapestry.error(Tapestry.Messages.noZoneManager, 
> element);
>   return null;
>   }
> @@ -1233,7 +1236,8 @@
>   },
>  
>   zone : function(spec) {
> - new Tapestry.ZoneManager(spec);
> + if (spec.show || spec.parameters ||  
> (spec.update && spec.update != 'show') )
> + new Tapestry.ZoneManager(spec);
>   },
>  
>   formFragment : function(spec) {

--
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] [Assigned] (TAP5-1477) Stack assets should return 404 in stead of exception if they don't exist

2013-07-25 Thread Howard M. Lewis Ship (JIRA)

 [ 
https://issues.apache.org/jira/browse/TAP5-1477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Howard M. Lewis Ship reassigned TAP5-1477:
--

Assignee: Howard M. Lewis Ship

> Stack assets should return 404 in stead of exception if they don't exist
> 
>
> Key: TAP5-1477
> URL: https://issues.apache.org/jira/browse/TAP5-1477
> Project: Tapestry 5
>  Issue Type: Improvement
>  Components: tapestry-core
>Affects Versions: 5.2
>Reporter: Joost Schouten
>Assignee: Howard M. Lewis Ship
>
> Currently when trying to access a stack asset I get the following exception:
> java.lang.RuntimeException: Invalid path for a stack asset request.
> This should just be a 404.

--
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-1570) Zone elements in the client should trigger events so that the application can react to changes

2013-07-25 Thread Howard M. Lewis Ship (JIRA)

 [ 
https://issues.apache.org/jira/browse/TAP5-1570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Howard M. Lewis Ship closed TAP5-1570.
--

Resolution: Fixed

> Zone elements in the client should trigger events so that the application can 
> react to changes
> --
>
> Key: TAP5-1570
> URL: https://issues.apache.org/jira/browse/TAP5-1570
> Project: Tapestry 5
>  Issue Type: Improvement
>  Components: tapestry-core
>Affects Versions: 5.1.0.0, 5.1, 5.0.16
>Reporter: Joe Klecko
>Assignee: Howard M. Lewis Ship
> Fix For: 5.4
>
>
> It seems that time and time again for each T5 project (6 out of 7 so far) I 
> find I need to override tapesty.js methods to add additional support for 
> zones.  Currently there is only 1 event fired from a zone 
> (Tapestry.ZONE_UPDATED_EVENT), I'd like to suggest/request there be at least 
> 4 events total (3 new ones):
> 1) ZONE_BEFORE_AJAX_REQUEST_EVENT:  This would be fired before the ajax 
> request is sent to the server.  Listeners should be able to cancel the ajax 
> request (similiar to the way tapestry allows a form submission to be canceled)
> 2) ZONE_BEFORE_UPDATE_EVENT:  This would be fired after the ajax request 
> returns and just before the zone is updated via the processReply() method.  
> Again, listeners should be able to cancel the update.
> 3) ZONE_UPDATED_EVENT:  already and is listed here for completeness.
> 4) ZONE_AJAX_REQUEST_ERROR_EVENT:  This would be fired if the ajax request 
> errored out for the zone. (includes error data) 
> references to mailing list: 
> http://tapestry.1045711.n5.nabble.com/More-javscript-zone-events-please-td4401005.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] [Reopened] (TAP5-1570) More javascript events for zones

2013-07-25 Thread Howard M. Lewis Ship (JIRA)

 [ 
https://issues.apache.org/jira/browse/TAP5-1570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Howard M. Lewis Ship reopened TAP5-1570:



> More javascript events for zones
> 
>
> Key: TAP5-1570
> URL: https://issues.apache.org/jira/browse/TAP5-1570
> Project: Tapestry 5
>  Issue Type: Improvement
>  Components: tapestry-core
>Affects Versions: 5.1.0.0, 5.1, 5.0.16
>Reporter: Joe Klecko
>Assignee: Howard M. Lewis Ship
> Fix For: 5.4
>
>
> It seems that time and time again for each T5 project (6 out of 7 so far) I 
> find I need to override tapesty.js methods to add additional support for 
> zones.  Currently there is only 1 event fired from a zone 
> (Tapestry.ZONE_UPDATED_EVENT), I'd like to suggest/request there be at least 
> 4 events total (3 new ones):
> 1) ZONE_BEFORE_AJAX_REQUEST_EVENT:  This would be fired before the ajax 
> request is sent to the server.  Listeners should be able to cancel the ajax 
> request (similiar to the way tapestry allows a form submission to be canceled)
> 2) ZONE_BEFORE_UPDATE_EVENT:  This would be fired after the ajax request 
> returns and just before the zone is updated via the processReply() method.  
> Again, listeners should be able to cancel the update.
> 3) ZONE_UPDATED_EVENT:  already and is listed here for completeness.
> 4) ZONE_AJAX_REQUEST_ERROR_EVENT:  This would be fired if the ajax request 
> errored out for the zone. (includes error data) 
> references to mailing list: 
> http://tapestry.1045711.n5.nabble.com/More-javscript-zone-events-please-td4401005.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-1570) Zone elements in the client should trigger events so that the application can react to changes

2013-07-25 Thread Howard M. Lewis Ship (JIRA)

 [ 
https://issues.apache.org/jira/browse/TAP5-1570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Howard M. Lewis Ship updated TAP5-1570:
---

Summary: Zone elements in the client should trigger events so that the 
application can react to changes  (was: More javascript events for zones)

> Zone elements in the client should trigger events so that the application can 
> react to changes
> --
>
> Key: TAP5-1570
> URL: https://issues.apache.org/jira/browse/TAP5-1570
> Project: Tapestry 5
>  Issue Type: Improvement
>  Components: tapestry-core
>Affects Versions: 5.1.0.0, 5.1, 5.0.16
>Reporter: Joe Klecko
>Assignee: Howard M. Lewis Ship
> Fix For: 5.4
>
>
> It seems that time and time again for each T5 project (6 out of 7 so far) I 
> find I need to override tapesty.js methods to add additional support for 
> zones.  Currently there is only 1 event fired from a zone 
> (Tapestry.ZONE_UPDATED_EVENT), I'd like to suggest/request there be at least 
> 4 events total (3 new ones):
> 1) ZONE_BEFORE_AJAX_REQUEST_EVENT:  This would be fired before the ajax 
> request is sent to the server.  Listeners should be able to cancel the ajax 
> request (similiar to the way tapestry allows a form submission to be canceled)
> 2) ZONE_BEFORE_UPDATE_EVENT:  This would be fired after the ajax request 
> returns and just before the zone is updated via the processReply() method.  
> Again, listeners should be able to cancel the update.
> 3) ZONE_UPDATED_EVENT:  already and is listed here for completeness.
> 4) ZONE_AJAX_REQUEST_ERROR_EVENT:  This would be fired if the ajax request 
> errored out for the zone. (includes error data) 
> references to mailing list: 
> http://tapestry.1045711.n5.nabble.com/More-javscript-zone-events-please-td4401005.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] [Closed] (TAP5-1570) More javascript events for zones

2013-07-25 Thread Howard M. Lewis Ship (JIRA)

 [ 
https://issues.apache.org/jira/browse/TAP5-1570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Howard M. Lewis Ship closed TAP5-1570.
--

   Resolution: Fixed
Fix Version/s: 5.4
 Assignee: Howard M. Lewis Ship

Tapestry 5.4 now defines a number of events to force a zone to update, or to be 
informed of its progress.

> More javascript events for zones
> 
>
> Key: TAP5-1570
> URL: https://issues.apache.org/jira/browse/TAP5-1570
> Project: Tapestry 5
>  Issue Type: Improvement
>  Components: tapestry-core
>Affects Versions: 5.1.0.0, 5.1, 5.0.16
>Reporter: Joe Klecko
>Assignee: Howard M. Lewis Ship
> Fix For: 5.4
>
>
> It seems that time and time again for each T5 project (6 out of 7 so far) I 
> find I need to override tapesty.js methods to add additional support for 
> zones.  Currently there is only 1 event fired from a zone 
> (Tapestry.ZONE_UPDATED_EVENT), I'd like to suggest/request there be at least 
> 4 events total (3 new ones):
> 1) ZONE_BEFORE_AJAX_REQUEST_EVENT:  This would be fired before the ajax 
> request is sent to the server.  Listeners should be able to cancel the ajax 
> request (similiar to the way tapestry allows a form submission to be canceled)
> 2) ZONE_BEFORE_UPDATE_EVENT:  This would be fired after the ajax request 
> returns and just before the zone is updated via the processReply() method.  
> Again, listeners should be able to cancel the update.
> 3) ZONE_UPDATED_EVENT:  already and is listed here for completeness.
> 4) ZONE_AJAX_REQUEST_ERROR_EVENT:  This would be fired if the ajax request 
> errored out for the zone. (includes error data) 
> references to mailing list: 
> http://tapestry.1045711.n5.nabble.com/More-javscript-zone-events-please-td4401005.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-1767) Making URLRewrite optionally available for smooth upgrading

2013-07-25 Thread Howard M. Lewis Ship (JIRA)

[ 
https://issues.apache.org/jira/browse/TAP5-1767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13720062#comment-13720062
 ] 

Howard M. Lewis Ship commented on TAP5-1767:


It's going to be a challenge to find someone with the bandwidth to address this 
issue. You will probably need to provide a patch, with tests.


> Making URLRewrite optionally available for smooth upgrading
> ---
>
> Key: TAP5-1767
> URL: https://issues.apache.org/jira/browse/TAP5-1767
> Project: Tapestry 5
>  Issue Type: Improvement
>  Components: tapestry-core
>Affects Versions: 5.3
>Reporter: Angelo Chen
>  Labels: URLrewrie
>
> 1. removal of URLRewrite in 5.3 make it difficult to upgrade to 5.3 as we 
> have to test all the rules again.
> 2. lack of outbound link rewriting in LinkTransformer has totally stopped my 
> effort in upgrading to 5.3
> I'd suggest to make the urlrewrite a separate module so we can upgrade to 5.3 
> smoothly. thanks

--
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-1775) Improve javascript performance while creating zone events

2013-07-25 Thread Howard M. Lewis Ship (JIRA)

 [ 
https://issues.apache.org/jira/browse/TAP5-1775?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Howard M. Lewis Ship closed TAP5-1775.
--

   Resolution: Invalid
Fix Version/s: 5.4

This performance issues here have been addressed by the client-side overhaul in 
Tapestry 5.4.

> Improve javascript performance while creating zone events
> -
>
> Key: TAP5-1775
> URL: https://issues.apache.org/jira/browse/TAP5-1775
> Project: Tapestry 5
>  Issue Type: Improvement
>  Components: tapestry-core
>Affects Versions: 5.3
>Reporter: Pedro Ayala
>  Labels: javascript, performance
> Fix For: 5.4
>
> Attachments: changes.patch
>
>
> While creating eventLinks and actionLinks it is necessary to call 
> updateZoneOnEvent to create the observe and store the zoneId in the element 
> for future references.
> The method is also checking if the zoneId exist before storing it in the 
> element store information. While this feature is quite useful in debug mode, 
> it is also consuming some time in production mode.
> With this patch we will prevent the check while running in production mode, 
> this improve performance in older browser like internet explorer 7.
> Index: src/main/resources/org/apache/tapestry5/tapestry.js
> ===
> --- src/main/resources/org/apache/tapestry5/tapestry.js
> +++ src/main/resources/org/apache/tapestry5/tapestry.js
> @@ -1020,21 +1020,32 @@ T5.extendInitializers({
>  updateZoneOnEvent : function(eventName, element, zoneId, url) {
>  element = $(element);
>  
> -$T(element).zoneUpdater = true;
> -
> -var zoneElement = zoneId == '^' ? $(element).up('.t-zone')
> -: $(zoneId);
> -
> -if (!zoneElement) {
> -Tapestry
> -.error(
> -"Could not find zone element '#{zoneId}' to update on 
> #{eventName} of element '#{elementId}'.",
> -{
> -zoneId : zoneId,
> -eventName : eventName,
> -elementId : element.id
> -});
> -return;
> +var Telement = $T(element);
> +Telement.zoneUpdater = true;
> +
> +var destZoneId = zoneId;
> +var zoneElement = null;
> +if (zoneId == '^') {
> + zoneElement = element.up('.t-zone');
> + if (zoneElement)
> + destZoneId = zoneElement.id;
> +}
> + 
> +if (Tapestry.DEBUG_ENABLED) {
> + if (!zoneElement && zoneId != '^')
> + zoneElement = $(zoneId);
> +
> + if (!zoneElement) {
> + Tapestry
> + .error(
> + "Could not find zone element '#{zoneId}' to update on 
> #{eventName} of element '#{elementId}'.",
> + {
> + zoneId : zoneId,
> + eventName : eventName,
> + elementId : element.id
> + });
> + return;
> + }
>  }
>  
>  /*
> @@ -1042,7 +1053,7 @@ T5.extendInitializers({
>   * changed dynamically on the client side.
>   */
>  
> -$T(element).zoneId = zoneElement.id;
> +Telement.zoneId = zoneId;
>  
>  if (element.tagName == "FORM") {
>  

--
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] [Assigned] (TAP5-2149) Support JavaScript aggregation of modules, not just libraries

2013-07-25 Thread Howard M. Lewis Ship (JIRA)

 [ 
https://issues.apache.org/jira/browse/TAP5-2149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Howard M. Lewis Ship reassigned TAP5-2149:
--

Assignee: Howard M. Lewis Ship

> Support JavaScript aggregation of modules, not just libraries
> -
>
> Key: TAP5-2149
> URL: https://issues.apache.org/jira/browse/TAP5-2149
> Project: Tapestry 5
>  Issue Type: Improvement
>  Components: tapestry-core
>Affects Versions: 5.4
>Reporter: Howard M. Lewis Ship
>Assignee: Howard M. Lewis Ship
>Priority: Critical
>  Labels: javascript, requirejs
>
> One of the last major hurdles is to support aggregation of AMD modules; this 
> would imply that the modules become part of a JavaScriptStack.
> There are definitely some challenges to this; primarily the need to rewrite 
> the JavaScript slightly:
> define(["dep1", "dep2", "dep3"], function(dep1, dep2, dep3) { ... });
> needs to be rewitten to:
> define("my/module/name", ["dep1", "dep2", "dep3", function(dep1, dep2, dep3) 
> { ... });
> This can probably be accomplished using a regular expression. 
> RequireJS's r.js utility is powerful; part of its job is to automatically 
> hunt down transitive dependencies from a root namespace.  I don't know if we 
> can effectively duplicate that; because of issues such as CoffeeScript vs. 
> JavaScript (vs. other languages), the fact that certain modules are created 
> at runtime, and other factors ... we may need to the user to supply a list of 
> which modules should be included, and the others will be fetched on-demand.

--
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-2149) Support JavaScript aggregation of modules, not just libraries

2013-07-25 Thread Howard M. Lewis Ship (JIRA)
Howard M. Lewis Ship created TAP5-2149:
--

 Summary: Support JavaScript aggregation of modules, not just 
libraries
 Key: TAP5-2149
 URL: https://issues.apache.org/jira/browse/TAP5-2149
 Project: Tapestry 5
  Issue Type: Improvement
  Components: tapestry-core
Affects Versions: 5.4
Reporter: Howard M. Lewis Ship
Priority: Critical


One of the last major hurdles is to support aggregation of AMD modules; this 
would imply that the modules become part of a JavaScriptStack.

There are definitely some challenges to this; primarily the need to rewrite the 
JavaScript slightly:

define(["dep1", "dep2", "dep3"], function(dep1, dep2, dep3) { ... });

needs to be rewitten to:

define("my/module/name", ["dep1", "dep2", "dep3", function(dep1, dep2, dep3) { 
... });

This can probably be accomplished using a regular expression. 

RequireJS's r.js utility is powerful; part of its job is to automatically hunt 
down transitive dependencies from a root namespace.  I don't know if we can 
effectively duplicate that; because of issues such as CoffeeScript vs. 
JavaScript (vs. other languages), the fact that certain modules are created at 
runtime, and other factors ... we may need to the user to supply a list of 
which modules should be included, and the others will be fetched on-demand.

--
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-1776) Optimize the access to elements in javascript while creating a formEventManager

2013-07-25 Thread Howard M. Lewis Ship (JIRA)

 [ 
https://issues.apache.org/jira/browse/TAP5-1776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Howard M. Lewis Ship closed TAP5-1776.
--

Resolution: Invalid

This no longer makes sense in terms of the client overhaul in Tapestry 5.4.

> Optimize the access to elements in javascript while creating a 
> formEventManager
> ---
>
> Key: TAP5-1776
> URL: https://issues.apache.org/jira/browse/TAP5-1776
> Project: Tapestry 5
>  Issue Type: Improvement
>  Components: tapestry-core
>Affects Versions: 5.3
>Reporter: Pedro Ayala
>  Labels: javascript, optimization, performance
> Attachments: changes.patch
>
>
> When calling the function formEventManager tapestry is storing the new 
> created Tapestry.FormEventManager in the storage space, for doing this we are 
> using $T with the element id. Because the Tapestry.FormEventManager also 
> needs to access the element, we can optimize the access to it.
> This has some performance impact while using old browsers like internet 
> explorer 7 and pages with a big number of forms.
> Index: src/main/resources/org/apache/tapestry5/tapestry.js
> ===
> --- src/main/resources/org/apache/tapestry5/tapestry.js
> +++ src/main/resources/org/apache/tapestry5/tapestry.js
> @@ -1119,7 +1130,8 @@ T5.extendInitializers({
>   * @since 5.2.2
>   */
>  formEventManager : function(spec) {
> -$T(spec.formId).formEventManager = new Tapestry.FormEventManager(
> + spec.form = $(spec.formId);
> +$T(spec.form).formEventManager = new Tapestry.FormEventManager(
>  spec);
>  },
>  
> @@ -1457,7 +1469,7 @@ Tapestry.ErrorPopup = Class.create({
>  Tapestry.FormEventManager = Class.create({
>  
>  initialize : function(spec) {
> -this.form = $(spec.formId);
> +this.form = spec.form;
>  this.validateOnBlur = spec.validate.blur;
>  this.validateOnSubmit = spec.validate.submit;
>  

--
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-1781) Improve javascript load time of pages improving onDomLoadedCallback

2013-07-25 Thread Howard M. Lewis Ship (JIRA)

 [ 
https://issues.apache.org/jira/browse/TAP5-1781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Howard M. Lewis Ship closed TAP5-1781.
--

   Resolution: Fixed
Fix Version/s: 5.4
 Assignee: Howard M. Lewis Ship

This was one of the driving forces between the client overhaul in 5.4.

Your concerns have been applied, but your patch is now meaningless.

The JavaScript provided for most pages is now much "lighter", consisting of 
document-level event handlers, rather than individual event handlers on 
specific elements. There's much less to setup during page initialization. In 
addition, RequireJS allows for the JavaScript to be loaded in parallel.

We've also gotten rid of some expensive operations such as on-blur field input 
validation.

> Improve javascript load time of pages improving onDomLoadedCallback
> ---
>
> Key: TAP5-1781
> URL: https://issues.apache.org/jira/browse/TAP5-1781
> Project: Tapestry 5
>  Issue Type: Improvement
>  Components: tapestry-core
>Affects Versions: 5.3
>Reporter: Pedro Ayala
>Assignee: Howard M. Lewis Ship
>  Labels: javascript, performance
> Fix For: 5.4
>
> Attachments: changes.patch
>
>
> One of tapestry main slow loading of big pages with many forms and components 
> is the need of initializing the observers for popup up messages and for the 
> click on submit elements.
> Right now tapestry is using two $$, one for each process, and then creating 
> an observe for each element. This way, although working fine, is terrible 
> slow in ie7 with big pages.
> One way to improve this issue is using less observes and removing the $$. 
> This patch observe the document element for click and keyup events, and then 
> checks if the element is one of the one we want fire some event.
> Index: src/main/resources/org/apache/tapestry5/tapestry.js
> ===
> --- src/main/resources/org/apache/tapestry5/tapestry.js
> +++ src/main/resources/org/apache/tapestry5/tapestry.js
> @@ -99,6 +99,12 @@ var Tapestry = {
>  
>  /** Initially, false, set to true once the page is fully loaded. */
>  pageLoaded : false,
> +
> +/** Initially, false, set to true once we start observing the document 
> for clicks. */
> +trackingClicks : false,
> +
> +/** Initially, false, set to true once we start observing events for 
> displaying errors. */
> +trackFocusError : false,
>  
>  /**
>   * Invoked from onclick event handlers built into links and forms. 
> Raises a
> @@ -196,25 +202,11 @@ var Tapestry = {
>   * Adds a focus observer that fades all error popups except for the
>   * field in question.
>   */
> -$$("INPUT", "SELECT", "TEXTAREA").each(function(element) {
> -/*
> - * Due to Ajax, we may execute the callback multiple times, and 
> we
> - * don't want to add multiple listeners to the same element.
> - */
> -var t = $T(element);
> -
> -if (!t.observingFocusChange) {
> -element.observe("focus", function() {
> -if (element != Tapestry.currentFocusField) {
> -document.fire(Tapestry.FOCUS_CHANGE_EVENT, element);
> -
> -Tapestry.currentFocusField = element;
> -}
> -});
> -
> -t.observingFocusChange = true;
> -}
> -});
> +if (!Tapestry.trackFocusError) {
> +document.observe("keyup", Tapestry.errorPoup.bind(this));
> +document.observe("click", Tapestry.errorPoup.bind(this));
> +Tapestry.trackFocusError = true;
> +}
>  
>  /*
>   * When a submit element is clicked, record the name of the element 
> into
> @@ -224,17 +216,26 @@ var Tapestry = {
>   * TAP5-1418: Added "type=image" so that they set the submitting 
> element
>   * correctly.
>   */
> -$$("INPUT[type=submit]", "INPUT[type=image]").each(function(element) 
> {
> -var t = $T(element);
> -
> -if (!t.trackingClicks) {
> -element.observe("click", function() {
> -$(element.form).setSubmittingElement(element);
> -});
> -
> -t.trackingClicks = true;
> -}
> -});
> +if (!Tapestry.trackingClicks) {
> + Event.observe(document, "click", function(event) {
> + var element = event.findElement();
> + if (element.tagName == "INPUT" && 
> (element.type=="submit" || element.type=="image"))
> + $(element.form).setSubmittingElement(element);
> +

[jira] [Closed] (TAP5-1816) Add CSS rule for DIV.t-exception-container to default.css that sets a very high z-index

2013-07-25 Thread Howard M. Lewis Ship (JIRA)

 [ 
https://issues.apache.org/jira/browse/TAP5-1816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Howard M. Lewis Ship closed TAP5-1816.
--

   Resolution: Fixed
Fix Version/s: 5.4
 Assignee: Howard M. Lewis Ship

Fixed as part of the general client-side overhaul in 5.4. The new z-order of 
1100 is chosen to be "in front of" .modal-backdrop and .modal (1040 and 1050, 
by default).

> Add CSS rule for DIV.t-exception-container to default.css that sets a very 
> high z-index
> ---
>
> Key: TAP5-1816
> URL: https://issues.apache.org/jira/browse/TAP5-1816
> Project: Tapestry 5
>  Issue Type: Improvement
>  Components: tapestry-core
>Affects Versions: 5.3, 5.4
>Reporter: Howard M. Lewis Ship
>Assignee: Howard M. Lewis Ship
> Fix For: 5.4
>
>
> Currently uses the default z-index which means that anything with a higher 
> z-index appears above it.

--
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-1834) Warn user or disallow zone with randomly generated id

2013-07-25 Thread Howard M. Lewis Ship (JIRA)

[ 
https://issues.apache.org/jira/browse/TAP5-1834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13720037#comment-13720037
 ] 

Howard M. Lewis Ship commented on TAP5-1834:


This is becoming increasingly irrelevant in 5.4, unless you have a component 
*outside* a Zone try to update the Zone; then it needs its id (or some other 
mechanism for locating the Zone's client-side element).

> Warn user or disallow zone with randomly generated id
> -
>
> Key: TAP5-1834
> URL: https://issues.apache.org/jira/browse/TAP5-1834
> Project: Tapestry 5
>  Issue Type: Improvement
>  Components: tapestry-core
>Affects Versions: 5.3, 5.2.5
>Reporter: Denis Stepanov
>
> Zone with an id generated randomly(ajax request) is useless and confusing 
> developers, is such case there should be a warning or even an exception.
> TAP5-1746
> http://www.mail-archive.com/users@tapestry.apache.org/msg57958.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] [Assigned] (TAP5-1820) Default Exception Report Page should have a link to discard component class loader and retry

2013-07-25 Thread Howard M. Lewis Ship (JIRA)

 [ 
https://issues.apache.org/jira/browse/TAP5-1820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Howard M. Lewis Ship reassigned TAP5-1820:
--

Assignee: Howard M. Lewis Ship

> Default Exception Report Page should have a link to discard component class 
> loader and retry
> 
>
> Key: TAP5-1820
> URL: https://issues.apache.org/jira/browse/TAP5-1820
> Project: Tapestry 5
>  Issue Type: Improvement
>  Components: tapestry-core
>Affects Versions: 5.3, 5.4
>Reporter: Howard M. Lewis Ship
>Assignee: Howard M. Lewis Ship
>  Labels: exception-reporting
>
> Sometimes you attempt to reach a page, but it doesn't exist because of a 
> syntax error.
> Even after you create the page and reload, Tapestry may not pick up the 
> change because it is not monitoring the directory containing the .class file, 
> because it didn't successfully load a file from that directory.
> It would be nice if the exception report page included a link to discard the 
> class loader, forcing a reload of the page(s) for the request, and would then 
> redirect back to the page (or event request) that failed.
> Caveats:
> - Different handling for an Ajax request, where the class loader should be 
> discarded, and a response returned that will dismiss the exception report 
> iframe.
> - POST requests may be tricky.
> - The link should only appear if the request is white-listed (by default, 
> from localhost).

--
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-1849) The text "Dismiss All" used in client-side Alerts is not localized or localizable

2013-07-25 Thread Howard M. Lewis Ship (JIRA)

 [ 
https://issues.apache.org/jira/browse/TAP5-1849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Howard M. Lewis Ship updated TAP5-1849:
---

Summary: The text "Dismiss All" used in client-side Alerts is not localized 
or localizable  (was: It is necessary to localize title in the Alerts component)

> The text "Dismiss All" used in client-side Alerts is not localized or 
> localizable
> -
>
> Key: TAP5-1849
> URL: https://issues.apache.org/jira/browse/TAP5-1849
> Project: Tapestry 5
>  Issue Type: Improvement
>  Components: tapestry-core
>Affects Versions: 5.3.2
>Reporter: Vladimir Velikiy
>  Labels: javascript
>
> t5-alerts.js contains nonlocalized string "Dismiss" in alert div title:
> 62 var alertDiv = new Element("div", { "class": alertSpec['class'] 
> }).update("" +
> 63"" + alertSpec.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] [Closed] (TAP5-1849) The text "Dismiss All" used in client-side Alerts is not localized or localizable

2013-07-25 Thread Howard M. Lewis Ship (JIRA)

 [ 
https://issues.apache.org/jira/browse/TAP5-1849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Howard M. Lewis Ship closed TAP5-1849.
--

   Resolution: Fixed
Fix Version/s: 5.4
 Assignee: Howard M. Lewis Ship

This was addressed with the general client-side overhaul in Tapestry 5.4.

> The text "Dismiss All" used in client-side Alerts is not localized or 
> localizable
> -
>
> Key: TAP5-1849
> URL: https://issues.apache.org/jira/browse/TAP5-1849
> Project: Tapestry 5
>  Issue Type: Improvement
>  Components: tapestry-core
>Affects Versions: 5.3.2
>Reporter: Vladimir Velikiy
>Assignee: Howard M. Lewis Ship
>  Labels: javascript
> Fix For: 5.4
>
>
> t5-alerts.js contains nonlocalized string "Dismiss" in alert div title:
> 62 var alertDiv = new Element("div", { "class": alertSpec['class'] 
> }).update("" +
> 63"" + alertSpec.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] [Assigned] (TAP5-1861) Wrap javascript call rendering apis for interoperability and convenience

2013-07-25 Thread Howard M. Lewis Ship (JIRA)

 [ 
https://issues.apache.org/jira/browse/TAP5-1861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Howard M. Lewis Ship reassigned TAP5-1861:
--

Assignee: Howard M. Lewis Ship

> Wrap javascript call rendering apis for interoperability and convenience
> 
>
> Key: TAP5-1861
> URL: https://issues.apache.org/jira/browse/TAP5-1861
> Project: Tapestry 5
>  Issue Type: Improvement
>  Components: tapestry-core
>Affects Versions: 5.3.2
>Reporter: Paul Stanton
>Assignee: Howard M. Lewis Ship
>  Labels: ajax, javascript
>
> Vast improvements to the ajax and javascript rendering API's have made things 
> much easier to use in tapestry 5.2+, however I still think there is room for 
> improvement. I find I can't work without this 'helper' service I designed to 
> standardise script call rendering between xhr and non-xhr requests. The main 
> motivation/benefit is that a set of functionality can now be called in either 
> (xhr/non-xhr) context and still work. It also has the benefit of building the 
> necessary JavaScriptCallback in the xhr context. In my opinion, this makes 
> user code much tidier:
> public class JavascriptHelperImpl implements JavascriptHelper
> {
> @Inject
> private AjaxResponseRenderer ajaxResponseRenderer;
> @Inject
> private Request request;
> @Inject
> private JavaScriptSupport jsSupport;
> @Override
> public void addScript(final String format, final Object... args)
> {
> if (!request.isXHR())
> {
> jsSupport.addScript(format, args);
> return;
> }
> ajaxResponseRenderer.addCallback(new JavaScriptCallback()
> {
> @Override
> public void run(JavaScriptSupport javascriptSupport)
> {
> javascriptSupport.addScript(format, args);
> }
> });
> }
> }
> There may or may not be additional opportunity with the other methods such as 
> 'addInitializerCall' but I haven't needed to.
> This code is free for anyone (including apache/tapestry) to use.

--
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-1861) Wrap javascript call rendering apis for interoperability and convenience

2013-07-25 Thread Howard M. Lewis Ship (JIRA)

[ 
https://issues.apache.org/jira/browse/TAP5-1861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13720031#comment-13720031
 ] 

Howard M. Lewis Ship commented on TAP5-1861:


No, we still have this issue.

I can definitely see the need for a facade to handle this situation. Probably, 
the JavaScriptSupport interface could be used; most methods would throw an 
IllegalStateException, a few, such as require(), would capture results and add 
them to AjaxResponseRenderer.

> Wrap javascript call rendering apis for interoperability and convenience
> 
>
> Key: TAP5-1861
> URL: https://issues.apache.org/jira/browse/TAP5-1861
> Project: Tapestry 5
>  Issue Type: Improvement
>  Components: tapestry-core
>Affects Versions: 5.3.2
>Reporter: Paul Stanton
>  Labels: ajax, javascript
>
> Vast improvements to the ajax and javascript rendering API's have made things 
> much easier to use in tapestry 5.2+, however I still think there is room for 
> improvement. I find I can't work without this 'helper' service I designed to 
> standardise script call rendering between xhr and non-xhr requests. The main 
> motivation/benefit is that a set of functionality can now be called in either 
> (xhr/non-xhr) context and still work. It also has the benefit of building the 
> necessary JavaScriptCallback in the xhr context. In my opinion, this makes 
> user code much tidier:
> public class JavascriptHelperImpl implements JavascriptHelper
> {
> @Inject
> private AjaxResponseRenderer ajaxResponseRenderer;
> @Inject
> private Request request;
> @Inject
> private JavaScriptSupport jsSupport;
> @Override
> public void addScript(final String format, final Object... args)
> {
> if (!request.isXHR())
> {
> jsSupport.addScript(format, args);
> return;
> }
> ajaxResponseRenderer.addCallback(new JavaScriptCallback()
> {
> @Override
> public void run(JavaScriptSupport javascriptSupport)
> {
> javascriptSupport.addScript(format, args);
> }
> });
> }
> }
> There may or may not be additional opportunity with the other methods such as 
> 'addInitializerCall' but I haven't needed to.
> This code is free for anyone (including apache/tapestry) to use.

--
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-1863) Rendering components in Alerts

2013-07-25 Thread Howard M. Lewis Ship (JIRA)

[ 
https://issues.apache.org/jira/browse/TAP5-1863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13720026#comment-13720026
 ] 

Howard M. Lewis Ship commented on TAP5-1863:


I think it would be nice if we could pass along to the client that the Alert 
content was pre-formatted (the equivalent of MarkupWriter.writeRaw()). That 
would support the kind of scenarios you describe.

It would be even more effective if the client-side api, the t5/core/alert 
module, added some flexibility here.

> Rendering components in Alerts
> --
>
> Key: TAP5-1863
> URL: https://issues.apache.org/jira/browse/TAP5-1863
> Project: Tapestry 5
>  Issue Type: Improvement
>  Components: tapestry-core
>Affects Versions: 5.3.2
>Reporter: Magnus Kvalheim
>
> We've just upgraded to 5.3.2 and checked out some of the new components.
> The Alerts seems pretty useful, but looks like it's only possible to pass on 
> strings.
> I'm thinking a pretty common use-case would be to render some 
> components/markup in it - like links.
> I experimented a little by manually rendering a block and pass that on to 
> alertManager. Got some inspiration from this thread about rendering blocks - 
> http://tapestry.1045711.n5.nabble.com/Howto-render-a-block-and-put-it-into-a-JSON-reply-td5486823.html
> 
> RenderCommand renderCommand = (RenderCommand)alertBlock;
> MarkupWriter markupWriter = new MarkupWriterImpl();
> RenderQueueImpl renderQueue = new RenderQueueImpl(log);
> renderQueue.push(renderCommand);
> renderQueue.run(markupWriter);
> alertManager.info(markupWriter.toString());
> 
> That seems to work, but it's a bit clumsy and don't know if it's the 
> recommended approach for rendering blocks. Does a convenience method exist 
> for rendering blocks/components?
> Not sure if it's possible, but how about if one could pass blocks to alerts 
> directly. That could be pretty flexible as well...
> ##REPLY FROM KALLE##
> Certainly the recommended approach is to use the provided render
> queue, rather than create your own - but obviously the current
> implementation doesn't always allow to do so. Completely agree with
> you that rendering links, and, in general, rendering blocks would be
> very useful for alerts. I don't see any major issue why it couldn't be
> supported. Please open an issue for it.

--
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-1898) Asset should be able to create a client url with an absolute path and secure

2013-07-25 Thread Howard M. Lewis Ship (JIRA)

 [ 
https://issues.apache.org/jira/browse/TAP5-1898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Howard M. Lewis Ship closed TAP5-1898.
--

Resolution: Won't Fix

Please provide concrete, real-world examples of why this would be necessary.

> Asset should be able to create a client url with an absolute path and secure
> 
>
> Key: TAP5-1898
> URL: https://issues.apache.org/jira/browse/TAP5-1898
> Project: Tapestry 5
>  Issue Type: Improvement
>Affects Versions: 5.3
>Reporter: Denis Stepanov
>
> It would be nice to introduce new method "toLink", Link supports all kind of 
> URL combinations

--
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-1966) Plastic should throw an exception when it attempts to redefine an existing method unexpectedly

2013-07-25 Thread Howard M. Lewis Ship (JIRA)

 [ 
https://issues.apache.org/jira/browse/TAP5-1966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Howard M. Lewis Ship updated TAP5-1966:
---

Summary: Plastic should throw an exception when it attempts to redefine an 
existing method unexpectedly  (was: It would be good, if Plastic throws an 
exception, when it is redefining getter which already exists)

> Plastic should throw an exception when it attempts to redefine an existing 
> method unexpectedly
> --
>
> Key: TAP5-1966
> URL: https://issues.apache.org/jira/browse/TAP5-1966
> Project: Tapestry 5
>  Issue Type: Improvement
>  Components: tapestry-core, tapestry-ioc
>Affects Versions: 5.3.3
>Reporter: Andrei Arapov
>  Labels: @Property, Plastic,, Select, Tapestry,
>
> For example, we have page class; page shows "select" component on 
> corresponsing page :
> public class FooPage {
> ...
> // now let's define Property "organizations"
> @Property
> private List organizations;
> // we create method for getting SelectModel class for "select" component
> public SelectModel getOrganizations() {
>  ... blablabla
> }
> ...
> }
> And on page:
> ...
>  value="user.organization" encoder="getValueEncoder()"/>
> ...
> Ok. What's happen now? The behaivour of this situation is not defined. 
> Tapestry can invoke "SelectModel  getOrganizations()" or "List 
> getOrganizations()" in arbitrary order (it is clear why).
> It would be good, if Plastic throws an exception, when it redefines getter 
> which already exists.

--
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] [Assigned] (TAP5-1947) BigDecimal Validator

2013-07-25 Thread Howard M. Lewis Ship (JIRA)

 [ 
https://issues.apache.org/jira/browse/TAP5-1947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Howard M. Lewis Ship reassigned TAP5-1947:
--

Assignee: Howard M. Lewis Ship

> BigDecimal Validator
> 
>
> Key: TAP5-1947
> URL: https://issues.apache.org/jira/browse/TAP5-1947
> Project: Tapestry 5
>  Issue Type: Improvement
>  Components: tapestry-core
>Affects Versions: 5.3.3
>Reporter: George Christman
>Assignee: Howard M. Lewis Ship
>  Labels: features
>
> Tapestry should offer the ability to validate BigDecimal max length's for 
> currency/amounts. I'm donating the following code which validates maxScale 
> and maxPrecision. Unfortunately, I haven't written anything to handle the 
> clientside validation. 
> //app.properties
> maximum-precision=You may provide at most %d numbers for %s.
> maximum-scale=You may provide at most %d decimal digits for %s.
> //MaxScale
> public class MaxScale extends AbstractValidator {
> public MaxScale() {
> super(Integer.class, BigDecimal.class, "maximum-scale");
> }
> @Override
> public void validate(Field field, Integer constraintValue, 
> MessageFormatter formatter, BigDecimal value)
> throws ValidationException
> {
> if (value.scale() > constraintValue)
> throw new ValidationException(buildMessage(formatter, field, 
> constraintValue));
> }
> private String buildMessage(MessageFormatter formatter, Field field, 
> Integer constraintValue) {
> return formatter.format(constraintValue, field.getLabel());
> }
>
> @Override
> public void render(Field field, Integer constraintValue, MessageFormatter 
> formatter, MarkupWriter writer,
> FormSupport formSupport) {
> formSupport.addValidation(field, "maxscale", buildMessage(formatter, 
> field, constraintValue), constraintValue);
> }
> }
> //MaxPrecision
> public class MaxPrecision extends AbstractValidator {
> public MaxPrecision() {
> super(Integer.class, BigDecimal.class, "maximum-precision");
> }
> @Override
> public void validate(Field field, Integer constraintValue, 
> MessageFormatter formatter, BigDecimal value)
> throws ValidationException
> {
> if (value.precision() > constraintValue)
> throw new ValidationException(buildMessage(formatter, field, 
> constraintValue));
> }
> private String buildMessage(MessageFormatter formatter, Field field, 
> Integer constraintValue) {
> return formatter.format(constraintValue, field.getLabel());
> }
>
> @Override
> public void render(Field field, Integer constraintValue, MessageFormatter 
> formatter, MarkupWriter writer,
> FormSupport formSupport) {
> formSupport.addValidation(field, "maxprecision", 
> buildMessage(formatter, field, constraintValue), constraintValue);
> }
> }
> //AppModule
> @SuppressWarnings("rawtypes")
> public static void 
> contributeFieldValidatorSource(MappedConfiguration 
> configuration) {
> configuration.add("maxScale", new MaxScale());
> configuration.add("maxPrecision", new MaxPrecision());
> } 

--
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-1990) Link interface should be more fluid to allow setting of anchor, etc., more concisely

2013-07-25 Thread Howard M. Lewis Ship (JIRA)

 [ 
https://issues.apache.org/jira/browse/TAP5-1990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Howard M. Lewis Ship closed TAP5-1990.
--

   Resolution: Fixed
Fix Version/s: 5.4
 Assignee: Howard M. Lewis Ship

> Link interface should be more fluid to allow setting of anchor, etc., more 
> concisely
> 
>
> Key: TAP5-1990
> URL: https://issues.apache.org/jira/browse/TAP5-1990
> Project: Tapestry 5
>  Issue Type: Improvement
>Reporter: Angelo Chen
>Assignee: Howard M. Lewis Ship
> Fix For: 5.4
>
>
> first, the use case:
> You might be in a situation adding Backbonejs router to your existing 
> Tapestry5 app, you got one like this:
> Object onActivate(String code, String entry);   // 
> localhost:8080/mypage/0001/e001
> and you would like to redirect this to your backbonejs version which is: 
> localhost:8080/mypage/0001#e001
> you can do it now by:
> Object onActivate(String code, String entry) {
>   Link lnk = 
> renderLinkSource.createPageRenderLinkWithContext(Mypage.class, code);
>   lnk.setAnchor(entry);
>   return lnk
> }
> if setAnchor returns Link instead of void, then it can be simplified to:
> Object onActivate(String code, String entry) {
>   return renderLinkSource.createPageRenderLinkWithContext(Mypage.class, 
> code).setAnchor(entry);
> }

--
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-1974) Better API for retrieving application messages by locale

2013-07-25 Thread Howard M. Lewis Ship (JIRA)

 [ 
https://issues.apache.org/jira/browse/TAP5-1974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Howard M. Lewis Ship closed TAP5-1974.
--

Resolution: Won't Fix

It's a good suggestion, but it simply isn't necessary.

> Better API for retrieving application messages by locale
> 
>
> Key: TAP5-1974
> URL: https://issues.apache.org/jira/browse/TAP5-1974
> Project: Tapestry 5
>  Issue Type: Improvement
>  Components: tapestry-core
>Affects Versions: 5.3
>Reporter: Denis Stepanov
>
> ComponentMessagesSource has method getApplicationCatalog(Locale locale), but 
> it would be better to have separate service for that without "component" in 
> its name.

--
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


git commit: TAP5-1990: Link interface should be more fluid to allow setting of anchor, etc., more concisely

2013-07-25 Thread hlship
Updated Branches:
  refs/heads/master 8f52e1229 -> 91cad


TAP5-1990: Link interface should be more fluid to allow setting of anchor, 
etc., more concisely


Project: http://git-wip-us.apache.org/repos/asf/tapestry-5/repo
Commit: http://git-wip-us.apache.org/repos/asf/tapestry-5/commit/91ca
Tree: http://git-wip-us.apache.org/repos/asf/tapestry-5/tree/91ca
Diff: http://git-wip-us.apache.org/repos/asf/tapestry-5/diff/91ca

Branch: refs/heads/master
Commit: 91cad5f6849febb2b24a41a49fc673872724
Parents: 8f52e12
Author: Howard M. Lewis Ship 
Authored: Thu Jul 25 13:36:49 2013 -0700
Committer: Howard M. Lewis Ship 
Committed: Thu Jul 25 13:36:49 2013 -0700

--
 .../main/java/org/apache/tapestry5/Link.java| 29 ++--
 .../tapestry5/internal/services/LinkImpl.java   | 17 ++--
 2 files changed, 34 insertions(+), 12 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/tapestry-5/blob/91ca/tapestry-core/src/main/java/org/apache/tapestry5/Link.java
--
diff --git a/tapestry-core/src/main/java/org/apache/tapestry5/Link.java 
b/tapestry-core/src/main/java/org/apache/tapestry5/Link.java
index f61475c..212cb90 100644
--- a/tapestry-core/src/main/java/org/apache/tapestry5/Link.java
+++ b/tapestry-core/src/main/java/org/apache/tapestry5/Link.java
@@ -44,10 +44,10 @@ public interface Link
 /**
  * Returns the value of a specifically named query parameter, or 
null if no such query parameter is stored
  * in the link.
- *
+ * 
  * Use this method only when you are sure the parameter has only one 
value. If the parameter might have more than
  * one value, use {@link #getParameterValues}.
- *
+ * 
  * If you use this method with a multivalued parameter, the value 
returned is equal to the first value in the
  * array returned by getParameterValues.
  *
@@ -59,10 +59,14 @@ public interface Link
  * Adds a parameter value. The value will be added, as is, to the URL. In 
many cases, the value should be URL
  * encoded via {@link URLCodec}.
  *
- * @param parameterName the name of the parameter to store
- * @param value the value to store, a null or blank value is 
allowed (as of Tapestry 5.3)
+ * @param parameterName
+ * the name of the parameter to store
+ * @param value
+ * the value to store, a null or blank value is allowed (as of 
Tapestry 5.3)
+ * @return this Link, to support method chaining
  */
-void addParameter(String parameterName, String value);
+@IncompatibleChange(release = "5.4", details = "changed from void to Link")
+Link addParameter(String parameterName, String value);
 
 /**
  * Adds a parameter value as a value object; the value object is converted 
to a string via
@@ -77,9 +81,11 @@ public interface Link
  * Removes a parameter value, which is occasionally useful when 
transforming a parameter into a portion of
  * the path.
  *
+ * @return this Link, to support method chaining
  * @since 5.2.0
  */
-void removeParameter(String parameterName);
+@IncompatibleChange(release = "5.4", details = "changed from void to Link")
+Link removeParameter(String parameterName);
 
 /**
  * Returns the completely unadorned base path. Other methods (such as 
{@link #toURI()}), may append
@@ -93,6 +99,7 @@ public interface Link
  * Creates a copy of this link that has the same parameters, anchor, and 
other attributes, but a different
  * {@linkplain #getBasePath() base path}.
  *
+ * @return a new Link instance
  * @since 5.2.0
  */
 Link copyWithBasePath(String basePath);
@@ -120,9 +127,12 @@ public interface Link
 /**
  * Sets the link anchor. Null and empty anchors will be ignored when 
building the link URI.
  *
- * @param anchor the link anchor
+ * @param anchor
+ * the link anchor
+ * @return this Link, to support method chaining
  */
-void setAnchor(String anchor);
+@IncompatibleChange(release = "5.4", details = "changed from void to Link")
+Link setAnchor(String anchor);
 
 /**
  * Returns the absolute URL, which includes the scheme, hostname and 
possibly port (as per
@@ -149,7 +159,8 @@ public interface Link
  * Changes the link's security, which can be useful to force a link to be 
either secure or insecure
  * when normally it might not be.
  *
- * @param newSecurity new security value, not null, typically {@link 
LinkSecurity#FORCE_SECURE} or {@link LinkSecurity#FORCE_INSECURE}
+ * @param newSecurity
+ * new security value, not null, typically {@link 
LinkSecurity#FORCE_SECURE} or {@link LinkSecurity#FORCE_INSECURE}
  * @since 5.3
  */
 @IncompatibleChan

[jira] [Commented] (TAP5-1990) Link interface should be more fluid to allow setting of anchor, etc., more concisely

2013-07-25 Thread Howard M. Lewis Ship (JIRA)

[ 
https://issues.apache.org/jira/browse/TAP5-1990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13720012#comment-13720012
 ] 

Howard M. Lewis Ship commented on TAP5-1990:


(doto (.createPageRenderLinkWithContext Mypage code) (.setAnchor entry))

... oh, sorry, that's Clojure.

This would be an improvement though changing an existing public interface 
arbitrarily is always suspect.

> Link interface should be more fluid to allow setting of anchor, etc., more 
> concisely
> 
>
> Key: TAP5-1990
> URL: https://issues.apache.org/jira/browse/TAP5-1990
> Project: Tapestry 5
>  Issue Type: Improvement
>Reporter: Angelo Chen
>
> first, the use case:
> You might be in a situation adding Backbonejs router to your existing 
> Tapestry5 app, you got one like this:
> Object onActivate(String code, String entry);   // 
> localhost:8080/mypage/0001/e001
> and you would like to redirect this to your backbonejs version which is: 
> localhost:8080/mypage/0001#e001
> you can do it now by:
> Object onActivate(String code, String entry) {
>   Link lnk = 
> renderLinkSource.createPageRenderLinkWithContext(Mypage.class, code);
>   lnk.setAnchor(entry);
>   return lnk
> }
> if setAnchor returns Link instead of void, then it can be simplified to:
> Object onActivate(String code, String entry) {
>   return renderLinkSource.createPageRenderLinkWithContext(Mypage.class, 
> code).setAnchor(entry);
> }

--
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-1990) Link interface should be more fluid to allow setting of anchor, etc., more concisely

2013-07-25 Thread Howard M. Lewis Ship (JIRA)

 [ 
https://issues.apache.org/jira/browse/TAP5-1990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Howard M. Lewis Ship updated TAP5-1990:
---

Summary: Link interface should be more fluid to allow setting of anchor, 
etc., more concisely  (was: 
PageRenderLinkSource.createPageRenderLinkWithContext.setAnchor returns Link)

> Link interface should be more fluid to allow setting of anchor, etc., more 
> concisely
> 
>
> Key: TAP5-1990
> URL: https://issues.apache.org/jira/browse/TAP5-1990
> Project: Tapestry 5
>  Issue Type: Improvement
>Reporter: Angelo Chen
>
> first, the use case:
> You might be in a situation adding Backbonejs router to your existing 
> Tapestry5 app, you got one like this:
> Object onActivate(String code, String entry);   // 
> localhost:8080/mypage/0001/e001
> and you would like to redirect this to your backbonejs version which is: 
> localhost:8080/mypage/0001#e001
> you can do it now by:
> Object onActivate(String code, String entry) {
>   Link lnk = 
> renderLinkSource.createPageRenderLinkWithContext(Mypage.class, code);
>   lnk.setAnchor(entry);
>   return lnk
> }
> if setAnchor returns Link instead of void, then it can be simplified to:
> Object onActivate(String code, String entry) {
>   return renderLinkSource.createPageRenderLinkWithContext(Mypage.class, 
> code).setAnchor(entry);
> }

--
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] [Assigned] (TAP5-2139) When an exception occurs during minification, the asset should be sent unminimized

2013-07-25 Thread Howard M. Lewis Ship (JIRA)

 [ 
https://issues.apache.org/jira/browse/TAP5-2139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Howard M. Lewis Ship reassigned TAP5-2139:
--

Assignee: Howard M. Lewis Ship

> When an exception occurs during minification, the asset should be sent 
> unminimized
> --
>
> Key: TAP5-2139
> URL: https://issues.apache.org/jira/browse/TAP5-2139
> Project: Tapestry 5
>  Issue Type: Improvement
>  Components: tapestry-wro4j
>Affects Versions: 5.4
>Reporter: Jochen Kemnade
>Assignee: Howard M. Lewis Ship
>
> The current closure compiler version fails to minimize angular.js 
> (https://github.com/angular/angular.js/issues/1304). A WroRuntimeException is 
> thrown from GoogleClosureCompressorProcessor which is not handled, so the 
> asset is not sent to the client at all.
> When an asset cannot be minimized for whatever reason, Tapestry should just 
> send the original asset.

--
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-1743) [Tap5.2] Error in Tapestry.FieldEventManager : the getIcon method doesn't set the value of this.icon.

2013-07-25 Thread Howard M. Lewis Ship (JIRA)

 [ 
https://issues.apache.org/jira/browse/TAP5-1743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Howard M. Lewis Ship closed TAP5-1743.
--

Resolution: Won't Fix

All the code described here is no longer present in Tapestry 5.4.

> [Tap5.2] Error in Tapestry.FieldEventManager : the getIcon method doesn't set 
> the value of this.icon.
> -
>
> Key: TAP5-1743
> URL: https://issues.apache.org/jira/browse/TAP5-1743
> Project: Tapestry 5
>  Issue Type: Bug
>  Components: tapestry-core
>Affects Versions: 5.2.6
>Reporter: Clément Uster
>Assignee: François Facon
>Priority: Trivial
>  Labels: javascript
> Attachments: patch-tapestry.js
>
>
> Within the javascript Tapestry.FieldEventManager class, the getIcon method 
> should set the value of this.icon instead of this.com.
> https://github.com/apache/tapestry5/blob/maint-5-2/tapestry-core/src/main/resources/org/apache/tapestry5/tapestry.js#L1694
> The problem has been fixed in tapestry 5.3, but not in tapestry 5.2.

--
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-1926) PropertyDisplayBlocks Date's display block is not thread safe

2013-07-25 Thread Howard M. Lewis Ship (JIRA)

 [ 
https://issues.apache.org/jira/browse/TAP5-1926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Howard M. Lewis Ship closed TAP5-1926.
--

   Resolution: Fixed
Fix Version/s: 5.4
 Assignee: Howard M. Lewis Ship

> PropertyDisplayBlocks Date's display block is not thread safe 
> --
>
> Key: TAP5-1926
> URL: https://issues.apache.org/jira/browse/TAP5-1926
> Project: Tapestry 5
>  Issue Type: Bug
>  Components: tapestry-core
>Affects Versions: 5.3.1, 5.3.2, 5.3.3, 5.3.4, 5.3
>Reporter: Luca Menegus
>Assignee: Howard M. Lewis Ship
>Priority: Trivial
> Fix For: 5.4
>
>
> In class org.apache.tapestry5.corelib.pages.PropertyDisplayBlocks the 
> DateFormat used to format Dates is declared as:
> private final DateFormat dateFormat = 
> DateFormat.getDateInstance(DateFormat.MEDIUM, locale);
> Which is not correct because DateFormat is not thread safe and pages aren't 
> pooled any more.

--
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


git commit: TAP5-1926: PropertyDisplayBlocks Date's display block is not thread safe

2013-07-25 Thread hlship
Updated Branches:
  refs/heads/master 12cb5670a -> 8f52e1229


TAP5-1926: PropertyDisplayBlocks Date's display block is not thread safe


Project: http://git-wip-us.apache.org/repos/asf/tapestry-5/repo
Commit: http://git-wip-us.apache.org/repos/asf/tapestry-5/commit/8f52e122
Tree: http://git-wip-us.apache.org/repos/asf/tapestry-5/tree/8f52e122
Diff: http://git-wip-us.apache.org/repos/asf/tapestry-5/diff/8f52e122

Branch: refs/heads/master
Commit: 8f52e12293896d7446655c5bd80fc5da11a306da
Parents: 12cb567
Author: Howard M. Lewis Ship 
Authored: Thu Jul 25 12:55:24 2013 -0700
Committer: Howard M. Lewis Ship 
Committed: Thu Jul 25 12:55:24 2013 -0700

--
 .../corelib/pages/PropertyDisplayBlocks.java | 19 +++
 1 file changed, 7 insertions(+), 12 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/tapestry-5/blob/8f52e122/tapestry-core/src/main/java/org/apache/tapestry5/corelib/pages/PropertyDisplayBlocks.java
--
diff --git 
a/tapestry-core/src/main/java/org/apache/tapestry5/corelib/pages/PropertyDisplayBlocks.java
 
b/tapestry-core/src/main/java/org/apache/tapestry5/corelib/pages/PropertyDisplayBlocks.java
index 487457a..92c72b6 100644
--- 
a/tapestry-core/src/main/java/org/apache/tapestry5/corelib/pages/PropertyDisplayBlocks.java
+++ 
b/tapestry-core/src/main/java/org/apache/tapestry5/corelib/pages/PropertyDisplayBlocks.java
@@ -1,4 +1,4 @@
-// Copyright 2007, 2008, 2010 The Apache Software Foundation
+// Copyright 2007, 2008, 2010, 2013 The Apache Software Foundation
 //
 // Licensed under the Apache License, Version 2.0 (the "License");
 // you may not use this file except in compliance with the License.
@@ -39,8 +39,6 @@ public class PropertyDisplayBlocks
 @Inject
 private Locale locale;
 
-private final DateFormat dateFormat = 
DateFormat.getDateInstance(DateFormat.MEDIUM, locale);
-
 public String getConvertedEnumValue()
 {
 Enum value = (Enum) context.getPropertyValue();
@@ -52,18 +50,15 @@ public class PropertyDisplayBlocks
 
 public DateFormat getDateFormat()
 {
-return dateFormat;
+return DateFormat.getDateInstance(DateFormat.MEDIUM, locale);
 }
-
-public Date getCalendarDate() 
+
+public Date getCalendarDate()
 {
 Calendar calendar = (Calendar) context.getPropertyValue();
-
-if(calendar == null)
-return null;
-
-return calendar.getTime();
- }
+
+return calendar == null ? null : calendar.getTime();
+}
 
 
 public PropertyOutputContext getContext()



[jira] [Closed] (TAP5-2026) Excesive Error logging on yuicompressor

2013-07-25 Thread Howard M. Lewis Ship (JIRA)

 [ 
https://issues.apache.org/jira/browse/TAP5-2026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Howard M. Lewis Ship closed TAP5-2026.
--

Resolution: Won't Fix

tapestry-yuicompressor module has been removed in 5.4, replaced with 
tapestry-wro4j

> Excesive Error logging on yuicompressor
> ---
>
> Key: TAP5-2026
> URL: https://issues.apache.org/jira/browse/TAP5-2026
> Project: Tapestry 5
>  Issue Type: Bug
>  Components: tapestry-yuicompressor
>Affects Versions: 5.3.5, 5.3.6
>Reporter: jose luis sanchez
>Priority: Trivial
>  Labels: javascript,, minified,, yuicompressor
>
> I've found that sometimes, the tapestry5-yuicompressor component rethrows 
> excesive output when it does find an error in minifying css/js files.
> Le me show the error in see in my logs.
> 12:11:06.552 ERROR o.a.t.s.a.A.ResourceMinimizer - JavaScript compression 
> problems for resource 'core' JavaScript stack, for locale en, 
> resources=classpath:org/apache/tapestry5/underscore_1_3_3.js, 
> classpath:org/apache/tapestry5/scriptaculous_1_9_0/prototype.js, 
> classpath:org/apache/tapestry5/scriptaculous_1_9_0/scriptaculous.js, 
> classpath:org/apache/tapestry5/scriptaculous_1_9_0/effects.js, 
> classpath:org/apache/tapestry5/t5-core.js, 
> classpath:org/apache/tapestry5/t5-spi.js, 
> classpath:org/apache/tapestry5/t5-prototype.js, 
> classpath:org/apache/tapestry5/t5-init.js, 
> classpath:org/apache/tapestry5/t5-pubsub.js, 
> classpath:org/apache/tapestry5/t5-events.js, 
> classpath:org/apache/tapestry5/t5-dom.js, 
> classpath:org/apache/tapestry5/t5-console.js, 
> classpath:org/apache/tapestry5/t5-ajax.js, 
> classpath:org/apache/tapestry5/t5-formfragment.js, 
> classpath:org/apache/tapestry5/t5-alerts.js, 
> classpath:org/apache/tapestry5/tapestry.js, 
> classpath:org/apache/tapestry5/tapestry-console.js, 
> classpath:org/apache/tapestry5/tree.js, 
> classpath:org/apache/tapestry5/tapestry-messages.js:
> 12:11:06.554 ERROR o.a.t.s.a.A.ResourceMinimizer - java.lang.RuntimeException
> java.lang.RuntimeException: null
>   at 
> com.yahoo.platform.yui.compressor.JavaScriptCompressor.printSourceNumber(JavaScriptCompressor.java:299)
>  ~[yuicompressor-2.4.7.jar:na]
>   at 
> com.yahoo.platform.yui.compressor.JavaScriptCompressor.parse(JavaScriptCompressor.java:336)
>  ~[yuicompressor-2.4.7.jar:na]
>   at 
> com.yahoo.platform.yui.compressor.JavaScriptCompressor.(JavaScriptCompressor.java:533)
>  ~[yuicompressor-2.4.7.jar:na]
>   at 
> org.apache.tapestry5.internal.yuicompressor.JavaScriptResourceMinimizer.doMinimize(JavaScriptResourceMinimizer.java:150)
>  ~[tapestry-yuicompressor-5.3.6.jar:na]
>   at 
> org.apache.tapestry5.internal.yuicompressor.AbstractMinimizer$1.perform(AbstractMinimizer.java:67)
>  [tapestry-yuicompressor-5.3.6.jar:na]
>   at 
> org.apache.tapestry5.internal.TapestryInternalUtils$5.run(TapestryInternalUtils.java:582)
>  [tapestry-core-5.3.6.jar:na]
>   at 
> org.apache.tapestry5.ioc.internal.OperationTrackerImpl$1.invoke(OperationTrackerImpl.java:51)
>  [tapestry-ioc-5.3.6.jar:na]
>   at 
> org.apache.tapestry5.ioc.internal.OperationTrackerImpl$1.invoke(OperationTrackerImpl.java:48)
>  [tapestry-ioc-5.3.6.jar:na]
>   at 
> org.apache.tapestry5.ioc.internal.OperationTrackerImpl.invoke(OperationTrackerImpl.java:74)
>  [tapestry-ioc-5.3.6.jar:na]
>   at 
> org.apache.tapestry5.ioc.internal.OperationTrackerImpl.run(OperationTrackerImpl.java:47)
>  [tapestry-ioc-5.3.6.jar:na]
>   at 
> org.apache.tapestry5.ioc.internal.PerThreadOperationTracker.run(PerThreadOperationTracker.java:76)
>  [tapestry-ioc-5.3.6.jar:na]
>   at 
> org.apache.tapestry5.ioc.internal.RegistryImpl.run(RegistryImpl.java:1119) 
> [tapestry-ioc-5.3.6.jar:na]
>   at 
> org.apache.tapestry5.internal.TapestryInternalUtils.performIO(TapestryInternalUtils.java:576)
>  [tapestry-core-5.3.6.jar:na]
>   at 
> org.apache.tapestry5.internal.yuicompressor.AbstractMinimizer.minimize(AbstractMinimizer.java:61)
>  [tapestry-yuicompressor-5.3.6.jar:na]
>   at 
> org.apache.tapestry5.internal.services.assets.MasterResourceMinimizer.minimize(MasterResourceMinimizer.java:44)
>  [tapestry-core-5.3.6.jar:na]
>   at $ResourceMinimizer_49a4f82ce9661.minimize(Unknown Source) [na:na]
>   at 
> org.apache.tapestry5.internal.services.assets.StackAssetRequestHandler.assembleStackContent(StackAssetRequestHandler.java:175)
>  [tapestry-core-5.3.6.jar:na]
>   at 
> org.apache.tapestry5.internal.services.assets.StackAssetRequestHandler.assembleStackContent(StackAssetRequestHandler.java:163)
>  [tapestry-core-5.3.6.jar:na]
>   at 
> org.apache.tapestry5.internal.services.assets.StackAssetRequestHandler.getUncompressedResource(StackAssetRequestHandler.java:146)
>  [tapestry-core-5.3.6.jar:n

git commit: TAP5-2073: AbstractEventContext always emits "null" regardless of what values are defined by subclass

2013-07-25 Thread hlship
Updated Branches:
  refs/heads/master b8627d043 -> 12cb5670a


TAP5-2073: AbstractEventContext always emits "null" regardless of what values 
are defined by subclass


Project: http://git-wip-us.apache.org/repos/asf/tapestry-5/repo
Commit: http://git-wip-us.apache.org/repos/asf/tapestry-5/commit/12cb5670
Tree: http://git-wip-us.apache.org/repos/asf/tapestry-5/tree/12cb5670
Diff: http://git-wip-us.apache.org/repos/asf/tapestry-5/diff/12cb5670

Branch: refs/heads/master
Commit: 12cb5670a762c025b5932efac77fc49683bbc382
Parents: b8627d0
Author: Howard M. Lewis Ship 
Authored: Thu Jul 25 12:53:12 2013 -0700
Committer: Howard M. Lewis Ship 
Committed: Thu Jul 25 12:53:12 2013 -0700

--
 .../internal/AbstractEventContext.java  | 21 
 .../internal/services/EventContextTests.java| 10 +-
 2 files changed, 17 insertions(+), 14 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/tapestry-5/blob/12cb5670/tapestry-core/src/main/java/org/apache/tapestry5/internal/AbstractEventContext.java
--
diff --git 
a/tapestry-core/src/main/java/org/apache/tapestry5/internal/AbstractEventContext.java
 
b/tapestry-core/src/main/java/org/apache/tapestry5/internal/AbstractEventContext.java
index a8feab1..443a01a 100644
--- 
a/tapestry-core/src/main/java/org/apache/tapestry5/internal/AbstractEventContext.java
+++ 
b/tapestry-core/src/main/java/org/apache/tapestry5/internal/AbstractEventContext.java
@@ -1,4 +1,4 @@
-// Copyright 2010 The Apache Software Foundation
+// Copyright 2010, 2013 The Apache Software Foundation
 //
 // Licensed under the Apache License, Version 2.0 (the "License");
 // you may not use this file except in compliance with the License.
@@ -18,8 +18,6 @@ import org.apache.tapestry5.EventContext;
 
 public abstract class AbstractEventContext implements EventContext
 {
-private String[] values;
-
 public String[] toStrings()
 {
 int count = getCount();
@@ -37,21 +35,18 @@ public abstract class AbstractEventContext implements 
EventContext
 @Override
 public String toString()
 {
-StringBuilder builder = new StringBuilder("EventContext:");
+StringBuilder builder = new StringBuilder("").toString();
 }
 }

http://git-wip-us.apache.org/repos/asf/tapestry-5/blob/12cb5670/tapestry-core/src/test/java/org/apache/tapestry5/internal/services/EventContextTests.java
--
diff --git 
a/tapestry-core/src/test/java/org/apache/tapestry5/internal/services/EventContextTests.java
 
b/tapestry-core/src/test/java/org/apache/tapestry5/internal/services/EventContextTests.java
index 78e77ff..8e8b2d8 100644
--- 
a/tapestry-core/src/test/java/org/apache/tapestry5/internal/services/EventContextTests.java
+++ 
b/tapestry-core/src/test/java/org/apache/tapestry5/internal/services/EventContextTests.java
@@ -1,4 +1,4 @@
-// Copyright 2010 The Apache Software Foundation
+// Copyright 2010, 2013 The Apache Software Foundation
 //
 // Licensed under the Apache License, Version 2.0 (the "License");
 // you may not use this file except in compliance with the License.
@@ -45,4 +45,12 @@ public class EventContextTests extends InternalBaseTestCase
 {
 assertEquals(new EmptyEventContext().toStrings(), new String[0]);
 }
+
+@Test
+public void to_string_of_event_context() {
+
+EventContext ec = new ArrayEventContext(typeCoercer, 1, 2.3);
+
+assertEquals(ec.toString(), "");
+}
 }



[jira] [Closed] (TAP5-2073) AbstractEventContext always emits "null" regardless of what values are defined by subclass

2013-07-25 Thread Howard M. Lewis Ship (JIRA)

 [ 
https://issues.apache.org/jira/browse/TAP5-2073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Howard M. Lewis Ship closed TAP5-2073.
--

   Resolution: Fixed
Fix Version/s: 5.4
 Assignee: Howard M. Lewis Ship

> AbstractEventContext always emits "null" regardless of what values are 
> defined by subclass
> --
>
> Key: TAP5-2073
> URL: https://issues.apache.org/jira/browse/TAP5-2073
> Project: Tapestry 5
>  Issue Type: Bug
>  Components: tapestry-core
>Affects Versions: 5.3.6
>Reporter: Petr Charvát
>Assignee: Howard M. Lewis Ship
>Priority: Trivial
> Fix For: 5.4
>
>
> In the issue TA5-1505 were implemented toString method in the 
> AbstractEventContext. Its implementation work with the String[] values are 
> private in the AbstractEventContext. 
> URLEventContext has its own values array. As a result, toString method of the 
> URLEventContext always returns 'null' string - not OK.

--
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-2073) AbstractEventContext always emits "null" regardless of what values are defined by subclass

2013-07-25 Thread Howard M. Lewis Ship (JIRA)

 [ 
https://issues.apache.org/jira/browse/TAP5-2073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Howard M. Lewis Ship updated TAP5-2073:
---

Summary: AbstractEventContext always emits "null" regardless of what values 
are defined by subclass  (was: URLEventContext toString() always returns null )

> AbstractEventContext always emits "null" regardless of what values are 
> defined by subclass
> --
>
> Key: TAP5-2073
> URL: https://issues.apache.org/jira/browse/TAP5-2073
> Project: Tapestry 5
>  Issue Type: Bug
>  Components: tapestry-core
>Affects Versions: 5.3.6
>Reporter: Petr Charvát
>Priority: Trivial
>
> In the issue TA5-1505 were implemented toString method in the 
> AbstractEventContext. Its implementation work with the String[] values are 
> private in the AbstractEventContext. 
> URLEventContext has its own values array. As a result, toString method of the 
> URLEventContext always returns 'null' string - not OK.

--
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-2073) AbstractEventContext always emits "null" regardless of what values are defined by subclass

2013-07-25 Thread Howard M. Lewis Ship (JIRA)

[ 
https://issues.apache.org/jira/browse/TAP5-2073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13719976#comment-13719976
 ] 

Howard M. Lewis Ship commented on TAP5-2073:


Looks like there was a bad refactoring at some point.

> AbstractEventContext always emits "null" regardless of what values are 
> defined by subclass
> --
>
> Key: TAP5-2073
> URL: https://issues.apache.org/jira/browse/TAP5-2073
> Project: Tapestry 5
>  Issue Type: Bug
>  Components: tapestry-core
>Affects Versions: 5.3.6
>Reporter: Petr Charvát
>Priority: Trivial
>
> In the issue TA5-1505 were implemented toString method in the 
> AbstractEventContext. Its implementation work with the String[] values are 
> private in the AbstractEventContext. 
> URLEventContext has its own values array. As a result, toString method of the 
> URLEventContext always returns 'null' string - not OK.

--
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-797) Using "tapestry.combine-scripts" with an EmptyClientInfrastructure still adds an empty JavaScript file

2013-07-25 Thread Howard M. Lewis Ship (JIRA)

 [ 
https://issues.apache.org/jira/browse/TAP5-797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Howard M. Lewis Ship closed TAP5-797.
-

Resolution: Won't Fix

Time has moved on; all the asset infrastructure has changed repeatedly since 
5.1.

> Using "tapestry.combine-scripts" with an EmptyClientInfrastructure still adds 
> an empty JavaScript file
> --
>
> Key: TAP5-797
> URL: https://issues.apache.org/jira/browse/TAP5-797
> Project: Tapestry 5
>  Issue Type: Bug
>  Components: tapestry-core
>Affects Versions: 5.1.0.5
>Reporter: Carl Crowder
>Priority: Minor
>  Labels: bulk-close-candidate
> Attachments: check_no_script_tag_if_no_scripts.diff
>
>
> If you have "tapestry.combine-scripts" set to true, and override the 
> ClientInfrastructure service to not add any assets, the DocumentLinkerImpl 
> still inserts a SCRIPT tag into the document. The JavaScript it generates is 
> empty except for a call to the Tapestry JavaScript object, which isn't part 
> of the page anyway as no other JavaScript has been loaded.
> This a) causes a JavaScript error and b) adds unecessary HTTP requests.

--
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-800) Server side error during provideCompletions event for Autocompleter mixin is not reported on the client side properly

2013-07-25 Thread Howard M. Lewis Ship (JIRA)

 [ 
https://issues.apache.org/jira/browse/TAP5-800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Howard M. Lewis Ship closed TAP5-800.
-

   Resolution: Fixed
Fix Version/s: 5.4
 Assignee: Howard M. Lewis Ship

As part of the refresh in 5.4, the Autocompleter was rewritten, and is now 
based on the Bootstrap Typeahead component, and no longer has this issue; 
server-side failures are reported the same as any other Ajax-related request.

> Server side error during provideCompletions event for Autocompleter mixin is 
> not reported on the client side properly
> -
>
> Key: TAP5-800
> URL: https://issues.apache.org/jira/browse/TAP5-800
> Project: Tapestry 5
>  Issue Type: Bug
>  Components: tapestry-core
>Affects Versions: 5.1.0.5
>Reporter: Howard M. Lewis Ship
>Assignee: Howard M. Lewis Ship
>Priority: Minor
>  Labels: bulk-close-candidate
> Fix For: 5.4
>
>
> You would expect that the console would be raised to display the Ajax error 
> (as happens with, say, a Zone update) but instead you get no notification and 
> some wierd presentation oddities (I believe because the autocompleter is 
> expecting an  markup snippet, and instead recieves the exception report 
> page!).
> It may just be time to find a complete replacement for the 
> Scriptaculous.Autocompleter.

--
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-691) Unclear exceptions for classes within wrong packages

2013-07-25 Thread Howard M. Lewis Ship (JIRA)

 [ 
https://issues.apache.org/jira/browse/TAP5-691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Howard M. Lewis Ship closed TAP5-691.
-

Resolution: Won't Fix

I suspect the exceptions have improved since this was reported.

> Unclear exceptions for classes within wrong packages
> 
>
> Key: TAP5-691
> URL: https://issues.apache.org/jira/browse/TAP5-691
> Project: Tapestry 5
>  Issue Type: Bug
>Affects Versions: 5.1.0.5
>Reporter: Michael Wyraz
>Priority: Minor
>
> Hi,
> since I'm new to tapestry I started with creating a completely new project 
> (without maven) based on the information provied within the samples. So i 
> created a Page that edits an address. The address was created within th esame 
> apckes ("pages"). In the result, tapestry tried to create the address object 
> as service. The problem is that the generated exception is very wired so that 
> the cause was almost impossible to locate. Example:
> 13:42:02,541 ERROR Registry:75 - No service implements the interface 
> org.apache.tapestry5.internal.InternalComponentResources.
> 13:42:02,545 ERROR Registry:76 - Operations trace:
> 13:42:02,546 ERROR Registry:85 - [ 1] Autobuilding instance of class 
> test.pages.AddressDTO
> 13:42:02,547 ERROR Registry:85 - [ 2] Determining injection value for 
> parameter #1 (org.apache.tapestry5.internal.InternalComponentResources)
> 13:42:02,548 ERROR Registry:85 - [ 3] Resolving object of type 
> org.apache.tapestry5.internal.InternalComponentResources using 
> MasterObjectProvider
> 13:42:02,554 ERROR TestPage1:84 - Render queue error in 
> SetupRender[TestPage1:beaneditform.editor]: Exception instantiating instance 
> of test.pages.AddressDTO (for component 'TestPage1:beaneditform.editor'): 
> Error invoking constructor test.pages.AddressDTO(InternalComponentResources) 
> (for service 'BeanModelSource'): No service implements the interface 
> org.apache.tapestry5.internal.InternalComponentResources.
> org.apache.tapestry5.ioc.internal.util.TapestryException: Exception 
> instantiating instance of test.pages.AddressDTO (for component 
> 'TestPage1:beaneditform.editor'): Error invoking constructor 
> test.pages.AddressDTO(InternalComponentResources) (for service 
> 'BeanModelSource'): No service implements the interface 
> org.apache.tapestry5.internal.InternalComponentResources. [at 
> classpath:org/apache/tapestry5/corelib/components/BeanEditForm.tml, line 7]
>   at 
> org.apache.tapestry5.internal.structure.ComponentPageElementImpl.invoke(ComponentPageElementImpl.java:948)
>   at 
> org.apache.tapestry5.internal.structure.ComponentPageElementImpl.access$400(ComponentPageElementImpl.java:49)
>   at 
> org.apache.tapestry5.internal.structure.ComponentPageElementImpl$AbstractPhase.callback(ComponentPageElementImpl.java:159)
>   at 
> org.apache.tapestry5.internal.structure.ComponentPageElementImpl$SetupRenderPhase.render(ComponentPageElementImpl.java:189)
>   at 
> org.apache.tapestry5.internal.services.RenderQueueImpl.run(RenderQueueImpl.java:74)
>   at 
> org.apache.tapestry5.internal.services.PageRenderQueueImpl.render(PageRenderQueueImpl.java:121)
>   at 
> $PageRenderQueue_1212f7ab15b.render($PageRenderQueue_1212f7ab15b.java)
>   at 
> $PageRenderQueue_1212f7ab153.render($PageRenderQueue_1212f7ab153.java)
>   at 
> org.apache.tapestry5.internal.services.MarkupRendererTerminator.renderMarkup(MarkupRendererTerminator.java:37)
>   at 
> org.apache.tapestry5.services.TapestryModule$27.renderMarkup(TapestryModule.java:1748)
>   at 
> $MarkupRenderer_1212f7ab15d.renderMarkup($MarkupRenderer_1212f7ab15d.java)
>   at 
> org.apache.tapestry5.services.TapestryModule$26.renderMarkup(TapestryModule.java:1732)
>   at 
> $MarkupRenderer_1212f7ab15d.renderMarkup($MarkupRenderer_1212f7ab15d.java)
>   at 
> org.apache.tapestry5.services.TapestryModule$25.renderMarkup(TapestryModule.java:1714)
>   at 
> $MarkupRenderer_1212f7ab15d.renderMarkup($MarkupRenderer_1212f7ab15d.java)
>   at 
> org.apache.tapestry5.services.TapestryModule$24.renderMarkup(TapestryModule.java:1700)
>   at 
> $MarkupRenderer_1212f7ab15d.renderMarkup($MarkupRenderer_1212f7ab15d.java)
>   at 
> org.apache.tapestry5.services.TapestryModule$23.renderMarkup(TapestryModule.java:1681)
>   at 
> $MarkupRenderer_1212f7ab15d.renderMarkup($MarkupRenderer_1212f7ab15d.java)
>   at 
> org.apache.tapestry5.services.TapestryModule$22.renderMarkup(TapestryModule.java:1662)
>   at 
> $MarkupRenderer_1212f7ab15d.renderMarkup($MarkupRenderer_1212f7ab15d.java)
>   at 
> $MarkupRenderer_1212f7ab15a.renderMarkup($MarkupRenderer_1212f7ab15a.java)
>   at 
> org.apache.tapestry5.internal.services.PageMarkupRendererImpl.renderPageMarkup(PageMarkupRendererImpl.java:64)

[jira] [Closed] (TAP5-876) Arrow icons used by Palette component should be converted to GIFs to look reasonable in IE

2013-07-25 Thread Howard M. Lewis Ship (JIRA)

 [ 
https://issues.apache.org/jira/browse/TAP5-876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Howard M. Lewis Ship closed TAP5-876.
-

Resolution: Invalid

This is no longer the case under 5.4, where the icons are presented using 
Bootstrap icon-xxx classes.

> Arrow icons used by Palette component should be converted to GIFs to look 
> reasonable in IE
> --
>
> Key: TAP5-876
> URL: https://issues.apache.org/jira/browse/TAP5-876
> Project: Tapestry 5
>  Issue Type: Bug
>  Components: tapestry-core
>Reporter: Howard M. Lewis Ship
>Priority: Minor
>
> Hate to compromise on this (PNG is the way to go) but they just look awful in 
> IE.

--
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-883) Regexp validator behaviour differs on client and server side

2013-07-25 Thread Howard M. Lewis Ship (JIRA)

 [ 
https://issues.apache.org/jira/browse/TAP5-883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Howard M. Lewis Ship closed TAP5-883.
-

Resolution: Won't Fix

> Regexp validator behaviour differs on client and server side
> 
>
> Key: TAP5-883
> URL: https://issues.apache.org/jira/browse/TAP5-883
> Project: Tapestry 5
>  Issue Type: Bug
>  Components: tapestry-core
>Affects Versions: 5.1.0.5
>Reporter: Dirk Lattermann
>Priority: Minor
>  Labels: bulk-close-candidate
>
> In some situations, a value can pass client side regexp validation and fail 
> the server side validation. This should not be the case.
> The server regexp validator requires a value to match the regexp exactly from 
> start to end which is not the case on the client (browser).
> For example, given a regexp of [a-z]{2}, a value of hu4 passes validation on 
> the client and fails on the server.
> Workaround: use anchored regexps like ^[a-z]{2}$

--
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-957) Tapestry's use of the beforeunload event conflicts with how IE operates

2013-07-25 Thread Howard M. Lewis Ship (JIRA)

 [ 
https://issues.apache.org/jira/browse/TAP5-957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Howard M. Lewis Ship closed TAP5-957.
-

Resolution: Invalid

Tapestry 5.4 no longer uses beforeunload.

> Tapestry's use of the beforeunload event conflicts with how IE operates
> ---
>
> Key: TAP5-957
> URL: https://issues.apache.org/jira/browse/TAP5-957
> Project: Tapestry 5
>  Issue Type: Bug
>  Components: tapestry-core
>Affects Versions: 5.1.0.5
>Reporter: mindhawk
>Priority: Minor
>  Labels: ie, javascript
>
> IE will generate a "beforeunload " event when a link such as " href='javascript:show()'>show"  is clicked. So Tapestry.windowUnloaded is 
> set to true. That means all ajax request have no chance to refresh the page 
> after this event.
> Now, I have to set Tapestry.windowUnloaded=false, every time I want to send a 
> ajax request. I don't think thisis a good practice. 
> I think there will be some more smart approach to replace 
> Tapestry.windowUnloaded, or just remove it. because, the request is sent to 
> the server no matter the value is true or false. This value is only discard 
> the responses from the server.

--
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-1016) unable to locate static asset if folder name contains a '.' character

2013-07-25 Thread Howard M. Lewis Ship (JIRA)

 [ 
https://issues.apache.org/jira/browse/TAP5-1016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Howard M. Lewis Ship closed TAP5-1016.
--

Resolution: Cannot Reproduce

If this is still a problem, please provide a test case and re-open the issue.

> unable to locate static asset if folder name contains a '.' character
> -
>
> Key: TAP5-1016
> URL: https://issues.apache.org/jira/browse/TAP5-1016
> Project: Tapestry 5
>  Issue Type: Bug
>Affects Versions: 5.2
>Reporter: Jim Smart
>Priority: Minor
>
> i have just upgraded from tapestry 5.1.0.5 to 5.2.0-snapshot (using the 
> version 5.2.0 snapshot in the maven repository)
> i have found a minor regression...
> in 5.1.0.5 the following line would work ok:-
>  type="text/css"/>
> ...but under the version of 5.2.0-snapshot that i am running, this produces a 
> (behind the scenes) 404 when the page tries to load the css in question 
> (resulting in an un-styled page), although the created url looks fine to me.
> i have narrowed down the issue to this:-
> if i remove the '.' chars from the folder names (ie. change 'my.folder.name' 
> to 'my-folder-name', or similar) then 5.2.0-snapshot is fine with the path -- 
> otherwise it seems to simply pretend that the files in question don't 
> exist... :-/
> fwiw, having extra dots in the filename (eg. my.test.css) works ok, the 
> problem only seems to be with folder names.
> the same problem applies to images also, not just css files - is it a bad 
> regex somewhere in the new asset protection code maybe?

--
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-1022) Undeploying an EAR with Tapestry causing an InputStream exception in Glassfish 2.1

2013-07-25 Thread Howard M. Lewis Ship (JIRA)

 [ 
https://issues.apache.org/jira/browse/TAP5-1022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Howard M. Lewis Ship closed TAP5-1022.
--

Resolution: Cannot Reproduce

I fixed another bug that I believe to be the underlying problem; the stack 
trace you presented appears to be a stack trace from after re-deployment; it 
does not look like a stack trace for undeployment.

If you can reproduce this under 5.4, please re-open this issue.

> Undeploying an EAR with Tapestry causing an InputStream exception in 
> Glassfish 2.1
> --
>
> Key: TAP5-1022
> URL: https://issues.apache.org/jira/browse/TAP5-1022
> Project: Tapestry 5
>  Issue Type: Bug
>  Components: tapestry-ioc
>Affects Versions: 5.1.0.5
>Reporter: Laurent Prévost
>Priority: Minor
>
> When I try to undeploy my EAR application that contains Tapestry, an 
> exception is thrown as the stackTrace below shows. But, at least, the 
> application could be undeploy without any consequences.
> [#|2010-02-19T10:09:16.972+0100|INFO|sun-appserver2.1|javax.enterprise.system.stream.out|_ThreadID=15;_ThreadName=httpWorkerThread-14848-1;|
> SharedSecrets.getJavaNetAccess()=java.net.URLClassLoader$7@1adaaab0|#]
> [#|2010-02-19T10:09:18.152+0100|WARNING|sun-appserver2.1|javax.enterprise.system.core.classloading|_ThreadID=15;_ThreadName=httpWorkerThread-14848-1;_RequestID=f985072a-1db3-4c5f-bb85-88434104dbd2;|Input
>  stream has been finalized or forced closed without being explicitly closed; 
> stream instantiation reported in following stack trace
> java.lang.Throwable
>   at 
> com.sun.enterprise.loader.EJBClassLoader$SentinelInputStream.(EJBClassLoader.java:1166)
>   at 
> com.sun.enterprise.loader.EJBClassLoader$InternalJarURLConnection.getInputStream(EJBClassLoader.java:1259)
>   at java.net.URL.openStream(URL.java:1010)
>   at java.lang.ClassLoader.getResourceAsStream(ClassLoader.java:1232)
>   at 
> com.sun.enterprise.loader.EJBClassLoader.getResourceAsStream(EJBClassLoader.java:796)
>   at 
> org.apache.catalina.loader.WebappClassLoader.getResourceAsStream(WebappClassLoader.java:1288)
>   at 
> org.apache.tapestry5.VersionUtils.readVersionNumber(VersionUtils.java:43)
>   at 
> org.apache.tapestry5.services.TapestryModule.contributeFactoryDefaults(TapestryModule.java:2007)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>   at java.lang.reflect.Method.invoke(Method.java:597)
>   at 
> org.apache.tapestry5.ioc.internal.ContributionDefImpl.invokeMethod(ContributionDefImpl.java:110)
>   at 
> org.apache.tapestry5.ioc.internal.ContributionDefImpl.contribute(ContributionDefImpl.java:71)
>   at 
> org.apache.tapestry5.ioc.internal.RegistryImpl$4.run(RegistryImpl.java:470)
>   at 
> org.apache.tapestry5.ioc.internal.OperationTrackerImpl$1.invoke(OperationTrackerImpl.java:52)
>   at 
> org.apache.tapestry5.ioc.internal.OperationTrackerImpl$1.invoke(OperationTrackerImpl.java:50)
>   at 
> org.apache.tapestry5.ioc.internal.OperationTrackerImpl.invoke(OperationTrackerImpl.java:68)
>   at 
> org.apache.tapestry5.ioc.internal.OperationTrackerImpl.run(OperationTrackerImpl.java:48)
>   at 
> org.apache.tapestry5.ioc.internal.PerThreadOperationTracker.run(PerThreadOperationTracker.java:56)
>   at 
> org.apache.tapestry5.ioc.internal.RegistryImpl.addToMappedConfiguration(RegistryImpl.java:466)
>   at 
> org.apache.tapestry5.ioc.internal.RegistryImpl.getMappedConfiguration(RegistryImpl.java:416)
>   at 
> org.apache.tapestry5.ioc.internal.ServiceResourcesImpl$3.invoke(ServiceResourcesImpl.java:126)
>   at 
> org.apache.tapestry5.ioc.internal.ServiceResourcesImpl$3.invoke(ServiceResourcesImpl.java:124)
>   at 
> org.apache.tapestry5.ioc.internal.OperationTrackerImpl.invoke(OperationTrackerImpl.java:68)
>   at 
> org.apache.tapestry5.ioc.internal.PerThreadOperationTracker.invoke(PerThreadOperationTracker.java:68)
>   at 
> org.apache.tapestry5.ioc.internal.RegistryImpl.invoke(RegistryImpl.java:941)
>   at 
> org.apache.tapestry5.ioc.internal.ServiceResourcesImpl.getMappedConfiguration(ServiceResourcesImpl.java:120)
>   at 
> org.apache.tapestry5.ioc.internal.AbstractServiceCreator.getMappedConfiguration(AbstractServiceCreator.java:142)
>   at 
> org.apache.tapestry5.ioc.internal.AbstractServiceCreator.access$300(AbstractServiceCreator.java:35)
>   at 
> org.apache.tapestry5.ioc.internal.AbstractServiceCreator$1.findResource(AbstractServiceCreator.java:107)
>   at 
> org.apache.tapestry5.ioc.internal.util.De

[jira] [Closed] (TAP5-2148) VersionUtils should close the stream it opens

2013-07-25 Thread Howard M. Lewis Ship (JIRA)

 [ 
https://issues.apache.org/jira/browse/TAP5-2148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Howard M. Lewis Ship closed TAP5-2148.
--

   Resolution: Fixed
Fix Version/s: 5.4

> VersionUtils should close the stream it opens
> -
>
> Key: TAP5-2148
> URL: https://issues.apache.org/jira/browse/TAP5-2148
> Project: Tapestry 5
>  Issue Type: Bug
>  Components: tapestry-core
>Affects Versions: 5.3, 5.4
>Reporter: Howard M. Lewis Ship
>Assignee: Howard M. Lewis Ship
>Priority: Minor
> Fix For: 5.4
>
>


--
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] [Assigned] (TAP5-2148) VersionUtils should close the stream it opens

2013-07-25 Thread Howard M. Lewis Ship (JIRA)

 [ 
https://issues.apache.org/jira/browse/TAP5-2148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Howard M. Lewis Ship reassigned TAP5-2148:
--

Assignee: Howard M. Lewis Ship

> VersionUtils should close the stream it opens
> -
>
> Key: TAP5-2148
> URL: https://issues.apache.org/jira/browse/TAP5-2148
> Project: Tapestry 5
>  Issue Type: Bug
>  Components: tapestry-core
>Affects Versions: 5.3, 5.4
>Reporter: Howard M. Lewis Ship
>Assignee: Howard M. Lewis Ship
>Priority: Minor
>


--
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


git commit: TAP5-2148: VersionUtils should close the stream it opens

2013-07-25 Thread hlship
Updated Branches:
  refs/heads/master 714a6027f -> b8627d043


TAP5-2148: VersionUtils should close the stream it opens


Project: http://git-wip-us.apache.org/repos/asf/tapestry-5/repo
Commit: http://git-wip-us.apache.org/repos/asf/tapestry-5/commit/b8627d04
Tree: http://git-wip-us.apache.org/repos/asf/tapestry-5/tree/b8627d04
Diff: http://git-wip-us.apache.org/repos/asf/tapestry-5/diff/b8627d04

Branch: refs/heads/master
Commit: b8627d04393cafa4ccd43ab48271853d0c1351b2
Parents: 714a602
Author: Howard M. Lewis Ship 
Authored: Thu Jul 25 12:33:02 2013 -0700
Committer: Howard M. Lewis Ship 
Committed: Thu Jul 25 12:33:02 2013 -0700

--
 .../src/main/java/org/apache/tapestry5/VersionUtils.java | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/tapestry-5/blob/b8627d04/tapestry-core/src/main/java/org/apache/tapestry5/VersionUtils.java
--
diff --git a/tapestry-core/src/main/java/org/apache/tapestry5/VersionUtils.java 
b/tapestry-core/src/main/java/org/apache/tapestry5/VersionUtils.java
index 3aae7b9..130ed31 100644
--- a/tapestry-core/src/main/java/org/apache/tapestry5/VersionUtils.java
+++ b/tapestry-core/src/main/java/org/apache/tapestry5/VersionUtils.java
@@ -1,4 +1,4 @@
-// Copyright 2007, 2008, 2011 The Apache Software Foundation
+// Copyright 2007-2013 The Apache Software Foundation
 //
 // Licensed under the Apache License, Version 2.0 (the "License");
 // you may not use this file except in compliance with the License.
@@ -54,6 +54,8 @@ public class VersionUtils
 stream = new BufferedInputStream(stream);
 
 properties.load(stream);
+
+stream.close();
 }
 catch (IOException ex)
 {



[jira] [Created] (TAP5-2148) VersionUtils should close the stream it opens

2013-07-25 Thread Howard M. Lewis Ship (JIRA)
Howard M. Lewis Ship created TAP5-2148:
--

 Summary: VersionUtils should close the stream it opens
 Key: TAP5-2148
 URL: https://issues.apache.org/jira/browse/TAP5-2148
 Project: Tapestry 5
  Issue Type: Bug
  Components: tapestry-core
Affects Versions: 5.3, 5.4
Reporter: Howard M. Lewis Ship
Priority: Minor




--
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-1353) Referencing library from root source causes tapestry to trim off first charater from file name.

2013-07-25 Thread Howard M. Lewis Ship (JIRA)

 [ 
https://issues.apache.org/jira/browse/TAP5-1353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Howard M. Lewis Ship closed TAP5-1353.
--

Resolution: Invalid
  Assignee: Howard M. Lewis Ship

I'm pretty certain this has been subsequently fixed.

> Referencing library from root source causes tapestry to trim off first 
> charater from file name.
> ---
>
> Key: TAP5-1353
> URL: https://issues.apache.org/jira/browse/TAP5-1353
> Project: Tapestry 5
>  Issue Type: Bug
>  Components: tapestry-core
>Affects Versions: 5.2
>Reporter: Adam Zimowski
>Assignee: Howard M. Lewis Ship
>Priority: Minor
>
> Given the following annotation on a component  (or page but haven't tried) 
> class:
> @Import(library="classpath:util.js")
> Given the following contribution in the module:
> public static void 
> contributeClasspathAssetAliasManager(MappedConfiguration 
> configuration) {
>  // see http://markmail.org/thread/rq4vp7hi437smsrh
>  configuration.add("js", "/");
> }
> Given that file util.js lives directly under src/
> Tapestry renders the page fine, but the reference to util.js is such that 
> first character of the file name is trimmed off:
>  type="text/javascript">
> Of course the file is inaccessible that way, but if I you manually add the 
> missing 'u' it will load fine.

--
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-1187) A Zone inside a Form that renders new content can fail with "The rendered content did not include any elements that allow for the positioning of the hidden form field's el

2013-07-25 Thread Howard M. Lewis Ship (JIRA)

 [ 
https://issues.apache.org/jira/browse/TAP5-1187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Howard M. Lewis Ship updated TAP5-1187:
---

Labels: ajax  (was: )

> A Zone inside a Form that renders new content can fail with "The rendered 
> content did not include any elements that allow for the positioning of the 
> hidden form field's element."
> --
>
> Key: TAP5-1187
> URL: https://issues.apache.org/jira/browse/TAP5-1187
> Project: Tapestry 5
>  Issue Type: Bug
>  Components: tapestry-core
>Affects Versions: 5.2
>Reporter: Howard M. Lewis Ship
>Priority: Minor
>  Labels: ajax
>
> This is about finding the correct location to place a hidden field to store 
> the t:formdata for the Zone.
> java.lang.IllegalStateException
> The rendered content did not include any elements that allow for the 
> positioning of the hidden form field's element.
> org.apache.tapestry5.corelib.internal.HiddenFieldPositioner.getElement(HiddenFieldPositioner.java:90)
> org.apache.tapestry5.corelib.components.Zone.afterRender(Zone.java:219)
> org.apache.tapestry5.internal.transform.RenderPhaseMethodWorker$Invoker.invoke(RenderPhaseMethodWorker.java:117)
> org.apache.tapestry5.internal.transform.RenderPhaseMethodWorker$RenderPhaseMethodAdvice.advise(RenderPhaseMethodWorker.java:86)
> org.apache.tapestry5.internal.services.AbstractComponentMethodInvocation.proceed(AbstractComponentMethodInvocation.java:86)
> org.apache.tapestry5.corelib.components.Zone.afterRender(Zone.java)
> org.apache.tapestry5.internal.structure.ComponentPageElementImpl$AfterRenderPhase.invokeComponent(ComponentPageElementImpl.java:400)
> org.apache.tapestry5.internal.structure.ComponentPageElementImpl$AbstractPhase.run(ComponentPageElementImpl.java:195)
> org.apache.tapestry5.internal.structure.ComponentPageElementImpl.invoke(ComponentPageElementImpl.java:974)
> org.apache.tapestry5.internal.structure.ComponentPageElementImpl.access$400(ComponentPageElementImpl.java:81)
> org.apache.tapestry5.internal.structure.ComponentPageElementImpl$AbstractPhase.callback(ComponentPageElementImpl.java:190)
> org.apache.tapestry5.internal.structure.ComponentPageElementImpl$AfterRenderPhase.render(ComponentPageElementImpl.java:405)
> org.apache.tapestry5.internal.services.RenderQueueImpl.run(RenderQueueImpl.java:74)
> org.apache.tapestry5.internal.services.PageRenderQueueImpl.render(PageRenderQueueImpl.java:121)
> org.apache.tapestry5.internal.services.MarkupRendererTerminator.renderMarkup(MarkupRendererTerminator.java:37)
> I believe that it should create the hidden field directly inside the Zone, or 
> possibly create a  inside the Zone to contain the necessary hidden field.
> A workaround is to provide a  somewhere inside the rendered content.

--
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-1425) AssetSource.getUnlocalizedAsset() should throw an exception if asset is found but does not actually exist

2013-07-25 Thread Howard M. Lewis Ship (JIRA)

 [ 
https://issues.apache.org/jira/browse/TAP5-1425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Howard M. Lewis Ship closed TAP5-1425.
--

   Resolution: Fixed
Fix Version/s: 5.3
 Assignee: Massimo Lusetti

Discovered this fixed bug while reviewing 5.4 bugs; this was fixed somewhere in 
the 5.3 timeframe.

> AssetSource.getUnlocalizedAsset() should throw an exception if asset is found 
> but does not actually exist
> -
>
> Key: TAP5-1425
> URL: https://issues.apache.org/jira/browse/TAP5-1425
> Project: Tapestry 5
>  Issue Type: Bug
>  Components: tapestry-core
>Affects Versions: 5.3, 5.2
>Reporter: Howard M. Lewis Ship
>Assignee: Massimo Lusetti
>Priority: Minor
> Fix For: 5.3
>
>
> From the JavaDoc:
>   /**
>  * Find an asset but does not attempt to localize it. If the path has no 
> prefix, it is assumed to
>  * be on the classpath.
>  * 
>  * @since 5.2.0
>  * @throws RuntimeException
>  * if the asset can not be found
>  */
>   Asset getUnlocalizedAsset(String path);
> I discoverred that I can pass an invalid path name and it works.  
> private Asset getLocalizedAssetFromResource(Resource unlocalized, Locale 
> locale)
> {
> Resource localized = locale == null ? unlocalized : 
> unlocalized.forLocale(locale);
> if (localized == null)
> throw new 
> RuntimeException(ServicesMessages.assetDoesNotExist(unlocalized));
> return getAssetForResource(localized);
> }
> That should be:
>   if (localized == null || ! localized.exists())

--
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-1512) Select update via zone inside a form confuses form's ValidationTracker

2013-07-25 Thread Howard M. Lewis Ship (JIRA)

 [ 
https://issues.apache.org/jira/browse/TAP5-1512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Howard M. Lewis Ship updated TAP5-1512:
---

Labels: ajax  (was: )

> Select update via zone inside a form confuses form's ValidationTracker
> --
>
> Key: TAP5-1512
> URL: https://issues.apache.org/jira/browse/TAP5-1512
> Project: Tapestry 5
>  Issue Type: Bug
>  Components: tapestry-core, tapestry-ioc
>Affects Versions: 5.2
>Reporter: Adam Zimowski
>Priority: Minor
>  Labels: ajax
>
> Here is the use case:
> We have a simple address form with Line 1, Line 2, City (all text fields), 
> State (Select), Zip (Text Field) and Country (Select). State select is 
> wrapped inside a Zone, which is tied to Country select, so that when country 
> is selected, states get populated. Line 1, City, State, Zip and Country are 
> all required. Form uses  next to each field.
> Here is the problem:
> 1. Select country and state (both have blank options therefore are required), 
> but leave other fields empty.
> 2. Submit form. Validation on required fields (such as city, zip) results in 
> form rendering error messages. Note: Country and State are
> not in error at this point.
> 3. While correcting errors on the form, change country. As a result, state 
> select component is repopulated (zone update), and default blank
> option is select. Do not chose state.
> 4. Submit form with state *not* selected. Debugging select shows that 
> ValidationTracker contains error (state required), yet attached field error 
> is not displaying the error.
> Upon debugging the framework I found the following:
> IdAllocator used to generate component id, suffixes select with an increment 
> even select is not inside a loop. It does this ONLY when Zone is updated, 
> causing the very subsequent form submit record error for select under wrong 
> key (a_state_1 rather than state), and so the  is unable to locate 
> the error when form eventually renders back with original select id (a_state).
> In this case, what happens is that every time I update zone while form is in 
> error, the ID of my select changes with incremented suffix:
> ORIGINAL AS EXPECTED BY FORM: a_state
> After resetting country causing state dropdown to repopulate, id becomes: 
> a_state_1 then a_state_2 etc...
> This causes ValidationTracker put error under wrong key, and consequently 
> error to field binding in tracker's map cannot be
> resolved, causing  thinking that all is good. That's why 
>  does display the error, as it simply loops over collection
> of errors.
> Out of lack of deep understanding of Tapestry, I coded a simple hack to 
> verify that if select update via zone kept its original id things
> would work, and indeed, the following hack fixes the problem for my case:
> Tapestry 5.2.5, AbstractField line 183:
>private void setupControlName(String controlName)
>{
>if(controlName.startsWith("a_state"))
>this.controlName = "a_state";
>else
>this.controlName = controlName;
>}
> Here is my source:
> 
> Address Information
>  
>   :
>   value="address.line1"/>
>  
>  
>  
>   :
>   value="address.line2"/>
>  
>  
>  
>   :
>   value="address.line3"/>
>  
>  
>  
>   :
>  
>  
>  
>  
>   :
>   value="address.zipCode"/>
>  
>  
>  
>   :
>   t:id="a_state" model="stateModel" validate="required"
> value="address.stateCode" blankOption="ALWAYS"
> blankLabel="literal:--Please Select"/>
>  
>  
>  
>   :
>   value="address.countryCode" blankOption="NEVER"
> zone="stateModelZone"/>
>  
>  
>  
>  
> 
> public class Register extends BasePage {
>@Inject
>private Logger log;
>@Inject
>private UtilityServiceRemote utilityService;
>@Persist
>@Property
>private AddressUiBean address;
>@OnEvent(value=EventConstants.PREPARE)
>void initialize() {
>if(address == null) address = new AddressUiBean();
>if(contact == null) contact = new ContactUiBean();
>if(registration == null) registration = new RegisterUiBean();
>String countryCode = address.getCountryCode();
>if(countryCode == null) {
>Locale locale = getLocale();
>countryCode = locale.getCountry();
>address.setCountryCode(countryCode);
>}
>log.debug("address state code {}", address.getStateCode());
>}
>@Cached
>public Map getCountryModel() {
>Map model = new LinkedHashMap String>();
>List countries =
>utilityService.getAllCountries(getLocale());
>for(CountryBean country : countries) {
> 

[jira] [Closed] (TAP5-1668) JavaDoc for @Parameter.value() should be clearer about the empty string

2013-07-25 Thread Howard M. Lewis Ship (JIRA)

 [ 
https://issues.apache.org/jira/browse/TAP5-1668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Howard M. Lewis Ship closed TAP5-1668.
--

   Resolution: Fixed
Fix Version/s: 5.4
 Assignee: Howard M. Lewis Ship

Updated the JavaDoc to be more explicit.

> JavaDoc for @Parameter.value() should be clearer about the empty string
> ---
>
> Key: TAP5-1668
> URL: https://issues.apache.org/jira/browse/TAP5-1668
> Project: Tapestry 5
>  Issue Type: Bug
>Affects Versions: 5.2
>Reporter: Geoff Callender
>Assignee: Howard M. Lewis Ship
>Priority: Minor
> Fix For: 5.4
>
>
> After reading the Parameter javadoc I expected these 3 to be equivalent.
>   @Parameter
>   private String tab;
>   @Parameter(value = "")
>   private String tab;
>   @Parameter
>   private String tab = "";
> but they are not: if the parameter is not bound, then in the first two its 
> value will be null, and in the third one it will be "".
> The javadoc is 
> http://tapestry.apache.org/tapestry5.2-dev/apidocs/org/apache/tapestry5/annotations/Parameter.html
>  .
> Is the behaviour wrong or does the javadoc need to be clearer?

--
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


git commit: TAP5-1668: JavaDoc for @Parameter.value() should be clearer about the empty string

2013-07-25 Thread hlship
Updated Branches:
  refs/heads/master 5dbc37202 -> 714a6027f


TAP5-1668: JavaDoc for @Parameter.value() should be clearer about the empty 
string


Project: http://git-wip-us.apache.org/repos/asf/tapestry-5/repo
Commit: http://git-wip-us.apache.org/repos/asf/tapestry-5/commit/714a6027
Tree: http://git-wip-us.apache.org/repos/asf/tapestry-5/tree/714a6027
Diff: http://git-wip-us.apache.org/repos/asf/tapestry-5/diff/714a6027

Branch: refs/heads/master
Commit: 714a6027fd38bee6b93cb37370585c2be54bd732
Parents: 5dbc372
Author: Howard M. Lewis Ship 
Authored: Thu Jul 25 12:23:00 2013 -0700
Committer: Howard M. Lewis Ship 
Committed: Thu Jul 25 12:23:00 2013 -0700

--
 .../org/apache/tapestry5/annotations/Parameter.java   | 14 --
 1 file changed, 8 insertions(+), 6 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/tapestry-5/blob/714a6027/tapestry-core/src/main/java/org/apache/tapestry5/annotations/Parameter.java
--
diff --git 
a/tapestry-core/src/main/java/org/apache/tapestry5/annotations/Parameter.java 
b/tapestry-core/src/main/java/org/apache/tapestry5/annotations/Parameter.java
index 6e769df..d0c9814 100644
--- 
a/tapestry-core/src/main/java/org/apache/tapestry5/annotations/Parameter.java
+++ 
b/tapestry-core/src/main/java/org/apache/tapestry5/annotations/Parameter.java
@@ -1,4 +1,4 @@
-// Copyright 2006, 2007, 2008, 2009 The Apache Software Foundation
+// Copyright 2006-2013 The Apache Software Foundation
 //
 // Licensed under the Apache License, Version 2.0 (the "License");
 // you may not use this file except in compliance with the License.
@@ -18,12 +18,13 @@ import org.apache.tapestry5.BindingConstants;
 import org.apache.tapestry5.ioc.annotations.UseWith;
 
 import java.lang.annotation.Documented;
-import static java.lang.annotation.ElementType.FIELD;
 import java.lang.annotation.Retention;
-import static java.lang.annotation.RetentionPolicy.RUNTIME;
 import java.lang.annotation.Target;
 
-import static org.apache.tapestry5.ioc.annotations.AnnotationUseContext.*;
+import static java.lang.annotation.ElementType.FIELD;
+import static java.lang.annotation.RetentionPolicy.RUNTIME;
+import static 
org.apache.tapestry5.ioc.annotations.AnnotationUseContext.COMPONENT;
+import static org.apache.tapestry5.ioc.annotations.AnnotationUseContext.MIXIN;
 
 /**
  * Annotation placed on a field to indicate that it is, in fact, a component 
parameter. Parameters may be optional or
@@ -64,8 +65,9 @@ public @interface Parameter
 boolean cache() default true;
 
 /**
- * The default value for the parameter if not bound (and not the empty 
string). This is a binding expression,
- * typically the name of a property of the component to bind.
+ * The default value for the parameter if not bound. This is a binding 
expression,
+ * typically the name of a property of the component to bind. The default 
value for this attribute
+ * is the empty string, indicating that there is no default default 
binding.
  */
 String value() default "";
 



[jira] [Commented] (TAP5-1668) Unexpected behaviour setting default of String parameter to ""

2013-07-25 Thread Howard M. Lewis Ship (JIRA)

[ 
https://issues.apache.org/jira/browse/TAP5-1668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13719927#comment-13719927
 ] 

Howard M. Lewis Ship commented on TAP5-1668:


Case 1: tab is null
Case 2: tab is null, because the empty string is used as a placeholder for "no 
default value".
Case 3: tab is the empty string.

I think this is as expected.


> Unexpected behaviour setting default of String parameter to "" 
> ---
>
> Key: TAP5-1668
> URL: https://issues.apache.org/jira/browse/TAP5-1668
> Project: Tapestry 5
>  Issue Type: Bug
>Affects Versions: 5.2
>Reporter: Geoff Callender
>Priority: Minor
>
> After reading the Parameter javadoc I expected these 3 to be equivalent.
>   @Parameter
>   private String tab;
>   @Parameter(value = "")
>   private String tab;
>   @Parameter
>   private String tab = "";
> but they are not: if the parameter is not bound, then in the first two its 
> value will be null, and in the third one it will be "".
> The javadoc is 
> http://tapestry.apache.org/tapestry5.2-dev/apidocs/org/apache/tapestry5/annotations/Parameter.html
>  .
> Is the behaviour wrong or does the javadoc need to be clearer?

--
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-1668) JavaDoc for @Parameter.value() should be clearer about the empty string

2013-07-25 Thread Howard M. Lewis Ship (JIRA)

 [ 
https://issues.apache.org/jira/browse/TAP5-1668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Howard M. Lewis Ship updated TAP5-1668:
---

Summary: JavaDoc for @Parameter.value() should be clearer about the empty 
string  (was: Unexpected behaviour setting default of String parameter to "" )

> JavaDoc for @Parameter.value() should be clearer about the empty string
> ---
>
> Key: TAP5-1668
> URL: https://issues.apache.org/jira/browse/TAP5-1668
> Project: Tapestry 5
>  Issue Type: Bug
>Affects Versions: 5.2
>Reporter: Geoff Callender
>Priority: Minor
>
> After reading the Parameter javadoc I expected these 3 to be equivalent.
>   @Parameter
>   private String tab;
>   @Parameter(value = "")
>   private String tab;
>   @Parameter
>   private String tab = "";
> but they are not: if the parameter is not bound, then in the first two its 
> value will be null, and in the third one it will be "".
> The javadoc is 
> http://tapestry.apache.org/tapestry5.2-dev/apidocs/org/apache/tapestry5/annotations/Parameter.html
>  .
> Is the behaviour wrong or does the javadoc need to be clearer?

--
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

2013-07-25 Thread Howard M. Lewis Ship (JIRA)

[ 
https://issues.apache.org/jira/browse/TAP5-1730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13719924#comment-13719924
 ] 

Howard M. Lewis Ship commented on TAP5-1730:


Could you verify if this is still an issue in 5.4?

> 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] [Assigned] (TAP5-1672) Propertydisplay swallows NPEs

2013-07-25 Thread Howard M. Lewis Ship (JIRA)

 [ 
https://issues.apache.org/jira/browse/TAP5-1672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Howard M. Lewis Ship reassigned TAP5-1672:
--

Assignee: Howard M. Lewis Ship

> Propertydisplay swallows NPEs
> -
>
> Key: TAP5-1672
> URL: https://issues.apache.org/jira/browse/TAP5-1672
> Project: Tapestry 5
>  Issue Type: Bug
>  Components: tapestry-core
>Affects Versions: 5.2
>Reporter: Wulf Wechsung
>Assignee: Howard M. Lewis Ship
>Priority: Minor
>  Labels: NPE, propertydisplay
>
> Situation:
> A property (prop) on an object is realized by a getter (ie getProp()). The 
> getter throws a NullPointerException on invokation. 
> Observed Behavior:
> Trying to display the property, the propertydisplay component reports an 
> error "Property 'currentlyOverdue' contains a null value in the path." 
> without any trace of the underlying NPE.
> Expected Behavior:
> The error report should include the stack-trace off the NPE and the error 
> message could also be a bit clearer.
> It's possible that propertydisplay also fails to report other exceptions that 
> occur in a getter.

--
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-1822) LinkSecurity should be public, not internal, as it is used with the public Link interface

2013-07-25 Thread Howard M. Lewis Ship (JIRA)

 [ 
https://issues.apache.org/jira/browse/TAP5-1822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Howard M. Lewis Ship closed TAP5-1822.
--

   Resolution: Fixed
Fix Version/s: 5.4
 Assignee: Howard M. Lewis Ship

> LinkSecurity should be public, not internal, as it is used with the public 
> Link interface
> -
>
> Key: TAP5-1822
> URL: https://issues.apache.org/jira/browse/TAP5-1822
> Project: Tapestry 5
>  Issue Type: Bug
>  Components: tapestry-core
>Affects Versions: 5.3.1
>Reporter: Mihail Slobodyanuk
>Assignee: Howard M. Lewis Ship
>Priority: Minor
>  Labels: api
> Fix For: 5.4
>
>
> Public API org.apache.tapestry5.Link use internal 
> org.apache.tapestry5.internal.services.LinkSecurity import in member method's 
> prototype

--
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


git commit: TAP5-1822: LinkSecurity should be public, not internal, as it is used with the public Link interface

2013-07-25 Thread hlship
Updated Branches:
  refs/heads/master c4b93e11f -> 5dbc37202


TAP5-1822: LinkSecurity should be public, not internal, as it is used with the 
public Link interface


Project: http://git-wip-us.apache.org/repos/asf/tapestry-5/repo
Commit: http://git-wip-us.apache.org/repos/asf/tapestry-5/commit/5dbc3720
Tree: http://git-wip-us.apache.org/repos/asf/tapestry-5/tree/5dbc3720
Diff: http://git-wip-us.apache.org/repos/asf/tapestry-5/diff/5dbc3720

Branch: refs/heads/master
Commit: 5dbc37202ab56c0a150e7c693b9f9694f21b023c
Parents: c4b93e1
Author: Howard M. Lewis Ship 
Authored: Thu Jul 25 12:15:37 2013 -0700
Committer: Howard M. Lewis Ship 
Committed: Thu Jul 25 12:15:37 2013 -0700

--
 54_RELEASE_NOTES.txt|  6 ++
 .../main/java/org/apache/tapestry5/Link.java|  4 +-
 .../java/org/apache/tapestry5/LinkSecurity.java | 61 +++
 .../tapestry5/internal/services/LinkImpl.java   |  3 +-
 .../internal/services/LinkSecurity.java | 63 
 .../services/RequestSecurityManager.java|  3 +-
 .../services/RequestSecurityManagerImpl.java|  3 +-
 .../ComponentEventLinkEncoderImplTest.java  |  3 +-
 .../internal/services/LinkImplTest.java |  3 +-
 .../RequestSecurityManagerImplTest.java |  3 +-
 10 files changed, 82 insertions(+), 70 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/tapestry-5/blob/5dbc3720/54_RELEASE_NOTES.txt
--
diff --git a/54_RELEASE_NOTES.txt b/54_RELEASE_NOTES.txt
index e6eac18..6255469 100644
--- a/54_RELEASE_NOTES.txt
+++ b/54_RELEASE_NOTES.txt
@@ -246,6 +246,12 @@ until the end of the request. A new configuration symbol 
can be used to turn thi
 
 The interface for AssetPathConstructor was changed incompatibly, to allow for 
individual asset checksums.
 
+## Link and LinkSecurity
+
+The enum type LinkSecurity was an internal class in 5.3 despite being used in 
methods of the public Link interface.
+It has been moved to package org.apache.tapestry5; this represents a minor 
incompatible change to the Link interface
+(which is rarely, if ever, implemented outside of the framework).
+
 ## StreamableResource Extended
 
 StreamableResource has been modified, adding a new `getChecksum()` method; 
this interface is rarely, if ever,

http://git-wip-us.apache.org/repos/asf/tapestry-5/blob/5dbc3720/tapestry-core/src/main/java/org/apache/tapestry5/Link.java
--
diff --git a/tapestry-core/src/main/java/org/apache/tapestry5/Link.java 
b/tapestry-core/src/main/java/org/apache/tapestry5/Link.java
index 9596335..f61475c 100644
--- a/tapestry-core/src/main/java/org/apache/tapestry5/Link.java
+++ b/tapestry-core/src/main/java/org/apache/tapestry5/Link.java
@@ -15,7 +15,7 @@
 package org.apache.tapestry5;
 
 import org.apache.commons.codec.net.URLCodec;
-import org.apache.tapestry5.internal.services.LinkSecurity;
+import org.apache.tapestry5.ioc.annotations.IncompatibleChange;
 import org.apache.tapestry5.services.BaseURLSource;
 import org.apache.tapestry5.services.ContextPathEncoder;
 import org.apache.tapestry5.services.Request;
@@ -152,6 +152,7 @@ public interface Link
  * @param newSecurity new security value, not null, typically {@link 
LinkSecurity#FORCE_SECURE} or {@link LinkSecurity#FORCE_INSECURE}
  * @since 5.3
  */
+@IncompatibleChange(release = "5.4", details = "LinkSecurity class moved 
from internal package to org.apache.tapestry5.")
 void setSecurity(LinkSecurity newSecurity);
 
 /**
@@ -159,6 +160,7 @@ public interface Link
  *
  * @since 5.3
  */
+@IncompatibleChange(release = "5.4", details = "LinkSecurity class moved 
from internal package to org.apache.tapestry5.")
 LinkSecurity getSecurity();
 
 /**

http://git-wip-us.apache.org/repos/asf/tapestry-5/blob/5dbc3720/tapestry-core/src/main/java/org/apache/tapestry5/LinkSecurity.java
--
diff --git a/tapestry-core/src/main/java/org/apache/tapestry5/LinkSecurity.java 
b/tapestry-core/src/main/java/org/apache/tapestry5/LinkSecurity.java
new file mode 100644
index 000..34ff445
--- /dev/null
+++ b/tapestry-core/src/main/java/org/apache/tapestry5/LinkSecurity.java
@@ -0,0 +1,61 @@
+// Copyright 2010-2013 The Apache Software Foundation
+//
+// Licensed under the Apache License, Version 2.0 (the "License");
+// you may not use this file except in compliance with the License.
+// You may obtain a copy of the License at
+//
+// http://www.apache.org/licenses/LICENSE-2.0
+//
+// Unless required by applicable law or agreed to in writing, software
+// distributed under the License is distributed on an "AS IS" BASIS,
+// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either expre

[jira] [Updated] (TAP5-1822) LinkSecurity should be public, not internal, as it is used with the public Link interface

2013-07-25 Thread Howard M. Lewis Ship (JIRA)

 [ 
https://issues.apache.org/jira/browse/TAP5-1822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Howard M. Lewis Ship updated TAP5-1822:
---

Summary: LinkSecurity should be public, not internal, as it is used with 
the public Link interface  (was: Export internal declaration)

> LinkSecurity should be public, not internal, as it is used with the public 
> Link interface
> -
>
> Key: TAP5-1822
> URL: https://issues.apache.org/jira/browse/TAP5-1822
> Project: Tapestry 5
>  Issue Type: Bug
>  Components: tapestry-core
>Affects Versions: 5.3.1
>Reporter: Mihail Slobodyanuk
>Priority: Minor
>  Labels: api
>
> Public API org.apache.tapestry5.Link use internal 
> org.apache.tapestry5.internal.services.LinkSecurity import in member method's 
> prototype

--
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-1917) BeanEditForm/BeanEditor doesn't do the InformalParameter dance - from the mailing list

2013-07-25 Thread Howard M. Lewis Ship (JIRA)

 [ 
https://issues.apache.org/jira/browse/TAP5-1917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Howard M. Lewis Ship closed TAP5-1917.
--

Resolution: Won't Fix
  Assignee: Howard M. Lewis Ship

There isn't a good way to handle this; informal parameters to BeanEditForm (and 
BeanEditor) are used to supply override blocks for property editors.

> BeanEditForm/BeanEditor doesn't do the InformalParameter dance - from the 
> mailing list
> --
>
> Key: TAP5-1917
> URL: https://issues.apache.org/jira/browse/TAP5-1917
> Project: Tapestry 5
>  Issue Type: Bug
>  Components: tapestry-core
>Affects Versions: 5.3.2, 5.3.3
>Reporter: Chris Mylonas
>Assignee: Howard M. Lewis Ship
>Priority: Minor
>  Labels: parameters
>
>  submitlabel="message:create-button"/>
> Does not render donkey (or class="donkey").
> It does render once the t:mixins="renderInformals" is added.
> Some comment from Lance:
> It seems that the beanEditForm needs a one-liner added to it
> ComponentResources.renderInformals(writer)
> &
> It seems that BeanEditor has the same bug. Pls put that in the Jira too
> Might be an idea to search all components with @SupportsInformalParameters
> that don't call renderInformalParameters to find any others

--
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


  1   2   >