[jira] Created: (TAP5-648) Tapestry ignores the order in which user gives the META tags

2009-04-16 Thread Ville Virtanen (JIRA)
Tapestry ignores the order in which user gives the META tags


 Key: TAP5-648
 URL: https://issues.apache.org/jira/browse/TAP5-648
 Project: Tapestry 5
  Issue Type: Bug
  Components: tapestry-core
Affects Versions: 5.1.0.3
Reporter: Ville Virtanen


As Microsoft documentation states 
(http://msdn.microsoft.com/en-us/library/cc817574.aspx) the META tags that 
direct IE8 must be positioned as follows: The X-UA-compatible header is not 
case sensitive; however, it must appear in the Web page's header (the HEAD 
section) before all other elements, except for the TITLE element and other META 
elements..

The most flexible solution would be to honor the order of META and other tags 
that author has put directly to the template: the place for T5 tags could be 
indicated with special tag:

For an example 
html
  head
 titleMy Web Page/title
  meta http-equiv=X-UA-Compatible content=IE=EmulateIE7 /
  t:headcontent /
  link href=dirlang.html rel=next/
  /head
  .
  .

If author decides to omit the t:headcontent tag then T5 would not attach any 
meta or link tags.

Other solution as Howard indicated in the mailing list would be to just add the 
T5 specific stuff to the end of the head section. 
 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Closed: (TAP5-593) Calling ApplicationStateManager.exists() will throw an exception when the session has been invalidated

2009-04-16 Thread Joachim Van der Auwera (JIRA)

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

Joachim Van der Auwera closed TAP5-593.
---

Resolution: Fixed

 Calling ApplicationStateManager.exists() will throw an exception when the 
 session has been invalidated
 --

 Key: TAP5-593
 URL: https://issues.apache.org/jira/browse/TAP5-593
 Project: Tapestry 5
  Issue Type: Bug
Affects Versions: 5.1.0.1
Reporter: Joachim Van der Auwera
Assignee: Howard M. Lewis Ship
 Fix For: 5.1.0.2




-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (TAP5-593) Calling ApplicationStateManager.exists() will throw an exception when the session has been invalidated

2009-04-16 Thread Joachim Van der Auwera (JIRA)

[ 
https://issues.apache.org/jira/browse/TAP5-593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12699733#action_12699733
 ] 

Joachim Van der Auwera commented on TAP5-593:
-

re-testing using 5.1.0.3 this is indeed fixed

 Calling ApplicationStateManager.exists() will throw an exception when the 
 session has been invalidated
 --

 Key: TAP5-593
 URL: https://issues.apache.org/jira/browse/TAP5-593
 Project: Tapestry 5
  Issue Type: Bug
Affects Versions: 5.1.0.1
Reporter: Joachim Van der Auwera
Assignee: Howard M. Lewis Ship
 Fix For: 5.1.0.2




-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Created: (TAP5-649) Forms containing loop components which contain no form elements still encode into t:formdata hidden field

2009-04-16 Thread Andy Blower (JIRA)
Forms containing loop components which contain no form elements still encode 
into t:formdata hidden field
-

 Key: TAP5-649
 URL: https://issues.apache.org/jira/browse/TAP5-649
 Project: Tapestry 5
  Issue Type: Bug
  Components: tapestry-core
Affects Versions: 5.0.18, 5.1.0.3, 5.1.0.2, 5.1.0.1, 5.1.0.0
Reporter: Andy Blower


Updating our app to 5.1 has caused us an issue with using loop components 
nested inside form components, we now need to provide a ValueEncoder whereas we 
didn't in 5.0.18 which just serialised the loop values into t:formdata. In many 
cases we have loops that don't have any input or form elements inside them, but 
that still need to be contained by the form tag in the HTML. The issue is that 
the loop component has a 'volatile' parameter to switch off the state saving, 
but this expects the iterator to still be available when the form is submitted, 
which it isn't and doesn't need to be.

