[jira] [Commented] (TAP5-1565) It should be easier to make a series of contributions to an OrderedConfiguration so that the contributions are in sequential orderer
[
https://issues.apache.org/jira/browse/TAP5-1565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13068646#comment-13068646
]
Hudson commented on TAP5-1565:
--
Integrated in tapestry-trunk-freestyle #425 (See
[https://builds.apache.org/job/tapestry-trunk-freestyle/425/])
TAP5-1565: OrderedConfiguration should have methods to make it easy to add
elements in sequential order
hlship : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1148905
Files :
*
/tapestry/tapestry5/trunk/tapestry-ioc/src/main/java/org/apache/tapestry5/ioc/internal/ValidatingOrderedConfigurationWrapper.java
*
/tapestry/tapestry5/trunk/tapestry-ioc/src/test/java/org/apache/tapestry5/ioc/FredModule.java
*
/tapestry/tapestry5/trunk/tapestry-ioc/src/test/java/org/apache/tapestry5/ioc/internal/ValidatingOrderedConfigurationWrapperTest.java
*
/tapestry/tapestry5/trunk/tapestry-ioc/src/main/java/org/apache/tapestry5/ioc/internal/RegistryImpl.java
*
/tapestry/tapestry5/trunk/tapestry-ioc/src/main/java/org/apache/tapestry5/ioc/OrderedConfiguration.java
> It should be easier to make a series of contributions to an
> OrderedConfiguration so that the contributions are in sequential orderer
>
>
> Key: TAP5-1565
> URL: https://issues.apache.org/jira/browse/TAP5-1565
> Project: Tapestry 5
> Issue Type: Improvement
> Components: tapestry-ioc
>Affects Versions: 5.3
>Reporter: Howard M. Lewis Ship
>Assignee: Howard M. Lewis Ship
>Priority: Minor
> Fix For: 5.3
>
>
> It is not uncommon to have a series of elements to add to an
> OrderedConfiguration in a specific order; it would be nice if there was a way
> to add sequential items without manually tracking each nodes name and adding
> "after:" clauses.
> Example:
> configuration.add("item1", new Item1());
> configuration.addSequential("item2", new Item2());
> configuration.addInstanceSequential("item3", Item3.class);
> This would simply add an "after:item1" ordering constraint for item2, and an
> "after:item3" constraint for item3.
> It should be legal to add an item sequentially, even if there is no
> previously added item (added in this contribution method, or elsewhere), in
> which case, no ordering constraint it added.
> Would "next" and "nextInstance" be better than "addSequential" and
> "addInstanceSequential"? I'm open to other suggestions on the naming.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (TAP5-1565) It should be easier to make a series of contributions to an OrderedConfiguration so that the contributions are in sequential orderer
[
https://issues.apache.org/jira/browse/TAP5-1565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Howard M. Lewis Ship closed TAP5-1565.
--
Resolution: Fixed
> It should be easier to make a series of contributions to an
> OrderedConfiguration so that the contributions are in sequential orderer
>
>
> Key: TAP5-1565
> URL: https://issues.apache.org/jira/browse/TAP5-1565
> Project: Tapestry 5
> Issue Type: Improvement
> Components: tapestry-ioc
>Affects Versions: 5.3
>Reporter: Howard M. Lewis Ship
>Assignee: Howard M. Lewis Ship
>Priority: Minor
> Fix For: 5.3
>
>
> It is not uncommon to have a series of elements to add to an
> OrderedConfiguration in a specific order; it would be nice if there was a way
> to add sequential items without manually tracking each nodes name and adding
> "after:" clauses.
> Example:
> configuration.add("item1", new Item1());
> configuration.addSequential("item2", new Item2());
> configuration.addInstanceSequential("item3", Item3.class);
> This would simply add an "after:item1" ordering constraint for item2, and an
> "after:item3" constraint for item3.
> It should be legal to add an item sequentially, even if there is no
> previously added item (added in this contribution method, or elsewhere), in
> which case, no ordering constraint it added.
> Would "next" and "nextInstance" be better than "addSequential" and
> "addInstanceSequential"? I'm open to other suggestions on the naming.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TAP5-1565) It should be easier to make a series of contributions to an OrderedConfiguration so that the contributions are in sequential orderer
[
https://issues.apache.org/jira/browse/TAP5-1565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Howard M. Lewis Ship updated TAP5-1565:
---
Summary: It should be easier to make a series of contributions to an
OrderedConfiguration so that the contributions are in sequential orderer (was:
OrderedConfiguration should have methods to make it easy to add elements in
sequential order)
Also, I've updated the wiki.
> It should be easier to make a series of contributions to an
> OrderedConfiguration so that the contributions are in sequential orderer
>
>
> Key: TAP5-1565
> URL: https://issues.apache.org/jira/browse/TAP5-1565
> Project: Tapestry 5
> Issue Type: Improvement
> Components: tapestry-ioc
>Affects Versions: 5.3
>Reporter: Howard M. Lewis Ship
>Assignee: Howard M. Lewis Ship
>Priority: Minor
> Fix For: 5.3
>
>
> It is not uncommon to have a series of elements to add to an
> OrderedConfiguration in a specific order; it would be nice if there was a way
> to add sequential items without manually tracking each nodes name and adding
> "after:" clauses.
> Example:
> configuration.add("item1", new Item1());
> configuration.addSequential("item2", new Item2());
> configuration.addInstanceSequential("item3", Item3.class);
> This would simply add an "after:item1" ordering constraint for item2, and an
> "after:item3" constraint for item3.
> It should be legal to add an item sequentially, even if there is no
> previously added item (added in this contribution method, or elsewhere), in
> which case, no ordering constraint it added.
> Would "next" and "nextInstance" be better than "addSequential" and
> "addInstanceSequential"? I'm open to other suggestions on the naming.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Reopened] (TAP5-1565) OrderedConfiguration should have methods to make it easy to add elements in sequential order
[
https://issues.apache.org/jira/browse/TAP5-1565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Howard M. Lewis Ship reopened TAP5-1565:
> OrderedConfiguration should have methods to make it easy to add elements in
> sequential order
>
>
> Key: TAP5-1565
> URL: https://issues.apache.org/jira/browse/TAP5-1565
> Project: Tapestry 5
> Issue Type: Improvement
> Components: tapestry-ioc
>Affects Versions: 5.3
>Reporter: Howard M. Lewis Ship
>Assignee: Howard M. Lewis Ship
>Priority: Minor
> Fix For: 5.3
>
>
> It is not uncommon to have a series of elements to add to an
> OrderedConfiguration in a specific order; it would be nice if there was a way
> to add sequential items without manually tracking each nodes name and adding
> "after:" clauses.
> Example:
> configuration.add("item1", new Item1());
> configuration.addSequential("item2", new Item2());
> configuration.addInstanceSequential("item3", Item3.class);
> This would simply add an "after:item1" ordering constraint for item2, and an
> "after:item3" constraint for item3.
> It should be legal to add an item sequentially, even if there is no
> previously added item (added in this contribution method, or elsewhere), in
> which case, no ordering constraint it added.
> Would "next" and "nextInstance" be better than "addSequential" and
> "addInstanceSequential"? I'm open to other suggestions on the naming.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[CONF] Apache Tapestry > Tapestry IoC Configuration
Tapestry IoC Configuration
Page edited by Howard M. Lewis Ship
Comment:
ordere configurations implicit constraint
Changes (1)
...
Null values, once ordered, are edited out (the List passed to the service builder method does not include any nulls). Again, they are allowed as placeholders, for the actual contributed objects to organize themselves around.
{since:since=5.3} When using {{add()}} without any specific contraints, a default contraint is added: after the previously added element. These default constraints are only within a single contribution method, but makes it much easier to set the order of several related contributions. Note that the contributions will be ordered relative to each other and its possible that contributions by some other module or method may be interspersed between them. {since}
h2. Mapped Configurations
...
Full Content
Tapestry IoC Decorators IoC Case Insensitivity
Tapestry IoC Configuration
Related Articles
Page:
IoC cookbook - Service Configurations
Page:
Tapestry IoC Configuration
Page:
Symbols
Page:
Response Compression
Page:
Configuration
Page:
Application Module Class Cheat Sheet
Tapestry services – both those provided by Tapestry and those you write yourself – are configured using Java, not XML.
One of the key concepts in Tapestry IoC is distributed configuration. The distributed part refers to the fact that any module may configure a service. Distributed configuration is the key feature of Tapestry IoC that supports extensibility and modularity.
Modules configure a service by contributing to service configurations. This seems esoteric, but is quite handy, and is best explained by an example.
Let's say you've written a bunch of different services, each of which does something specific for a particular type of file (identified by the file's extension), and each implements the same interface, which we'll call FileServicer. And now let's say you need a central service that selects the one of your FileServicer implementations based on a given file extension. You start by providing a service builder method:
public static FileServiceDispatcher buildFileServicerDispatcher(Map contributions)
{
return new FileServiceDispatcherImpl(contributions);
}
In order to provide a value for the contribution parameter, Tapestry will collect contributions from service contribution methods. It will ensure that the keys and values match the generic types shown (String for the key, FileServicer for the value). The map will be assembled and passed into the service builder method, and from there, into the FileServiceDispatcherImpl constructor.
So where do the values come from? Your service contributor methods, methods whose names start with "contribute":
public static void contributeFileServicerDispatcher(MappedConfiguration configuration)
{
configuration.add("txt", new TextFileServicer());
configuration.add("pdf", new PDFFileServicer());
}
Or, instead of instantiating those services ourselves, we could inject them:
public static void contributeFileServicerDispatcher(MappedConfiguration configuration,
@InjectService("TextFileServicer") FileServicer textFileServicer,
@InjectService("PDFFileServicer") FileServicer pdfFileServicer)
{
configuration.add("txt", textFileServicer);
configuration.add("pdf", pdfFileServicer);
}
The extensibility comes from the fact that multiple modules may all contribute to the same service configuration:
public static void contributeFileServicerDispatcher(MappedConfiguration configuration)
{
configuration.add("doc", new WordFileServicer());
configuration.add("ppt", new PowerP
[jira] [Closed] (TAP5-1565) OrderedConfiguration should have methods to make it easy to add elements in sequential order
[
https://issues.apache.org/jira/browse/TAP5-1565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Howard M. Lewis Ship closed TAP5-1565.
--
Resolution: Fixed
Fix Version/s: 5.3
> OrderedConfiguration should have methods to make it easy to add elements in
> sequential order
>
>
> Key: TAP5-1565
> URL: https://issues.apache.org/jira/browse/TAP5-1565
> Project: Tapestry 5
> Issue Type: Improvement
> Components: tapestry-ioc
>Affects Versions: 5.3
>Reporter: Howard M. Lewis Ship
>Assignee: Howard M. Lewis Ship
>Priority: Minor
> Fix For: 5.3
>
>
> It is not uncommon to have a series of elements to add to an
> OrderedConfiguration in a specific order; it would be nice if there was a way
> to add sequential items without manually tracking each nodes name and adding
> "after:" clauses.
> Example:
> configuration.add("item1", new Item1());
> configuration.addSequential("item2", new Item2());
> configuration.addInstanceSequential("item3", Item3.class);
> This would simply add an "after:item1" ordering constraint for item2, and an
> "after:item3" constraint for item3.
> It should be legal to add an item sequentially, even if there is no
> previously added item (added in this contribution method, or elsewhere), in
> which case, no ordering constraint it added.
> Would "next" and "nextInstance" be better than "addSequential" and
> "addInstanceSequential"? I'm open to other suggestions on the naming.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
svn commit: r1148905 - in /tapestry/tapestry5/trunk/tapestry-ioc/src: main/java/org/apache/tapestry5/ioc/ main/java/org/apache/tapestry5/ioc/internal/ test/java/org/apache/tapestry5/ioc/ test/java/org
Author: hlship
Date: Wed Jul 20 19:14:21 2011
New Revision: 1148905
URL: http://svn.apache.org/viewvc?rev=1148905&view=rev
Log:
TAP5-1565: OrderedConfiguration should have methods to make it easy to add
elements in sequential order
Modified:
tapestry/tapestry5/trunk/tapestry-ioc/src/main/java/org/apache/tapestry5/ioc/OrderedConfiguration.java
tapestry/tapestry5/trunk/tapestry-ioc/src/main/java/org/apache/tapestry5/ioc/internal/RegistryImpl.java
tapestry/tapestry5/trunk/tapestry-ioc/src/main/java/org/apache/tapestry5/ioc/internal/ValidatingOrderedConfigurationWrapper.java
tapestry/tapestry5/trunk/tapestry-ioc/src/test/java/org/apache/tapestry5/ioc/FredModule.java
tapestry/tapestry5/trunk/tapestry-ioc/src/test/java/org/apache/tapestry5/ioc/internal/ValidatingOrderedConfigurationWrapperTest.java
Modified:
tapestry/tapestry5/trunk/tapestry-ioc/src/main/java/org/apache/tapestry5/ioc/OrderedConfiguration.java
URL:
http://svn.apache.org/viewvc/tapestry/tapestry5/trunk/tapestry-ioc/src/main/java/org/apache/tapestry5/ioc/OrderedConfiguration.java?rev=1148905&r1=1148904&r2=1148905&view=diff
==
---
tapestry/tapestry5/trunk/tapestry-ioc/src/main/java/org/apache/tapestry5/ioc/OrderedConfiguration.java
(original)
+++
tapestry/tapestry5/trunk/tapestry-ioc/src/main/java/org/apache/tapestry5/ioc/OrderedConfiguration.java
Wed Jul 20 19:14:21 2011
@@ -1,4 +1,4 @@
-// Copyright 2006, 2008, 2009, 2010 The Apache Software Foundation
+// Copyright 2006, 2008, 2009, 2010, 2011 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.
@@ -26,7 +26,10 @@ package org.apache.tapestry5.ioc;
*
*
* The service defines the type of contribution, in terms of a base
class or service interface. Contributions
- * must be compatible with the type.
+ * must be compatible with the type, or be {@linkplain
org.apache.tapestry5.ioc.services.TypeCoercer coercable} to the type.
+ *
+ * @see org.apache.tapestry5.ioc.annotations.Contribute
+ * @see org.apache.tapestry5.ioc.annotations.UsesConfiguration
*/
public interface OrderedConfiguration
{
@@ -34,25 +37,23 @@ public interface OrderedConfiguration
* Adds an ordered object to a service's contribution. Each object has an
id (which must be unique). Optionally,
* pre-requisites (a list of ids that must precede this object) and
post-requisites (ids that must follow) can be
* provided.
- *
- * @param id
- *a unique id for the object; the id will be fully qualified
with the contributing module's id
- * @param constraints
- *used to order the object relative to other contributed
objects
- * @parm object to add to the service's configuration
+ *
+ * If no constraints are supplied, then an implicit constraint is
supplied: after the previously
+ * contributed id within the same contribution method.
+ *
+ * @param id a unique id for the object; the id will be fully
qualified with the contributing module's id
+ * @param constraints used to order the object relative to other
contributed objects
+ * @param object to add to the service's configuration
*/
void add(String id, T object, String... constraints);
/**
* Overrides a normally contributed object. Each override must match a
single normally contributed object.
- *
- * @param id
- *identifies object to override
- * @param object
- *overriding object (may be null)
- * @param constraints
- *contrains for the overridden object, replacing constraints
for the original object (even if
- *omitted, in which case the override object will have no
orderring contraints)
+ *
+ * @param id identifies object to override
+ * @param object overriding object (may be null)
+ * @param constraints constraints for the overridden object, replacing
constraints for the original object (even if
+ *omitted, in which case the override object will have
no ordering constraints)
* @since 5.1.0.0
*/
void override(String id, T object, String... constraints);
@@ -61,28 +62,22 @@ public interface OrderedConfiguration
* Adds an ordered object by instantiating (with dependencies) the
indicated class. When the configuration type is
* an interface and the class to be contributed is a local file,
* then a reloadable proxy for the class will be created and contributed.
- *
- * @param id
- *of contribution (used for ordering)
- * @param clazz
- *class to instantiate
- * @param constraints
- *used to order the object relative to other contributed
objects
+ *
+ * @param id of
[CONF] Apache Tapestry > Release Notes 5.3
Release Notes 5.3
Page edited by Howard M. Lewis Ship
Comment:
implicit ordered configuration constraints
Changes (1)
...
Form components now recognize when the client-side form was cancelled. A new "cancelled" event is triggered early in the submission process, which allows the page to bypass all property updates and input validations, when desired.
h3. Implicit OrderedConfiguration Constraints When using {{OrderedConfiguration.add()}} with no constraints, Tapestry will now implicitly order the added element after the previously added element, within the same method. In prior releases, such elements were added with no constraints. This makes it easier to contribute a group of related items with an implicit ordering.
h2. Removed Functionality
...
Full Content
Release Notes 5.2 Release Notes
This is the consolidated list of changes between Tapestry versions 5.2 and 5.3. To upgrade from 5.1 to 5.2, most users will be able to just update the Maven dependency in their POM file (or download the new JAR file) and the new version will just work. However, please read carefully below before upgrading.
Contents
Breaking Changes
New Features
Removed Functionality
Release Notes: Tapestry 5.3.0
Sub-task
Bug
Improvement
New Feature
Task
Test
Breaking Changes
Some number of interfaces and APIs in Tapestry 5.3 will be removed in Tapestry 5.4 or later. These include:
The "suppress redirects" functionality, which allows component event requests to respond directly with HTML, as in Tapestry 4
The RenderSupport environmental (replaced with the _javascript_Support environmental)
ClassFactory service and ClassFab interface (replaced with the PlasticProxyFactory service and PlasticClass interface)
Many classes and interfaces marked as deprecated in prior releases of Tapestry have been removed.
Because of the upgrade to Prototype 1.7, existing _javascript_ that uses value.toJSON() may break; replace with Object.toJSON(value).
New Features
Rendering comments
It is now possible to have Tapestry emit rendering comments; these are comments (such as ) that can assist you in debugging markup output on the client-side. This is enabled for all requests using the configuration symbol tapestry.component-render-tracing-enabled, and can be added to any request by adding the query parameter t:component-trace=true to the URL. This will significantly increase the size of the rendered markup, but can be very helpful with complex layouts to determine which component was responsible for which portion of the rendered page.
Adaptable service contributions
When making contributions to a service, you are no longer restricted to contributing a value that is assignable to the type associated with the configuration; objects of any type may be contributed, and the TypeCoercer service is used to coerce the value to the configuration's type.
Component debugging improvements
Because of how Tapestry instruments your pages and components, it has been difficult to debug Tapestry applications; any mutable field shows its default value in the debugger, regardless of what has been written to the field or read out of it. In Tapestry 5.3, when in development mode, Tapestry now shadows values read from or written to such fields into the fields themselves (this has also been fixed in the 5.2.5 maintenance release). This does not occur in production, to avoid potential memory leaks.
Reloading disabled in production
Tapestry no longer checks for changes to Tapestry component class files, templates, or message catalogs in production mode. It is assumed that Tapestry applications are packaged as WAR files in production, and that changing the WAR file causes the servlet container to redeploy the entire application. This change is to improve throughput and reduce memory consumption in production applications.
String-to-Enum coercions
The TypeCoercer service now automatically generates String-to-Enum coercions without requiring a specific contribution. This coercion is case insensitive. A contribution is still allowed, and will take priority over the default coercion, but is only necessary to support "aliases" for enum values outside those defined by the enum type itself.
_javascript_ and CSS minimization
A new optional library, tapestry-yuicompressor, has been added. This library adds support for compressing _javascript_ libraries and CSS files using the YUICompressor library
ComponentClassTransformWorker Service
The type of this service has changed from ComponentClassTransformWorker to ComponentClassTransformWorker2. Contributions of type ComponentClassTransformWorker will automatically be coerce
[jira] [Assigned] (TAP5-1565) OrderedConfiguration should have methods to make it easy to add elements in sequential order
[
https://issues.apache.org/jira/browse/TAP5-1565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Howard M. Lewis Ship reassigned TAP5-1565:
--
Assignee: Howard M. Lewis Ship
> OrderedConfiguration should have methods to make it easy to add elements in
> sequential order
>
>
> Key: TAP5-1565
> URL: https://issues.apache.org/jira/browse/TAP5-1565
> Project: Tapestry 5
> Issue Type: Improvement
> Components: tapestry-ioc
>Affects Versions: 5.3
>Reporter: Howard M. Lewis Ship
>Assignee: Howard M. Lewis Ship
>Priority: Minor
>
> It is not uncommon to have a series of elements to add to an
> OrderedConfiguration in a specific order; it would be nice if there was a way
> to add sequential items without manually tracking each nodes name and adding
> "after:" clauses.
> Example:
> configuration.add("item1", new Item1());
> configuration.addSequential("item2", new Item2());
> configuration.addInstanceSequential("item3", Item3.class);
> This would simply add an "after:item1" ordering constraint for item2, and an
> "after:item3" constraint for item3.
> It should be legal to add an item sequentially, even if there is no
> previously added item (added in this contribution method, or elsewhere), in
> which case, no ordering constraint it added.
> Would "next" and "nextInstance" be better than "addSequential" and
> "addInstanceSequential"? I'm open to other suggestions on the naming.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TAP5-1532) MarkupWriterImpl listeners improvement
[ https://issues.apache.org/jira/browse/TAP5-1532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Stepanov resolved TAP5-1532. -- Resolution: Duplicate Already fixed by TAP5-1581 > MarkupWriterImpl listeners improvement > -- > > Key: TAP5-1532 > URL: https://issues.apache.org/jira/browse/TAP5-1532 > Project: Tapestry 5 > Issue Type: Improvement > Components: tapestry-core >Reporter: Denis Stepanov >Priority: Minor > Attachments: 0001-MarkupWriterImpl-improvement.patch > > > New listeners collection is created every start/end element event, probably > to prevent CME, better solution is to create new collection when modifying it -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TAP5-1583) AddRowLink and RemoveRowLink components should implement ClientElement
[ https://issues.apache.org/jira/browse/TAP5-1583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Kemnade updated TAP5-1583: - Attachment: 0001-have-AddRowLink-and-RemoveRowLink-implement-ClientEl.patch patch against maint-5-2 > AddRowLink and RemoveRowLink components should implement ClientElement > -- > > Key: TAP5-1583 > URL: https://issues.apache.org/jira/browse/TAP5-1583 > Project: Tapestry 5 > Issue Type: Wish > Components: tapestry-core >Affects Versions: 5.3, 5.2.6 >Reporter: Jochen Kemnade > Labels: patch > Attachments: > 0001-have-AddRowLink-and-RemoveRowLink-implement-ClientEl.patch > > > To be able to query the client ids of AddRowLink and RemoveRowLink, they > should implement ClientElement. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TAP5-1583) AddRowLink and RemoveRowLink components should implement ClientElement
AddRowLink and RemoveRowLink components should implement ClientElement -- Key: TAP5-1583 URL: https://issues.apache.org/jira/browse/TAP5-1583 Project: Tapestry 5 Issue Type: Wish Components: tapestry-core Affects Versions: 5.3, 5.2.6 Reporter: Jochen Kemnade Attachments: 0001-have-AddRowLink-and-RemoveRowLink-implement-ClientEl.patch To be able to query the client ids of AddRowLink and RemoveRowLink, they should implement ClientElement. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