I think that the loop component needs the facility to be form agnostic, so that 
FormSupport (from the environment) is ignored / not set. My suggestion is that 
the volatile parameter is deprecated (can't remove for backwards compatability) 
and a new parameter 'formHandling' or 'formSupport' is added to the loop 
component which accepts three values: none, statesave, volatile. I think that 
this would be much clearer and concise than the current volatile boolean, which 
confuses everyone in my experience, but alternatively a new boolean for 
switching off form support would suffice.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (TAP5-649) Forms containing loop components which contain no form elements still encode into t:formdata hidden field

2009-04-16 Thread Andy Blower (JIRA)

[ 
https://issues.apache.org/jira/browse/TAP5-649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12699738#action_12699738
 ] 

Andy Blower commented on TAP5-649:
--

I should have mentioned that we have worked around this temporarily to prove 
that our theory was correct by creating and using a UselessEncoder class with 
relevant loops in forms. This encoder simply returns a blank string and cut 
down the t:formdata in one of our forms from 9076 bytes to a mere 832 bytes!

Since none of this extra information will ever be used, this shows how much of 
a wasteful overhead this can be. It would be especially bad for us because we  
log all activity on the website including posted form submissions. I'm glad 
that this exception was thrown by 5.1 and highlighted the issue.

 Forms containing loop components which contain no form elements still encode 
 into t:formdata hidden field
 -

 Key: TAP5-649
 URL: https://issues.apache.org/jira/browse/TAP5-649
 Project: Tapestry 5
  Issue Type: Bug
  Components: tapestry-core
Affects Versions: 5.1.0.0, 5.1.0.1, 5.1.0.2, 5.1.0.3, 5.0.18
Reporter: Andy Blower

 Updating our app to 5.1 has caused us an issue with using loop components 
 nested inside form components, we now need to provide a ValueEncoder whereas 
 we didn't in 5.0.18 which just serialised the loop values into t:formdata. In 
 many cases we have loops that don't have any input or form elements inside 
 them, but that still need to be contained by the form tag in the HTML. The 
 issue is that the loop component has a 'volatile' parameter to switch off the 
 state saving, but this expects the iterator to still be available when the 
 form is submitted, which it isn't and doesn't need to be.
 I think that the loop component needs the facility to be form agnostic, so 
 that FormSupport (from the environment) is ignored / not set. My suggestion 
 is that the volatile parameter is deprecated (can't remove for backwards 
 compatability) and a new parameter 'formHandling' or 'formSupport' is added 
 to the loop component which accepts three values: none, statesave, volatile. 
 I think that this would be much clearer and concise than the current volatile 
 boolean, which confuses everyone in my experience, but alternatively a new 
 boolean for switching off form support would suffice.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (TAP5-624) Support for javascript callbacks on zone update

2009-04-16 Thread Howard M. Lewis Ship (JIRA)

[ 
https://issues.apache.org/jira/browse/TAP5-624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12699767#action_12699767
 ] 

Howard M. Lewis Ship commented on TAP5-624:
---

Best way would be if Tapestry triggered an event on the Zone's div after the 
zone was updated. That would be easy.

 Support for javascript callbacks on zone update
 ---

 Key: TAP5-624
 URL: https://issues.apache.org/jira/browse/TAP5-624
 Project: Tapestry 5
  Issue Type: New Feature
  Components: tapestry-core
Reporter: Hugo Palma

 It would be great if it was possible to register some javascript to be 
 executed after a zone is updated.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Created: (TAP5-651) Documentation for if component needs expanding

2009-04-16 Thread Andy Blower (JIRA)
Documentation for if component needs expanding
--

 Key: TAP5-651
 URL: https://issues.apache.org/jira/browse/TAP5-651
 Project: Tapestry 5
  Issue Type: Improvement
  Components: documentation
Affects Versions: 5.1.0.4
Reporter: Andy Blower
Priority: Minor


Use of new p:else block in the example for the if component is confusing 
because there's nothing to draw an ex-5.0 developer to the addition in the 
container tag attributes for the parameter namespace definition. It would also 
be nice to explain the syntax for an else block without the new container tag 
attribute, if there actually is a way of course.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



svn commit: r765720 - in /tapestry/tapestry5/trunk/tapestry-core/src: main/java/org/apache/tapestry5/corelib/components/ main/resources/org/apache/tapestry5/ test/app1/nested/ test/java/org/apache/tap

2009-04-16 Thread hlship
Author: hlship
Date: Thu Apr 16 19:00:58 2009
New Revision: 765720

URL: http://svn.apache.org/viewvc?rev=765720view=rev
Log:
TAP5-624: Support for javascript callbacks on zone update

Added:

tapestry/tapestry5/trunk/tapestry-core/src/main/java/org/apache/tapestry5/corelib/components/Zone.xdoc
Modified:

tapestry/tapestry5/trunk/tapestry-core/src/main/java/org/apache/tapestry5/corelib/components/Zone.java

tapestry/tapestry5/trunk/tapestry-core/src/main/resources/org/apache/tapestry5/tapestry.js
tapestry/tapestry5/trunk/tapestry-core/src/test/app1/nested/ZoneDemo.tml

tapestry/tapestry5/trunk/tapestry-core/src/test/java/org/apache/tapestry5/integration/IntegrationTests.java

tapestry/tapestry5/trunk/tapestry-core/src/test/java/org/apache/tapestry5/integration/app1/pages/nested/ZoneDemo.java

Modified: 
tapestry/tapestry5/trunk/tapestry-core/src/main/java/org/apache/tapestry5/corelib/components/Zone.java
URL: 
http://svn.apache.org/viewvc/tapestry/tapestry5/trunk/tapestry-core/src/main/java/org/apache/tapestry5/corelib/components/Zone.java?rev=765720r1=765719r2=765720view=diff
==
--- 
tapestry/tapestry5/trunk/tapestry-core/src/main/java/org/apache/tapestry5/corelib/components/Zone.java
 (original)
+++ 
tapestry/tapestry5/trunk/tapestry-core/src/main/java/org/apache/tapestry5/corelib/components/Zone.java
 Thu Apr 16 19:00:58 2009
@@ -32,10 +32,15 @@
  * Often, Zones are initially invisible, in which case the visible parameter 
may be set to false (it defaults to true).
  * p/
  * When a user clicks an {...@link 
org.apache.tapestry5.corelib.components.ActionLink} whose zone parameter is 
set, the
- * corresponding client-side Tapestry.Zone object is located. It will update 
the content of the Zone's lt;divgt; and
- * then invoke either a show method (if the div is not visible) or an update 
method (if the div is visible).  The show
- * and update parameters are the emnames/em of functions attached to the 
Tapestry.ElementEffect object.Likewise,
- * a {...@link org.apache.tapestry5.corelib.components.Form} component may 
also trigger an update of a client-side Zone.
+ * corresponding client-side Tapestry.ZoneManager object is located. It will 
update the content of the Zone's
+ * lt;divgt; and then invoke either a show method (if the div is not 
visible) or an update method (if the div is
+ * visible).  The show and update parameters are the emnames/em of 
functions attached to the Tapestry.ElementEffect
+ * object.Likewise, a {...@link 
org.apache.tapestry5.corelib.components.Form} component may also trigger an 
update of a
+ * client-side Zone.
+ * p/
+ * The server side event handler can return a {...@link 
org.apache.tapestry5.Block} or a component to render as the new
+ * content on the client side. Often, re-rendering the Zone's {...@linkplain 
#getBody() body} is useful. Multiple
+ * client-side zones may be updated by returning a {...@link 
org.apache.tapestry5.ajax.MultiZoneUpdate}.
  * p/
  * Renders informal parameters, adding CSS class t-zone and possibly, 
t-invisible.
  * p/
@@ -46,6 +51,9 @@
  * of the page). Failure to provide an explicit id results in a new, and 
non-predictable, id being generated for each
  * partial render, which will often result in client-side failures to locate 
the element to update when the Zone is
  * triggered.
+ * p/
+ * After the client-side content is updated, a client-side event is fired on 
the zone's element. The constant
+ * Tapestry.ZONE_UPDATED_EVENT can be used to listen to the event.
  */
 @SupportsInformalParameters
 public class Zone implements ClientElement
@@ -77,7 +85,7 @@
  * is generated for the element.
  */
 @Parameter(name = id, defaultPrefix = BindingConstants.LITERAL)
-private String clientId;
+private String idParameter;
 
 @Environmental
 private RenderSupport renderSupport;
@@ -95,6 +103,8 @@
 @Inject
 private ComponentResources resources;
 
+private String clientId;
+
 String defaultElementName()
 {
 return resources.getElementName(div);
@@ -102,8 +112,7 @@
 
 void beginRender(MarkupWriter writer)
 {
-if (!resources.isBound(id))
-clientId = renderSupport.allocateClientId(resources);
+clientId = resources.isBound(id) ? idParameter : 
renderSupport.allocateClientId(resources);
 
 Element e = writer.element(elementName, id, clientId);
 
@@ -111,7 +120,7 @@
 
 e.addClassName(t-zone);
 
-if (!visible) e.addClassName(t-invisible);
+if (!visible) e.addClassName(CSSClassConstants.INVISIBLE);
 
 // And continue on to render the body
 
@@ -126,6 +135,12 @@
 writer.end(); // div
 }
 
+/**
+ * The client id of the Zone; this is set when the Zone renders and will 
either be the value bound to the id
+ * parameter, or an allocated unique id.
+ *
+ * @return client-side element id
+

[jira] Closed: (TAP5-624) Support for javascript callbacks on zone update

2009-04-16 Thread Howard M. Lewis Ship (JIRA)

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

Howard M. Lewis Ship closed TAP5-624.
-

   Resolution: Fixed
Fix Version/s: 5.1.0.4

 Support for javascript callbacks on zone update
 ---

 Key: TAP5-624
 URL: https://issues.apache.org/jira/browse/TAP5-624
 Project: Tapestry 5
  Issue Type: New Feature
  Components: tapestry-core
Reporter: Hugo Palma
Assignee: Howard M. Lewis Ship
 Fix For: 5.1.0.4


 It would be great if it was possible to register some javascript to be 
 executed after a zone is updated.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.