[jira] Commented: (TAP5-213) Create an easier way to populate List of object to Select component
[
https://issues.apache.org/jira/browse/TAP5-213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12671852#action_12671852
]
Thiago H. de Paula Figueiredo commented on TAP5-213:
Tapestry CRUD (http://www.arsmachina.com.br/project/tapestrycrud/concepts)
tackles this problem in a very different , more reusable way. It provides
SingleTypeSelectModelFactory, an interface that defines a factory of
SelectModel instances for a given type. It also provides SelectModelFactory, a
factory of SelectModel instances for any given type. This interface has two
methods: SelectModel create(Class? clasz) (all the instances of a given class
are included in the returned SelectModel) and T SelectModel create(ClassT
clasz, ListT objects) (just the provided instances. Tapestry CRUD provides
them without any configuration needed, as long as its conventions are followed.
Create an easier way to populate List of object to Select component
---
Key: TAP5-213
URL: https://issues.apache.org/jira/browse/TAP5-213
Project: Tapestry 5
Issue Type: Wish
Affects Versions: 5.0.15
Reporter: Joshua Partogi
Assignee: Kevin Menard
Create an easier way to populate List of object to Select component.
Currently we must create a class that implement SelectModel and a class that
implement ValueEncoder. Perhaps it would be nice if there property in the
Select component such as list that corresponds to the list of object to be
displayed for the combobox as such:
select t:type=Select t:id=member model=member list=members /
and the Page class as such:
private ListMember members;
public ListMember getMembers()
{
return members;
}
public void setMembers(ListMember members)
{
this.members = members;
}
@SetupRender
public void init(){
members = dao.getMembers();
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-108) ActionLink should be able to update several zones
[ https://issues.apache.org/jira/browse/TAP5-108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12672102#action_12672102 ] Thiago H. de Paula Figueiredo commented on TAP5-108: What if any event handler method that can return a Zone or Block could also receive a zone id, block or zone to render map? Not only ActionLink, but also EventLink, Form, etc. This would be very T5-ish (contrasted with T4's updateComponents) and could be implemented only changing Tapestry internal services, without breaking existing code. ActionLink should be able to update several zones - Key: TAP5-108 URL: https://issues.apache.org/jira/browse/TAP5-108 Project: Tapestry 5 Issue Type: Improvement Affects Versions: 5.0.15 Reporter: Igor Drobiazko Unfortunately the ActionLink's parameter zone expect a single zone. Commonly, we want to update several parts of the client. It would be very nice to be able to update a bunch of zones after an action was triggered. This limitation is quite frustrating for people coming from T4 because updateComponents expected a list of component ids. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TAP5-509) Create an AnnotationProvider pipeline
Create an AnnotationProvider pipeline - Key: TAP5-509 URL: https://issues.apache.org/jira/browse/TAP5-509 Project: Tapestry 5 Issue Type: Improvement Components: tapestry-ioc Affects Versions: 5.0.18 Reporter: Thiago H. de Paula Figueiredo Priority: Minor An AnnotationProvider pipeline would provide two very nice features: * The possibility of converting one annotation into another. This could easily allow for Tapestry-IoC recognize Spring or EJB or Guice dependency-injection annotations, for example. * The possibility to easily add annotations to classes, fields and methods that do not have them. Example: use of JPA and Hibernate Validator annotations to provide BeanEditor/BeanEditForm validation without using @Validate on the entity classes. Maybe we need an specialized validation pipeline, as JPA annotations (@Column(nullable= false), for example) would add one validation rule, but Hibernate Validator (@Email) would provide another validation rule, not overwriting the first one. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-552) Common compressed image files should be configured to not re-compress when sent to client: GIF, PNG
[ https://issues.apache.org/jira/browse/TAP5-552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12678878#action_12678878 ] Thiago H. de Paula Figueiredo commented on TAP5-552: What about JPG? Isn't it compressed enough? Common compressed image files should be configured to not re-compress when sent to client: GIF, PNG --- Key: TAP5-552 URL: https://issues.apache.org/jira/browse/TAP5-552 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.1.0.0 Reporter: Howard M. Lewis Ship Assignee: Howard M. Lewis Ship Tapestry's gzip compression logic should know not to try and compress GIF and PNG files are already compressed and should not be re-compressed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-540) Allow exact parsing of numeric client input by creating a BigDecimal Translator and enabling parseBigDecimal in DecimalFormat
[ https://issues.apache.org/jira/browse/TAP5-540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12678982#action_12678982 ] Thiago H. de Paula Figueiredo commented on TAP5-540: Tip: BigDecimal.scale() retuns the number of digits to the right of the decimal point. Then use DecimalFormat.setMinimumFractionDigits() to define the number of digits to the right of the decimal point when formatting. Allow exact parsing of numeric client input by creating a BigDecimal Translator and enabling parseBigDecimal in DecimalFormat - Key: TAP5-540 URL: https://issues.apache.org/jira/browse/TAP5-540 Project: Tapestry 5 Issue Type: Improvement Components: tapestry-core Affects Versions: 5.1.0.1 Reporter: Paudi Moriarty Assignee: Howard M. Lewis Ship The current NumericTranslator is great but it is not easy to build on it since the classes are internal. Tapestry should provide a BigDecimal Translator which uses the infrastructure created for TAP5-211 but parses client input directly to BigDecimal retaining the full precision of that input. For example, I need a client input of 100.00 to be translated to a BigDecimal with value 100.00. Contributing a NumericTranslatorBigDecimal results in a BigDecimal with value 100 because the input is parsed to a long by the NumberFormat before being type coerced. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-213) Create an easier way to populate List of object to Select component
[
https://issues.apache.org/jira/browse/TAP5-213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12679880#action_12679880
]
Thiago H. de Paula Figueiredo commented on TAP5-213:
By the way, the GenericSelectModel approach suggested by
http://wiki.apache.org/tapestry/Tapestry5HowtoSelectWithObjects (implementing
SelectModel and ValueEncoder in the same class and relying in a list to do the
encoding) is so bad that sometimes I want to put a Thiago does not recommend
this approach warning on it.
Create an easier way to populate List of object to Select component
---
Key: TAP5-213
URL: https://issues.apache.org/jira/browse/TAP5-213
Project: Tapestry 5
Issue Type: Wish
Affects Versions: 5.0.15
Reporter: Joshua Partogi
Assignee: Kevin Menard
Create an easier way to populate List of object to Select component.
Currently we must create a class that implement SelectModel and a class that
implement ValueEncoder. Perhaps it would be nice if there property in the
Select component such as list that corresponds to the list of object to be
displayed for the combobox as such:
select t:type=Select t:id=member model=member list=members /
and the Page class as such:
private ListMember members;
public ListMember getMembers()
{
return members;
}
public void setMembers(ListMember members)
{
this.members = members;
}
@SetupRender
public void init(){
members = dao.getMembers();
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-565) Add BeanPropertySelectModel
[ https://issues.apache.org/jira/browse/TAP5-565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12680025#action_12680025 ] Thiago H. de Paula Figueiredo commented on TAP5-565: Ulrich: I agree with you, but how we could write a generic way to implement it? The toClient() part is easy (toString()), but how to decode it? I guess we could add ValueEncoders for Strings and number types, but not for arbitrary classes. Add BeanPropertySelectModel --- Key: TAP5-565 URL: https://issues.apache.org/jira/browse/TAP5-565 Project: Tapestry 5 Issue Type: Improvement Components: tapestry-core Affects Versions: 5.1.0.1 Reporter: Kevin Menard Assignee: Kevin Menard Priority: Minor As raised in TAP5-213, we don't do enough to make the common cases of using the Select component easy enough. To this end, we should add back in the BeanPropertySelectModel default implementation like T4 had (http://tapestry.apache.org/tapestry4.1/apidocs/org/apache/tapestry/form/BeanPropertySelectionModel.html). Not only was it a good idea then, but it should help with a T4 migration to T5. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TAP5-557) Provide support for URL rewriting
[ https://issues.apache.org/jira/browse/TAP5-557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thiago H. de Paula Figueiredo updated TAP5-557: --- Summary: Provide support for URL rewriting (was: Provide some way to do URL rewriting) Provide support for URL rewriting - Key: TAP5-557 URL: https://issues.apache.org/jira/browse/TAP5-557 Project: Tapestry 5 Issue Type: New Feature Affects Versions: 5.1.0.1, 5.0.18 Reporter: Thiago H. de Paula Figueiredo Assignee: Thiago H. de Paula Figueiredo Fix For: 5.1.0.1 Tapestry should provide some way, configured via Tapestry-IoC, to provide URL rewriting. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TAP5-557) Provide support for URL rewriting
[ https://issues.apache.org/jira/browse/TAP5-557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thiago H. de Paula Figueiredo updated TAP5-557: --- Fix Version/s: 5.1.0.1 Provide support for URL rewriting - Key: TAP5-557 URL: https://issues.apache.org/jira/browse/TAP5-557 Project: Tapestry 5 Issue Type: New Feature Affects Versions: 5.1.0.1, 5.0.18 Reporter: Thiago H. de Paula Figueiredo Assignee: Thiago H. de Paula Figueiredo Fix For: 5.1.0.1 Tapestry should provide some way, configured via Tapestry-IoC, to provide URL rewriting. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TAP5-557) Provide support for URL rewriting
[ https://issues.apache.org/jira/browse/TAP5-557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thiago H. de Paula Figueiredo resolved TAP5-557. Resolution: Fixed Provide support for URL rewriting - Key: TAP5-557 URL: https://issues.apache.org/jira/browse/TAP5-557 Project: Tapestry 5 Issue Type: New Feature Affects Versions: 5.1.0.1, 5.0.18 Reporter: Thiago H. de Paula Figueiredo Assignee: Thiago H. de Paula Figueiredo Fix For: 5.1.0.1 Tapestry should provide some way, configured via Tapestry-IoC, to provide URL rewriting. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (TAP5-557) Provide support for URL rewriting
[ https://issues.apache.org/jira/browse/TAP5-557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thiago H. de Paula Figueiredo reopened TAP5-557: Reopened because it needs to handle page link generation too. Thanks Andreas Andreou for warning me. Provide support for URL rewriting - Key: TAP5-557 URL: https://issues.apache.org/jira/browse/TAP5-557 Project: Tapestry 5 Issue Type: New Feature Affects Versions: 5.1.0.1, 5.0.18 Reporter: Thiago H. de Paula Figueiredo Assignee: Thiago H. de Paula Figueiredo Fix For: 5.1.0.1 Tapestry should provide some way, configured via Tapestry-IoC, to provide URL rewriting. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-554) NPE when click addRow within AjaxFormLoop
[ https://issues.apache.org/jira/browse/TAP5-554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12680501#action_12680501 ] Thiago H. de Paula Figueiredo commented on TAP5-554: A very similar exception happens when doing an AJAX form submit, so I guess this is not a problem just with AjaxFormLoop, but with AJAX rendering itself. NPE when click addRow within AjaxFormLoop - Key: TAP5-554 URL: https://issues.apache.org/jira/browse/TAP5-554 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.1.0.0, 5.1.0.1 Reporter: Yunhua Sang Priority: Minor On the screen: Ajax failure: Status 500 for /tapestry/forminjectordemo.loop.rowinjector:inject/1236217007110?t:ac=FakePageActivationContextValuet:formcomponentid=FormInjectorDemo:formt:formid=form: java.lang.NullPointerException In console: ERROR] RequestExceptionHandler Processing of request failed with uncaught exception: java.lang.NullPointerException java.lang.NullPointerException at org.apache.tapestry5.dom.Element.createNamespaceURIToPrefix(Element.java:678) at org.apache.tapestry5.dom.Element.toMarkup(Element.java:335) at org.apache.tapestry5.dom.Element.writeChildMarkup(Element.java:872) at org.apache.tapestry5.dom.Element.getChildMarkup(Element.java:885) at org.apache.tapestry5.internal.services.PageRenderQueueImpl.renderPartial(PageRenderQueueImpl.java:163) at $PageRenderQueue_11fd441d050.renderPartial($PageRenderQueue_11fd441d050.java) at $PageRenderQueue_11fd441d04f.renderPartial($PageRenderQueue_11fd441d04f.java) at org.apache.tapestry5.internal.services.PartialMarkupRendererTerminator.renderMarkup(PartialMarkupRendererTerminator.java:39) at org.apache.tapestry5.services.TapestryModule$31.renderMarkup(TapestryModule.java:1821) at $PartialMarkupRenderer_11fd441d129.renderMarkup($PartialMarkupRenderer_11fd441d129.java) at org.apache.tapestry5.services.TapestryModule$30.renderMarkup(TapestryModule.java:1802) at $PartialMarkupRenderer_11fd441d129.renderMarkup($PartialMarkupRenderer_11fd441d129.java) at org.apache.tapestry5.services.TapestryModule$29.renderMarkup(TapestryModule.java:1784) at $PartialMarkupRenderer_11fd441d129.renderMarkup($PartialMarkupRenderer_11fd441d129.java) at org.apache.tapestry5.services.TapestryModule$28.renderMarkup(TapestryModule.java:1766) at $PartialMarkupRenderer_11fd441d129.renderMarkup($PartialMarkupRenderer_11fd441d129.java) at org.apache.tapestry5.services.TapestryModule$27.renderMarkup(TapestryModule.java:1740) at $PartialMarkupRenderer_11fd441d129.renderMarkup($PartialMarkupRenderer_11fd441d129.java) at $PartialMarkupRenderer_11fd441d128.renderMarkup($PartialMarkupRenderer_11fd441d128.java) at org.apache.tapestry5.internal.services.AjaxPartialResponseRendererImpl.renderPartialPageMarkup(AjaxPartialResponseRendererImpl.java:79) at $AjaxPartialResponseRenderer_11fd441d126.renderPartialPageMarkup($AjaxPartialResponseRenderer_11fd441d126.java) at org.apache.tapestry5.internal.services.AjaxComponentEventRequestHandler.handle(AjaxComponentEventRequestHandler.java:118) at $ComponentEventRequestHandler_11fd441d123.handle($ComponentEventRequestHandler_11fd441d123.java) at org.apache.tapestry5.internal.services.AjaxFilter.handle(AjaxFilter.java:42) at $ComponentEventRequestHandler_11fd441d125.handle($ComponentEventRequestHandler_11fd441d125.java) at org.apache.tapestry5.services.TapestryModule$35.handle(TapestryModule.java:2109) at $ComponentEventRequestHandler_11fd441d125.handle($ComponentEventRequestHandler_11fd441d125.java) at $ComponentEventRequestHandler_11fd441cffd.handle($ComponentEventRequestHandler_11fd441cffd.java) at org.apache.tapestry5.internal.services.ComponentRequestHandlerTerminator.handleComponentEvent(ComponentRequestHandlerTerminator.java:43) at $ComponentRequestHandler_11fd441cff6.handleComponentEvent($ComponentRequestHandler_11fd441cff6.java) at org.apache.tapestry5.internal.services.ComponentEventDispatcher.dispatch(ComponentEventDispatcher.java:138) at $Dispatcher_11fd441cff7.dispatch($Dispatcher_11fd441cff7.java) at $Dispatcher_11fd441cfed.dispatch($Dispatcher_11fd441cfed.java) at org.apache.tapestry5.services.TapestryModule$RequestHandlerTerminator.service(TapestryModule.java:246) at org.apache.tapestry5.internal.services.RequestErrorFilter.service(RequestErrorFilter.java:26) at $RequestHandler_11fd441cfee.service($RequestHandler_11fd441cfee.java) at
[jira] Created: (TAP5-573) NullPointerException during AJAX form submit
NullPointerException during AJAX form submit Key: TAP5-573 URL: https://issues.apache.org/jira/browse/TAP5-573 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.1.0.1 Reporter: Thiago H. de Paula Figueiredo Priority: Critical To reproduce this bug: * Checkout the Ars Machina Example Project from SVN: https://ars-machina.svn.sourceforge.net/svnroot/ars-machina/example/branches/1.1 * Run its Main class (default package) * Click in the login link * Login as manager (login) manager (password) * Click in the project listings link * Click in one of the edition links (the second icon) * Click the submit button. Relevant part of the stack trace: java.lang.NullPointerException at org.apache.tapestry5.dom.Element.createNamespaceURIToPrefix(Element.java:676) at org.apache.tapestry5.dom.Element.toMarkup(Element.java:333) at org.apache.tapestry5.dom.Element.writeChildMarkup(Element.java:870) at org.apache.tapestry5.dom.Element.toMarkup(Element.java:386) at org.apache.tapestry5.dom.Element.writeChildMarkup(Element.java:870) at org.apache.tapestry5.dom.Element.toMarkup(Element.java:386) at org.apache.tapestry5.dom.Element.writeChildMarkup(Element.java:870) at org.apache.tapestry5.dom.Element.getChildMarkup(Element.java:883) at org.apache.tapestry5.internal.services.PageRenderQueueImpl.renderPartial(PageRenderQueueImpl.java:163) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TAP5-557) Provide support for URL rewriting
[ https://issues.apache.org/jira/browse/TAP5-557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thiago H. de Paula Figueiredo resolved TAP5-557. Resolution: Fixed Fix Version/s: 5.1.0.2 Added the missing link rewriting part. The same rules used for rewriting incoming requests are also used to rewrite links generated by ComponentEventLinkEncoder (i.e. any one using regular Tapestry link creationg like ComponentResources.create*Link()). Provide support for URL rewriting - Key: TAP5-557 URL: https://issues.apache.org/jira/browse/TAP5-557 Project: Tapestry 5 Issue Type: New Feature Affects Versions: 5.1.0.1, 5.0.18 Reporter: Thiago H. de Paula Figueiredo Assignee: Thiago H. de Paula Figueiredo Fix For: 5.1.0.2 Tapestry should provide some way, configured via Tapestry-IoC, to provide URL rewriting. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (TAP5-557) Provide support for URL rewriting
[ https://issues.apache.org/jira/browse/TAP5-557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thiago H. de Paula Figueiredo closed TAP5-557. -- Issue implemented and documented. Provide support for URL rewriting - Key: TAP5-557 URL: https://issues.apache.org/jira/browse/TAP5-557 Project: Tapestry 5 Issue Type: New Feature Affects Versions: 5.1.0.1, 5.0.18 Reporter: Thiago H. de Paula Figueiredo Assignee: Thiago H. de Paula Figueiredo Fix For: 5.1.0.2 Tapestry should provide some way, configured via Tapestry-IoC, to provide URL rewriting. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-557) Provide support for URL rewriting
[ https://issues.apache.org/jira/browse/TAP5-557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12682651#action_12682651 ] Thiago H. de Paula Figueiredo commented on TAP5-557: Each rule will be applied, but each one can decide to really rewrite the URL/link or not. If you take a look at the tests (app5.services.AppModule), you see rules that only apply to incoming URL requests and ignore the others and rules that only apply only for generated links. And there is even one rule that applies to a single URL. I thought that it would be easier to have the same rewriting mechanism for both incoming URLs and generated links. As Tapestry 5.1.0.x is still an alpha, this can be changed if we decide otherwise. Provide support for URL rewriting - Key: TAP5-557 URL: https://issues.apache.org/jira/browse/TAP5-557 Project: Tapestry 5 Issue Type: New Feature Affects Versions: 5.1.0.1, 5.0.18 Reporter: Thiago H. de Paula Figueiredo Assignee: Thiago H. de Paula Figueiredo Fix For: 5.1.0.2 Tapestry should provide some way, configured via Tapestry-IoC, to provide URL rewriting. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-573) NullPointerException during AJAX form submit
[ https://issues.apache.org/jira/browse/TAP5-573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12682744#action_12682744 ] Thiago H. de Paula Figueiredo commented on TAP5-573: The dependency should be 3.3.0.ga, not 3.3.0.GA. Changing the example's pom.xml Hibernate Annotations should be enough. Strangely, it works here. Windows case sensitivity maybe? NullPointerException during AJAX form submit Key: TAP5-573 URL: https://issues.apache.org/jira/browse/TAP5-573 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.1.0.1 Reporter: Thiago H. de Paula Figueiredo Assignee: Howard M. Lewis Ship Priority: Critical To reproduce this bug: * Checkout the Ars Machina Example Project from SVN: https://ars-machina.svn.sourceforge.net/svnroot/ars-machina/example/branches/1.1 * Run its Main class (default package) * Click in the login link * Login as manager (login) manager (password) * Click in the project listings link * Click in one of the edition links (the second icon) * Click the submit button. Relevant part of the stack trace: java.lang.NullPointerException at org.apache.tapestry5.dom.Element.createNamespaceURIToPrefix(Element.java:676) at org.apache.tapestry5.dom.Element.toMarkup(Element.java:333) at org.apache.tapestry5.dom.Element.writeChildMarkup(Element.java:870) at org.apache.tapestry5.dom.Element.toMarkup(Element.java:386) at org.apache.tapestry5.dom.Element.writeChildMarkup(Element.java:870) at org.apache.tapestry5.dom.Element.toMarkup(Element.java:386) at org.apache.tapestry5.dom.Element.writeChildMarkup(Element.java:870) at org.apache.tapestry5.dom.Element.getChildMarkup(Element.java:883) at org.apache.tapestry5.internal.services.PageRenderQueueImpl.renderPartial(PageRenderQueueImpl.java:163) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-573) NullPointerException during AJAX form submit
[ https://issues.apache.org/jira/browse/TAP5-573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12682817#action_12682817 ] Thiago H. de Paula Figueiredo commented on TAP5-573: You should be returning the zone's body (getFormZone().getBody()) to update the Zone after submission (in Ajax mode). That's something new to me. The documentation just says that the event handler must return a component, and Zone is a component. I've doing this for a long time (since T5 has Zones, actually) and this exception only ocurrs with 5.1.0.0+, not with 5.0.18 or past versions. Maybe we should update the docs. Anyway, shouldn't Tapestry handle a Zone event handler return? NullPointerException during AJAX form submit Key: TAP5-573 URL: https://issues.apache.org/jira/browse/TAP5-573 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.1.0.1 Reporter: Thiago H. de Paula Figueiredo Assignee: Howard M. Lewis Ship Priority: Critical To reproduce this bug: * Checkout the Ars Machina Example Project from SVN: https://ars-machina.svn.sourceforge.net/svnroot/ars-machina/example/branches/1.1 * Run its Main class (default package) * Click in the login link * Login as manager (login) manager (password) * Click in the project listings link * Click in one of the edition links (the second icon) * Click the submit button. Relevant part of the stack trace: java.lang.NullPointerException at org.apache.tapestry5.dom.Element.createNamespaceURIToPrefix(Element.java:676) at org.apache.tapestry5.dom.Element.toMarkup(Element.java:333) at org.apache.tapestry5.dom.Element.writeChildMarkup(Element.java:870) at org.apache.tapestry5.dom.Element.toMarkup(Element.java:386) at org.apache.tapestry5.dom.Element.writeChildMarkup(Element.java:870) at org.apache.tapestry5.dom.Element.toMarkup(Element.java:386) at org.apache.tapestry5.dom.Element.writeChildMarkup(Element.java:870) at org.apache.tapestry5.dom.Element.getChildMarkup(Element.java:883) at org.apache.tapestry5.internal.services.PageRenderQueueImpl.renderPartial(PageRenderQueueImpl.java:163) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-597) The form submit event handler method should have access to the source of the event
[ https://issues.apache.org/jira/browse/TAP5-597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12689114#action_12689114 ] Thiago H. de Paula Figueiredo commented on TAP5-597: Isn't this issue covered by https://issues.apache.org/jira/browse/TAP5-146? The form submit event handler method should have access to the source of the event -- Key: TAP5-597 URL: https://issues.apache.org/jira/browse/TAP5-597 Project: Tapestry 5 Issue Type: Improvement Components: tapestry-core Reporter: Hugo Palma Priority: Minor Right now if you want to have more than one submit button in a form and you want to implement different execution logic for each you have to: - implement an event listener for both buttons that sets a local field that signals which button was pressed. - implement a form event listener method that reads the local field value and executes whatever logic based on that. (such a solution is provided on http://jumpstart.doublenegative.com.au:8080/jumpstart/examples/input/multiplesubmits1) If the form event listener could know which button triggered the commit this type of logic would be much simpler to implement. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (TAP5-599) Copying/Cloning a field in the get mutator of a persisted object produces unexpected results on Tapestry page.
[
https://issues.apache.org/jira/browse/TAP5-599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thiago H. de Paula Figueiredo closed TAP5-599.
--
Resolution: Invalid
This is expected behaviour, as Tapestry uses getters and setters to access
expression values.
During a form submission, the expression request.testContainer.testValue is set
using getRequest().getTestContainer().setTestValue(String s).
Please post your doubts in the mailing list, so most people can help (and they
usually do). ;)
Copying/Cloning a field in the get mutator of a persisted object produces
unexpected results on Tapestry page.
--
Key: TAP5-599
URL: https://issues.apache.org/jira/browse/TAP5-599
Project: Tapestry 5
Issue Type: Question
Components: documentation, tapestry-core
Affects Versions: 5.0.18
Reporter: Michael Fitzurka
Priority: Minor
I am new to Tapestry (awesome BTW!) and not sure if this is a bug /
misunderstanding / RTFM moment / or just an FYI.
But this tripped me up for awhile and makes perfect sense when I tracked it
down.
If you copy or clone a object field in the get mutator to protect from
unexpected mutations (which is a good thing), it affects Tapestry.
Given the code and page below; the page will display but seemingly ignore
the entered value (See comments in code).
It makes sense, but not cloning the object field opens the code up to other
unintended / non-beneficial mutations.
Perhaps all that is needed is to document this, or I should RTFM if it
already is ;-)
Thanks - again awesome product!
===
public class TestContainer
{
private String testValue;
public TestContainer() { super(); }
public TestContainer(String _testValue) { setTestValue(_testValue); }
public TestContainer(TestContainer _container) {
this(_container.getTestValue()); }
public String getTestValue() { return testValue; }
public void setTestValue(String _testValue) { testValue = _testValue; }
@Override public String toString() {
return TestContainer.testValue = ' + testValue + '\'';
}
}
===
public class TestWrapper
{
private TestContainer testContainer;
public TestWrapper() { super(); }
public TestWrapper(TestContainer _testContainer) {
setTestContainer(_testContainer); }
public TestWrapper(TestWrapper _testWrapper) {
this(_testWrapper.getTestContainer()); }
public TestContainer getTestContainer() {
// This works as expected.
//return testContainer;
// Cloning/Copying causes unforseen issues.
return testContainer == null ? null : new
TestContainer(testContainer);
}
public void setTestContainer(TestContainer _testContainer) {
// Cloning/Copying here doesn't matter.
testContainer = _testContainer == null ? null : new
TestContainer(_testContainer);
}
@Override public String toString() {
return TestWrapper.testContainer = + testContainer;
}
}
===
import org.apache.tapestry5.annotations.Persist;
import org.apache.tapestry5.annotations.Property;
import org.apache.tapestry5.annotations.Component;
import org.apache.tapestry5.corelib.components.Form;
public class TestWrapperPage
{
@Component private Form form;
@Property @Persist private TestWrapper request;
@Persist @Property private String response;
public TestWrapperPage() { super(); }
void onActivate() {
if (request == null)
request = new TestWrapper(new TestContainer(init));
}
void onSelectedFromSendRequest() {
response = TestWrapperPage.testWrapper = + request.toString();
}
}
===
html xmlns:t=http://tapestry.apache.org/schema/tapestry_5_0_0.xsd;
head
titleTest Wrapper Page/title
/head
body
form t:id=form
t:errors /
input type=text t:type=TextField t:id=request
t:value=request.testContainer.testValue /br /
input type=submit t:type=submit t:id=sendRequest value=Send
Request /br /
textarea cols=80 rows=10 readonly=true t:type=TextArea
t:id=response
/textarea
/form
/body
/html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-612) URLRewriting should distinguish between incoming and outgoing requests
[ https://issues.apache.org/jira/browse/TAP5-612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12694092#action_12694092 ] Thiago H. de Paula Figueiredo commented on TAP5-612: I vote for #3, as it is by far the more flexible approach, the easiest to write rules and test them. It could include, for example, a method that tells if that given request is an event one or a page one. As generated link rewriting works by decorating ComponentEventLinkEncoder, this is easy to do (different methods for generating page links and event links) and helps some usecases described in the mailing list. URLRewriting should distinguish between incoming and outgoing requests -- Key: TAP5-612 URL: https://issues.apache.org/jira/browse/TAP5-612 Project: Tapestry 5 Issue Type: Improvement Components: tapestry-core Affects Versions: 5.1.0.2 Reporter: Robert Zeigler Assignee: Robert Zeigler Currently, the new URLRewriting support uses a single method on the set of rewrite rules called process. This method is called both for transforming incoming request urls and for rewriting outbound links. Generally, however, urls from incoming requests are going to be translated into tapestry-aware urls and urls for links will be mapped from tapestry-aware urls to some external form. To facilitate the in vs. out mapping, URL Rewriting should provide a mechanism to distinguish between rewriting incoming urls vs. rewriting links. Three possible ways of doing that are: 1) have a separate service for incoming vs. outgoing rewriting 2) Alter the URLRewriterRule API to change from the single process method to two methods: processIncoming and processOutgoing (or something along those lines) 3) Alter URLRewriterRule API to pass an additional RewriteContext method parameter. The context would include (for now) a single method boolean isIncoming or perhaps boolean isOutgoing. (Alternatively, we could change the method signature to just provide a boolean isOutgoing parameter; but providing the RewriteContext would allow the API to evolve better in the future should we find that additional context information is useful). Currently leaning towards #2. The positive point in #3 could be handled in the future by the introduction of a per-thread helper service, RewriteContext or some such, that could be injected directly into the rewrite rules. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (TAP5-619) Provide way to override PropertyEditor.beanBlockSource
[ https://issues.apache.org/jira/browse/TAP5-619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thiago H. de Paula Figueiredo closed TAP5-619. -- Resolution: Won't Fix BeanBlockSource, is any other Tapestry service, is already overridable. To reorder or remove properties from a BeanEditForm, you can use the reorder and exclude parameters. By the way, Howard already stated in the mailing list that: (...) Grid and BeanEditForm are intended as scaffolding to get you up and running quick. As your application gets refined, you may start to pull apart the scaffolding components to build something more precisely tuned to your specific requirements. It is not my intention that we should keep layering on more parameters and models and such to make BeanEditForm and Grid the be-all and end-all of editting and display components; they're really about keeping momentum going, especially during the early, frustrating parts of writing an application: those first few steps. http://www.nabble.com/Tabindex-and-accesskey-in-BeanEditForm--td22380749s302.html#a22420266 Provide way to override PropertyEditor.beanBlockSource -- Key: TAP5-619 URL: https://issues.apache.org/jira/browse/TAP5-619 Project: Tapestry 5 Issue Type: Wish Components: tapestry-core Affects Versions: 5.1.0.1 Reporter: Alfie Kirkpatrick Priority: Minor I am building a search form and would like to override the default edit blocks with search-style ones. This is conjunction with a HashMapString, Object backed bean model. As an example, for dates I want to have a date range block which sends back a start/end range for a date, possibly as a DateRangeSearchTerm against the property name in the hashmap. The search implementation will then know how to convert this into a query to the backend. I might be pushing the whole BeanEditModel/Conduit framework further than intended? However, doing it this way provides some nice ways to override an auto-built form, eg. by restricting/reordering the properties or by overriding specific blocks even further. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-619) Provide way to override PropertyEditor.beanBlockSource
[ https://issues.apache.org/jira/browse/TAP5-619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12695371#action_12695371 ] Thiago H. de Paula Figueiredo commented on TAP5-619: Hi! You can use property error overrides: t:beaneditform object=loginCredentials t:parameter name=password t:label for=password/ t:passwordfield t:id=password value=loginCredentials.password/ /t:parameter /t:beaneditform http://tapestry.formos.com/nightly/tapestry5/guide/beaneditform.html Another solution is to use BeanEditor instead of BeanEditForm (easy transition) and its overrides parameter. Provide way to override PropertyEditor.beanBlockSource -- Key: TAP5-619 URL: https://issues.apache.org/jira/browse/TAP5-619 Project: Tapestry 5 Issue Type: Wish Components: tapestry-core Affects Versions: 5.1.0.1 Reporter: Alfie Kirkpatrick Priority: Minor I am building a search form and would like to override the default edit blocks with search-style ones. This is conjunction with a HashMapString, Object backed bean model. As an example, for dates I want to have a date range block which sends back a start/end range for a date, possibly as a DateRangeSearchTerm against the property name in the hashmap. The search implementation will then know how to convert this into a query to the backend. I might be pushing the whole BeanEditModel/Conduit framework further than intended? However, doing it this way provides some nice ways to override an auto-built form, eg. by restricting/reordering the properties or by overriding specific blocks even further. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-634) Google App Engine Support: disable code that creates new threads
[ https://issues.apache.org/jira/browse/TAP5-634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12697158#action_12697158 ] Thiago H. de Paula Figueiredo commented on TAP5-634: Don't forget that GAA also supports JPA. This is very nice, as I guess it'll be a easier transition from Hibernate. Google App Engine Support: disable code that creates new threads Key: TAP5-634 URL: https://issues.apache.org/jira/browse/TAP5-634 Project: Tapestry 5 Issue Type: Improvement Components: tapestry-core, tapestry-ioc Affects Versions: 5.1.0.3 Reporter: Howard M. Lewis Ship Right off the bat, the restriction in GAA that no threads be created will affect a few, small sections of Tapestry. In the larger scheme of things, a tapestry-googleappengine library may require a few things: - Make the GAA services (such as UserService) injectable - Support for JDO (much like tapestry-hibernate, today) - Other, unforseen Also, depending on the license of GAA (and availabilty through Maven) may need to host such a library at Tapestry360. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-138) Add Zone parameter to Select component
[ https://issues.apache.org/jira/browse/TAP5-138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12697160#action_12697160 ] Thiago H. de Paula Figueiredo commented on TAP5-138: I suggest the AJAX part would be better implemented as a mixin instead, a little like Autocomplete. And I agree with Peter about having something like a LinkedSelectPair component. They're would be a good suite for different situations. Add Zone parameter to Select component -- Key: TAP5-138 URL: https://issues.apache.org/jira/browse/TAP5-138 Project: Tapestry 5 Issue Type: New Feature Affects Versions: 5.0.15 Reporter: Geoff Callender Add AJAX ability to selection in a Select component to allow the classic chaining of Select components. Eg. for filtering car advertisements: 3 Select components - Brand, Make, Model. Choosing a Brand causes the Make to be enabled, showing the possible makes. Similarly, choosing a Make causes the Model to be enabled, showing the possible models. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (TAP5-697) Tapestry_improvement_ideas
[ https://issues.apache.org/jira/browse/TAP5-697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thiago H. de Paula Figueiredo closed TAP5-697. -- Resolution: Invalid There is a builtin Tapestry component, OutputRaw, that does exactly what you need: http://tapestry.apache.org/tapestry5.1/tapestry-core/ref/org/apache/tapestry5/corelib/components/OutputRaw.html It outputs HTML without converting into lt;, for example. Tapestry_improvement_ideas -- Key: TAP5-697 URL: https://issues.apache.org/jira/browse/TAP5-697 Project: Tapestry 5 Issue Type: Improvement Components: tapestry-core Affects Versions: 5.1.0.5, 5.0.18 Reporter: Tam Du Attachments: DisableHtmlTag.java In the tml file, we should not disable html the second time, that is, if it is already disabled, then should not disable again. For more details, I attach here my file DisableHTMLTag.java which I have been using to not disable html the second time. I hope that you can improve this feature in the next version. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-700) Improve Grid component of Tapestry
[ https://issues.apache.org/jira/browse/TAP5-700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12709665#action_12709665 ] Thiago H. de Paula Figueiredo commented on TAP5-700: Use the Loop component instead of Grid in this case. If you want pagination, use the PagedLoop from ChenilleKit. Improve Grid component of Tapestry -- Key: TAP5-700 URL: https://issues.apache.org/jira/browse/TAP5-700 Project: Tapestry 5 Issue Type: Improvement Components: tapestry-core Affects Versions: 5.1.0.5, 5.0.18 Reporter: Tam Du When using Grid component of Tapestry, I found that we should have an option to display/not display the header of the Grid. The reason of this requirement is: when developing my product, in some cases, I need to use Grid but I don't want to display the header of that grid. For example, I use Tapestry to write the list topic page of this website http://62.101.68.227:/snippetrepobrowser/, the header of Grid is unnecessary. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (TAP5-703) Improvement where to save tml files
[ https://issues.apache.org/jira/browse/TAP5-703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thiago H. de Paula Figueiredo closed TAP5-703. -- Resolution: Invalid I have just created a .tml class in a Tapestry project and tried to request it. It gives me a 403 (Forbidden error). Anyway, you can put the .tml files in the classpath (the recommended location) instead of context root. Improvement where to save tml files --- Key: TAP5-703 URL: https://issues.apache.org/jira/browse/TAP5-703 Project: Tapestry 5 Issue Type: Improvement Components: tapestry-core Affects Versions: 5.1.0.5, 5.0.18 Reporter: Tam Du I request this feature for purpose of the security of website. Currently, I found that users can download tml files by putting .tml at the end of URL. Users can do like that because .tml files are put in the webroot folder of the project. To prevent download, I have 2 solutions for this case: Solution 1: .tml files can be saved anywhere in project, and Tapestry will support the configuration to determine where to save these files. Solution 2: Save tml file in the WEB_INF folder of project. I hope that next version of Tapestry will have this option. Thank you very much. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (TAP5-705) Let a page choose its layout
[
https://issues.apache.org/jira/browse/TAP5-705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thiago H. de Paula Figueiredo closed TAP5-705.
--
Resolution: Won't Fix
This cannot be implemented in Tapestry without huge architectural changes, as
it is dynamic structure, and Tapestry is implemented under the static
structure, dynamic behaviour philosophy. In addition, it would handle layout
components in a different way from normal components, something Tapestry 5 does
not do. Anyway, this can be implemented using blocks and the Delegate
component: create a Layout component and use Delegate inside it, not inside the
pages.
Let a page choose its layout
Key: TAP5-705
URL: https://issues.apache.org/jira/browse/TAP5-705
Project: Tapestry 5
Issue Type: Wish
Components: tapestry-core
Affects Versions: 5.0.18
Reporter: Borut Bolcina
It would be great if a page could dynamically choose its layout. In some
cases the page would use Layout1 component and in some cases Layout2.
The t:type=${layout} does not get expanded to whatever I set in Index.java.
PageWithLayout.tml
===
div t:type=${layout}
xmlns:t=http://tapestry.apache.org/schema/tapestry_5_0_0.xsd;
ppage with ${layout}/p
/div
PageWithLayout.java
===
public class PageWithLayout {
private String layout;
public String getLayout() {
return layout;
}
public void setLayout(String layout) {
this.layout = layout;
}
}
Index.tml
===
t:actionlink t:id=PageWithLayout1layout1/t:actionlinkbr/
t:actionlink t:id=PageWithLayout2layout2/t:actionlink
Index.java
===
public class Index {
@InjectPage
private PageWithLayout pageWithLayout;
Object onActionFromPageWithLayout1() {
pageWithLayout.setLayout(layout1);
return pageWithLayout;
}
Object onActionFromPageWithLayout2() {
pageWithLayout.setLayout(layout2);
return pageWithLayout;
}
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (TAP5-704) Tapestry webapp locks files in WEB-INF/lib, preventing clean re-deploy without restarting Tomcat.
[ https://issues.apache.org/jira/browse/TAP5-704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thiago H. de Paula Figueiredo closed TAP5-704. -- Resolution: Invalid Tomcat is locking the JAR files, not Tapestry, so it's not a Tapestry issue. Take a look at http://tomcat.apache.org/tomcat-6.0-doc/config/context.html and search for http://tomcat.apache.org/tomcat-6.0-doc/config/context.html. Tapestry webapp locks files in WEB-INF/lib, preventing clean re-deploy without restarting Tomcat. - Key: TAP5-704 URL: https://issues.apache.org/jira/browse/TAP5-704 Project: Tapestry 5 Issue Type: Bug Components: quickstart, tapestry-core Affects Versions: 5.1.0.5 Reporter: John Crim Repro steps: 1. Run the Tapestry quickstart archetype (v 5.1.0.5) in NetBeans 2. Run it in the latest version of Tomcat (6.0.18). (note that NetBeans does the equivalent of running the exploded WAR in the /target dir directly within Tomcat) 3. View the site in a browser (to start Tapestry) 4. Undeploy the webapp in the Server window 5. Rebuild the webapp (mvn clean package) and try to deploy it. - the clean will fail with an error like: Failed to delete directory: C:\dev\tapestry\webAppB\target. Reason: Unable to delete file C:\dev\tapestry\webAppB\target\webAppB\WEB-INF\lib\antlr-runtime-3.1.1.jar In short, this flaw adds significant time to each iteration during development. And, if a developer doesn't understand that Tapestry webapps don't undeploy properly, they can easily waste time with bugs that arise because old code is still running in tomcat. The workaround is to shutdown tomcat before rebuilding the webapp (mvn clean) each time. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (TAP5-717) cannot load /assets/5.0.18/tapestry/tapestry.js
[
https://issues.apache.org/jira/browse/TAP5-717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thiago H. de Paula Figueiredo closed TAP5-717.
--
Resolution: Invalid
What about using Tapestry 5.1.0.5 (the latest version)? :) By the way, this
looks like an Apache issue, as its typically configured to handle static file
requests and pass the dynamic ones to Tomcat. But
/assets/5.0.18/tapestry/tapestry.js looks like a static file, but it is handled
by Tapestry. Configure Apache to not handle /assets/* requests.
And please post in the mailing list and check other issues before creating
JIRAs. This issue was already discussed in the list.
cannot load /assets/5.0.18/tapestry/tapestry.js
---
Key: TAP5-717
URL: https://issues.apache.org/jira/browse/TAP5-717
Project: Tapestry 5
Issue Type: Question
Affects Versions: 5.0.18
Reporter: zebracmz
I use tomcat to deploy my project locally without any problems, in Windows
System.
But when I deploy it to the server which is unix, the js files Tapestry5
added can not be loaded:
script src=assets/5.0.18/scriptaculous/prototype.js
type=text/javascript/script
script src=assets/5.0.18/scriptaculous/scriptaculous.js
type=text/javascript/script
script src=assets/5.0.18/scriptaculous/effects.js
type=text/javascript/script
script src=assets/5.0.18/tapestry/tapestry.js
type=text/javascript/script
script type=text/javascript
!--
Tapestry.onDOMLoaded(function() {
$('email').activate();
});
// --
/script
these 4 files were not loaded and the browser(IE7 and firefox) tell me the
script error: Tapestry not defined. Further more, when I use JavaScript
Debugger, double click the linked tapestry.js, it shows:
!DOCTYPE HTML PUBLIC -//IETF//DTD HTML 2.0//EN
2 htmlhead
3 title404 Not Found/title
4 /headbody
5 h1Not Found/h1
6 pThe requested URL /assets/5.0.18/tapestry/tapestry.js was not found
on this server./p
7 hr
8 addressApache/2.0.59 (Unix) DAV/2 mod_jk/1.2.26 Server at
www.shenghuo818.com Port 80/address
9 /body/html
the same thing happens to scriptaculous.js, prototype.js and effects.js.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (TAP5-739) Allow recursion of a component within itself
[ https://issues.apache.org/jira/browse/TAP5-739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thiago H. de Paula Figueiredo closed TAP5-739. -- Resolution: Won't Fix This can't be implemented in Tapestry without rewriting it from scratch. Read the Principle 1 -- Static Structure, Dynamic Behavior section of http://tapestry.apache.org/tapestry5.1/ to know why. Summary: Tapestry has a static tree of components, and allowing recursion in templates needs dynamic instantiation of components. By the way, it's not hard to render trees or tree-like structures inside a component: just render everything in code. One example: http://ars-machina.svn.sourceforge.net/viewvc/ars-machina/tapestry-crud/branches/1.1/src/main/java/br/com/arsmachina/tapestrycrud/components/TreeSelect.java?revision=595view=markup. Allow recursion of a component within itself Key: TAP5-739 URL: https://issues.apache.org/jira/browse/TAP5-739 Project: Tapestry 5 Issue Type: New Feature Reporter: Seth Call Ideally, Tapestry would allow a component to be nested within itself. Because recursion of a component within itself is not possible, it is very difficult to represent a tree structure, which a component representing each node of the tree. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-73) JavaScript libraries should be automatically packed/minimalized
[ https://issues.apache.org/jira/browse/TAP5-73?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12717257#action_12717257 ] Thiago H. de Paula Figueiredo commented on TAP5-73: --- Tapestry 5.1.0.5 (don't know about previous 5.1.0.x versions) already combines all the external (not inline) Javascript files when the symbol SymbolConstants.COMBINE_SCRIPTS is set to true (default value: the same as SymbolConstants.PRODUCTION_MODE, which has true as default). Therefore, IMHO, we don't need Javascript bundles nor JAWR, just the minification of Javascript files. By the way, after GZipping combined Javascript files, do we still need to minify them? I've just opened https://issues.apache.org/jira/browse/TAP5-741 to provide packing/minification for CSS files too. Support for JAWR bundles in @IncludeJavaScript doesn't need any modifications to Tapestry: just add another binding that provides the correct URL for that given JAWR bundle. JavaScript libraries should be automatically packed/minimalized --- Key: TAP5-73 URL: https://issues.apache.org/jira/browse/TAP5-73 Project: Tapestry 5 Issue Type: New Feature Affects Versions: 5.0.15 Reporter: Howard M. Lewis Ship Tapestry should catch downloads of JavaScript libraries, and should pack the JavaScript ... remove comments and unecessary whitespace. I believe Dojo has a library to do this, it may even shorten variable names (!). A smart implementation of this would manage to cache the compressed JS, and notice when the uncompressed version changed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-73) JavaScript libraries should be automatically packed/minimalized
[ https://issues.apache.org/jira/browse/TAP5-73?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12717287#action_12717287 ] Thiago H. de Paula Figueiredo commented on TAP5-73: --- From http://tapestry.apache.org/tapestry5.1/guide/ajax.html Combining Scripts In production mode, Tapestry automatically combines JavaScript libraries. A single request (for a virtual asset) will retrieve the combined content of all referenced JavaScript library files. This is a very useful feature, as it reduces the number of requests needed to present a page to the user. As elsewhere, if the client browser supports gzip compression, the combined JavaScript will be compressed. I have just tested two different pages that use the same set of Javascript files and they received the same URL: http://domainassets/virtual/H4sIAIXNQQrCMBCF4XGhXkREhE500QNN41SqlYS86aKeyat5B4mQgJu6$002ffl47$002fWm9ZNotSWiDR2dAGpw8GmIJn4awwTX8plP3LqYggWbo$002fINxMv2p2Z$002fWPba9$002brtK3dFmkSFpbmiErLaF9WN4u$002fdkC6V1ZJd83eteSggV83nHzax7d8QAQAA.js. I'm not 100% sure, but I think Tapestry, for each requests, checks what Javascript files were included. Then it checks if this file list was already combined into a single one: if not, it does the combining in the spot and sets a far-future expire header on it (for caching). If some of the included Javascript files is changed, then it does the combination again. You can also run tests yourself and take a look at the sources. JavaScript libraries should be automatically packed/minimalized --- Key: TAP5-73 URL: https://issues.apache.org/jira/browse/TAP5-73 Project: Tapestry 5 Issue Type: New Feature Affects Versions: 5.0.15 Reporter: Howard M. Lewis Ship Tapestry should catch downloads of JavaScript libraries, and should pack the JavaScript ... remove comments and unecessary whitespace. I believe Dojo has a library to do this, it may even shorten variable names (!). A smart implementation of this would manage to cache the compressed JS, and notice when the uncompressed version changed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-743) It is too much work to hide all T5 pages inside a virtual folder, for use in mixed-implementation deployments
[ https://issues.apache.org/jira/browse/TAP5-743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12718057#action_12718057 ] Thiago H. de Paula Figueiredo commented on TAP5-743: Can't this be implemented with url-filter/t5/*/url-filter in web.xml and a URL rewriting rule (inbound and outbound)? Or the URL rewriting would not happen before the dispatchers execution? It is too much work to hide all T5 pages inside a virtual folder, for use in mixed-implementation deployments - Key: TAP5-743 URL: https://issues.apache.org/jira/browse/TAP5-743 Project: Tapestry 5 Issue Type: Improvement Components: tapestry-core Affects Versions: 5.1.0.5 Reporter: Howard M. Lewis Ship In a mixed-implementation deployment (mixing Tapestry 5 with Tapestry 4 or some other framework), it would be nice if the T5 apps could be hidden in a virtual /t5 folder. This is doable, but awkward and ugly, today. Ideally, this would be a matter of changing the web.xml mapping to: url-filter/t5/*/url-filter and making some form of configuration change, i.e., configuration.add(ConfigurationConstants.TAPESTRY_APP_FOLDER, t5); This would affect link generation, prefixing urls with t5/ (including the virtual /assets folder, which would be /t5/assets). Since the /t5 portion is part of the URL mapping, it would not be part of the request pathInfo, so existing dispatch code would not need to change. Of course, Websphere has some bugs in this area that might cause some grief. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-742) Add optional component tracing comments to rendered output
[ https://issues.apache.org/jira/browse/TAP5-742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12718086#action_12718086 ] Thiago H. de Paula Figueiredo commented on TAP5-742: Or an specific symbol which has a default value of tapestry.prodution-mode. Add optional component tracing comments to rendered output -- Key: TAP5-742 URL: https://issues.apache.org/jira/browse/TAP5-742 Project: Tapestry 5 Issue Type: New Feature Components: tapestry-core Affects Versions: 5.1.0.5 Reporter: Howard M. Lewis Ship Priority: Minor In complex pages, it can be hard to work backwards from a bit of output HTML in the browser, back to the component that originated the markup. A special mode could be enabled where components would render a comment before and after rendering: !-- BEGIN: Index:layout.pagelink -- a href=dashboardDashboard/a !-- END: Index:layout.pagelink -- This would bloat and clutter the application (a lot!) but would be useful, on occasion. One possibility would be a special query parameter to enable this on a request-by-request basis, i.e., ?t:component-trace=true -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (TAP5-745) Remove Woodstox-specific Stax implementation usage
[ https://issues.apache.org/jira/browse/TAP5-745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thiago H. de Paula Figueiredo closed TAP5-745. -- Resolution: Duplicate Duplicate of https://issues.apache.org/jira/browse/TAP5-713. Different reasons, same problem, same solution. :) Remove Woodstox-specific Stax implementation usage -- Key: TAP5-745 URL: https://issues.apache.org/jira/browse/TAP5-745 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.1.0.4, 5.1.0.5, 5.1 Reporter: Christian Köberl Priority: Critical Attachments: TAP5-745-5.1.0.5.patch Tapestry uses some special extensions to StaX (out of Woodstox) in the template parser. This leads to the problem that Tapestry will usually not run on any application server because the appservers will use their own implementation of Stax. There is a workaround but a main stream web application framework should run on JEE compatible web and application servers without tweaking. The main problem is in org.apache.tapestry5.internal.services.TemplateParserImpl.init(TemplateParserImpl.java:44). Here, XMLInputFactory2 is asked for an instance - but XMLInputFactory2 does not implement the method newInstance. This is delegated to XMLInputFactory. So, the original XMLInputFactory is used - which returns the platform implementation of Stax. Workaround: Add the system property below to Application Server (either via startup script or admin console): -Djavax.xml.stream.XMLInputFactory=com.ctc.wstx.stax.WstxInputFactory -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-745) Remove Woodstox-specific Stax implementation usage
[ https://issues.apache.org/jira/browse/TAP5-745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12720085#action_12720085 ] Thiago H. de Paula Figueiredo commented on TAP5-745: I didn't notice the patch and the solution to TAP5-713 will solve this issue, so I thought I could close this one as a duplicate. You're right about saying that a solution for TAP5-713 will take some time. I'm sorry. Remove Woodstox-specific Stax implementation usage -- Key: TAP5-745 URL: https://issues.apache.org/jira/browse/TAP5-745 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.1.0.4, 5.1.0.5, 5.1 Reporter: Christian Köberl Priority: Critical Attachments: TAP5-745-5.1.0.5.patch Tapestry uses some special extensions to StaX (out of Woodstox) in the template parser. This leads to the problem that Tapestry will usually not run on any application server because the appservers will use their own implementation of Stax. There is a workaround but a main stream web application framework should run on JEE compatible web and application servers without tweaking. The main problem is in org.apache.tapestry5.internal.services.TemplateParserImpl.init(TemplateParserImpl.java:44). Here, XMLInputFactory2 is asked for an instance - but XMLInputFactory2 does not implement the method newInstance. This is delegated to XMLInputFactory. So, the original XMLInputFactory is used - which returns the platform implementation of Stax. Workaround: Add the system property below to Application Server (either via startup script or admin console): -Djavax.xml.stream.XMLInputFactory=com.ctc.wstx.stax.WstxInputFactory -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TAP5-757) Allow PageLink's page parameter to accept page instance or class instead of just logical name to add new type-safe way of render request generation
[ https://issues.apache.org/jira/browse/TAP5-757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thiago H. de Paula Figueiredo updated TAP5-757: --- Summary: Allow PageLink's page parameter to accept page instance or class instead of just logical name to add new type-safe way of render request generation (was: Allow PageLink's page parameter to accept page instance instead of just logical name to add new type-safe way of render request generation) Expanding the issue a little bit to support page class instances as a parameter value too. Allow PageLink's page parameter to accept page instance or class instead of just logical name to add new type-safe way of render request generation -- Key: TAP5-757 URL: https://issues.apache.org/jira/browse/TAP5-757 Project: Tapestry 5 Issue Type: Improvement Components: tapestry-core Affects Versions: 5.1.0.5 Reporter: Vjeran Marcinko It's a bit overkill to use ActionLink only for render requests (when no action is needed) just to use its ability to return target page instance from handler methods, preconfigured with required context values. This type safety comes at the expense of 2 HTTP requests. If PageLink's page parameter could not only accept logical page name, but also page instance, then it would be possible to achieve same type-safety with only one HTTP request. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-745) Remove Woodstox-specific Stax implementation usage
[ https://issues.apache.org/jira/browse/TAP5-745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12725838#action_12725838 ] Thiago H. de Paula Figueiredo commented on TAP5-745: Christian: Yes, I'm a committer, unfortunately too busy to contribute to Tapestry lately. :( Remove Woodstox-specific Stax implementation usage -- Key: TAP5-745 URL: https://issues.apache.org/jira/browse/TAP5-745 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.1.0.4, 5.1.0.5, 5.1 Reporter: Christian Köberl Priority: Critical Attachments: TAP5-745-5.1.0.5.patch Tapestry uses some special extensions to StaX (out of Woodstox) in the template parser. This leads to the problem that Tapestry will usually not run on any application server because the appservers will use their own implementation of Stax. There is a workaround but a main stream web application framework should run on JEE compatible web and application servers without tweaking. The main problem is in org.apache.tapestry5.internal.services.TemplateParserImpl.init(TemplateParserImpl.java:44). Here, XMLInputFactory2 is asked for an instance - but XMLInputFactory2 does not implement the method newInstance. This is delegated to XMLInputFactory. So, the original XMLInputFactory is used - which returns the platform implementation of Stax. Workaround: Add the system property below to Application Server (either via startup script or admin console): -Djavax.xml.stream.XMLInputFactory=com.ctc.wstx.stax.WstxInputFactory -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-771) allow to add a .html to page render requests
[ https://issues.apache.org/jira/browse/TAP5-771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12729638#action_12729638 ] Thiago H. de Paula Figueiredo commented on TAP5-771: You can (almost easily) implement this using URL rewriting. ;) allow to add a .html to page render requests Key: TAP5-771 URL: https://issues.apache.org/jira/browse/TAP5-771 Project: Tapestry 5 Issue Type: Improvement Components: tapestry-core Reporter: Andy Pahne Priority: Minor A common request is to allow a .html extension for page render requests. It would be nice when Tapestry also could be configured to add the desired extension to generated URLs. For backwards compatibility this behaviour could be turned off by default. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-771) allow to add a .html to page render requests
[ https://issues.apache.org/jira/browse/TAP5-771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12732514#action_12732514 ] Thiago H. de Paula Figueiredo commented on TAP5-771: I was just giving a hint on how to do it to the committer that will implement or yourself while a Tapestry version containing it isn't released yet.. :) allow to add a .html to page render requests Key: TAP5-771 URL: https://issues.apache.org/jira/browse/TAP5-771 Project: Tapestry 5 Issue Type: Improvement Components: tapestry-core Reporter: Andy Pahne Priority: Minor A common request is to allow a .html extension for page render requests. It would be nice when Tapestry also could be configured to add the desired extension to generated URLs. For backwards compatibility this behaviour could be turned off by default. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-791) How to get IP Address of client?
[ https://issues.apache.org/jira/browse/TAP5-791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12735053#action_12735053 ] Thiago H. de Paula Figueiredo commented on TAP5-791: Please post questions in the mailing list. There is a much higher probability of getting an answer there then here. How to get IP Address of client? Key: TAP5-791 URL: https://issues.apache.org/jira/browse/TAP5-791 Project: Tapestry 5 Issue Type: Question Affects Versions: 5.0.18 Reporter: zebracmz Fix For: 5.0.18 There is an method getRemoteAddr() in HttpServletRequest. In Tapestry5, I get a Request object like this: @Inject private Request request; but i can not find any method can get the remote address. anyone help? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-815) Asset dispatcher allows any file inside the webapp visible and downloadable
[ https://issues.apache.org/jira/browse/TAP5-815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12747886#action_12747886 ] Thiago H. de Paula Figueiredo commented on TAP5-815: I agree with Ulrich that a whitelist approach is probably the best one, but allowing onle access to assets used in pages is too restrictive IMHO. It would make working with anything that isn't a Tapestry page a hassle. I would suggest to have a chain of command, each object in it receiving the requested URL and responding true (ok), false (file is forbidden) or null (this object doesn't handle this URL, ask the same thing to the next object. This chain of command terminator would be a very restrictive one. Asset dispatcher allows any file inside the webapp visible and downloadable --- Key: TAP5-815 URL: https://issues.apache.org/jira/browse/TAP5-815 Project: Tapestry 5 Issue Type: Bug Affects Versions: 5.1.0.5 Reporter: Thiago H. de Paula Figueiredo Priority: Blocker Take any asset and you have an URL like domain.com/assets/ctx/f10407a6c1753e39/css/main.css. If you request domain.com/assets/ctx/f10407a6c1753e39/, a list containing all the files inside the webapp root is shown. It gives you the hint at downloading any file you want, including anyting inside WEB-INF and assets that should be protected by ResourceDigestGenerator. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-815) Asset dispatcher allows any file inside the webapp visible and downloadable
[ https://issues.apache.org/jira/browse/TAP5-815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12747895#action_12747895 ] Thiago H. de Paula Figueiredo commented on TAP5-815: I agree with Ulrich. The Tapestry asset handling should only be used by Tapestry components, pages and mixins. Asset dispatcher allows any file inside the webapp visible and downloadable --- Key: TAP5-815 URL: https://issues.apache.org/jira/browse/TAP5-815 Project: Tapestry 5 Issue Type: Bug Affects Versions: 5.1.0.5 Reporter: Thiago H. de Paula Figueiredo Priority: Blocker Take any asset and you have an URL like domain.com/assets/ctx/f10407a6c1753e39/css/main.css. If you request domain.com/assets/ctx/f10407a6c1753e39/, a list containing all the files inside the webapp root is shown. It gives you the hint at downloading any file you want, including anyting inside WEB-INF and assets that should be protected by ResourceDigestGenerator. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-879) 404 is never raised automatically if the application has an index page.
[ https://issues.apache.org/jira/browse/TAP5-879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12763603#action_12763603 ] Thiago H. de Paula Figueiredo commented on TAP5-879: Using an activation context or not is something that is decided per page, so a strict check configuration could only affect Index pages (or even only the top one). We can easily create a mixin that sends a 404 response when the activation context at least one parameter. 404 is never raised automatically if the application has an index page. --- Key: TAP5-879 URL: https://issues.apache.org/jira/browse/TAP5-879 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.1.0.5 Reporter: Christophe Cordenier The default behavior of PageRenderDispatcher when a user access to a URL like 'http://localhost/demo/blah' (where 'demo' is the application context and 'blah' is a page that does not exist) is to translate to 'http://localhost/demo/index/blah' if an index page exists even if it has no activation method. It could be a better solution to check if a the index page has an activation method with the corresponding parameter number and type, and automatically raise a http 404 if not. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-896) Contribute 'properties' file extension to the configuration of ResourceDigestGenerator
[ https://issues.apache.org/jira/browse/TAP5-896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12766532#action_12766532 ] Thiago H. de Paula Figueiredo commented on TAP5-896: This is not a solution, not even partly, for TAP-815 because, as far as I know, the problem source is that the digest is not checked in some circunstances (virtual versioned assets). Contribute 'properties' file extension to the configuration of ResourceDigestGenerator -- Key: TAP5-896 URL: https://issues.apache.org/jira/browse/TAP5-896 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.1.0.5 Reporter: Igor Drobiazko Assignee: Igor Drobiazko Priority: Blocker This is a partly solution for TAP5-815 (only for *.properties files). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (TAP5-818) JDK5 Generic is not supported by property chain
[
https://issues.apache.org/jira/browse/TAP5-818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thiago H. de Paula Figueiredo closed TAP5-818.
--
Resolution: Won't Fix
Tapestry's prop binding uses class creation, not reflection, to get and set
values. As the type of T is not known until runtime, all Tapestry know is that
T is Object.
JDK5 Generic is not supported by property chain
---
Key: TAP5-818
URL: https://issues.apache.org/jira/browse/TAP5-818
Project: Tapestry 5
Issue Type: Bug
Components: tapestry-core
Affects Versions: 5.1.0.5
Environment: Tapestry 5.1.0.5
JDK5
Reporter: maxyu
Below is the example
KeyedObject.java:used to store string keyed object
import java.util.*;
import java.util.Map.Entry;
public class KeyedObjectT {
private String key;
private T value;
public String getKey() {
return key;
}
public void setKey(String key) {
this.key = key;
}
public T getValue() {
return value;
}
public void setValue(T value) {
this.value = value;
}
}
page java class:dbpools simply put BasicDataSource and its key name into a
KeyObject list
import java.util.Iterator;
import java.util.LinkedList;
import java.util.List;
import java.util.Map;
import java.util.Map.Entry;
import org.apache.commons.dbcp.BasicDataSource;
import org.apache.tapestry5.annotations.Property;
import org.apache.tapestry5.ioc.annotations.Inject;
import com.elite.predictob.EliteOBManagerProxy;
import com.elite.predictob.KeyedObject;
public class dbpools {
@Inject
private EliteOBManagerProxy proxy;
@Property
private KeyedObjectBasicDataSource datasource;
public ListKeyedObjectBasicDataSource getDatasources()
{
Map dbmap=proxy.getManager().getDataSources();
synchronized (dbmap) {
ListKeyedObjectBasicDataSource list=new
LinkedListKeyedObjectBasicDataSource();
IteratorEntryString,BasicDataSource
it=dbmap.entrySet().iterator();
while(it.hasNext()){
EntryString,BasicDataSource entry=it.next();
KeyedObjectBasicDataSource obj=new
KeyedObjectBasicDataSource();
obj.setKey(entry.getKey());
obj.setValue(entry.getValue());
list.add(obj);
}
return list;
}
}
}
page template:
html xmlns:t=http://tapestry.apache.org/schema/tapestry_5_1_0.xsd;
xmlns:p=tapestry:parameter
xmlns:cl=cl
head
t:elite.cachecontrol.cachecontrol/
title${message:dbpoolconfig}/title
/head
body
table border=1
tr t:type=loop t:element=tr t:source=datasources
value=datasource
td${datasource.key}/tdtd${datasource.value.numActive}/td
/tr
/table
/body
/html
${datasource.value.numActive} will cause following error:
Could not convert 'datasource.value.numActive' into a component parameter
binding: Class java.lang.Object does not contain a property named 'numActive'
(within property expression 'datasource.value.numActive'). Available
properties: class.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-896) Contribute 'properties' file extension to the configuration of ResourceDigestGenerator
[ https://issues.apache.org/jira/browse/TAP5-896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12766536#action_12766536 ] Thiago H. de Paula Figueiredo commented on TAP5-896: You're right. :-) Contribute 'properties' file extension to the configuration of ResourceDigestGenerator -- Key: TAP5-896 URL: https://issues.apache.org/jira/browse/TAP5-896 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.1.0.5 Reporter: Igor Drobiazko Assignee: Igor Drobiazko Priority: Blocker This is a partly solution for TAP5-815 (only for *.properties files). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TAP5-714) Incorrect encoding of single quotes for Ajax requests
[ https://issues.apache.org/jira/browse/TAP5-714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thiago H. de Paula Figueiredo resolved TAP5-714. Resolution: Fixed Fix Version/s: 5.2.0.0 Assignee: Thiago H. de Paula Figueiredo Patch applied and committed. Thanks Ciaran Wood! Incorrect encoding of single quotes for Ajax requests - Key: TAP5-714 URL: https://issues.apache.org/jira/browse/TAP5-714 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.1.0.5 Reporter: Ciaran Wood Assignee: Thiago H. de Paula Figueiredo Priority: Minor Fix For: 5.2.0.0 Attachments: TAP-714.patch I've encountered what I think is a bug in the rendering of an ajax response. Basically, we're returning a block that contains a textfield component. The value of that textfield component is something with a single quote in it, for example o'reilly. The response markup for that textfield is: input value='oapos;reilly' id='addressLine1-1215dd60f22' name='addressLine1' type='text'\/input which renders as o'reilly in Firefox, but in IE the value renders as oapos;reilly. According to http://cssvault.com/blog/2007/10/17/internet-explorer-apos-feature/ , it should be rendering out #39; instead. I've looked into where the apos; is coming from and its in the AbstractMarkupModel class, in the encodeQuoted() method (around line 132). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-335) Provide access to annotations of service implementation class
[
https://issues.apache.org/jira/browse/TAP5-335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12796487#action_12796487
]
Thiago H. de Paula Figueiredo commented on TAP5-335:
Howard, your ServiceDescription lacks some way to get the annotations on
methods, something crucial for implementing many interesting features.
By the way, fixing this JIRA would solve the only thing that other IoC and DI
frameworks have and Tapestry-IoC doesn't.
Not having access to service implementation methods' annotations severely
prevents Tapestry-IoC to be used to implement a transaction management package,
for example. Putting the annotations in the service interfaces isn't a good
solution IMHO, as transaction managem is not part of a service definition,
being a part of the service implementation. And other methods, besides the
service interface ones, could be transactional.
The ideal scenario IMHO is to have the proxies have all the methods from the
service implementation, not just the service interface ones. This way, a proxy
could be used interchangeably with its delegate in terms of annotations. On the
other hand, if a solution that only provides access to service service methods'
annotation, I'm happy already. :)
Looking the the sources, it seems difficult to implement the proxies as I want,
Many places use ClassFab.proxyMethodsToDelegate(Class serviceInterface, String
delegateExpression, String toString) and the service implementation class is
not recorded anywhere. Or shouldn't I take take a look at ModuleImpl methods
first?
Any hints on how to solve this?
Provide access to annotations of service implementation class
-
Key: TAP5-335
URL: https://issues.apache.org/jira/browse/TAP5-335
Project: Tapestry 5
Issue Type: Improvement
Components: tapestry-ioc
Affects Versions: 5.0.15
Reporter: Lubor Gajda
In some situations it would be useful to have direct access to annotations of
service implementation class. This would allow us, during registry startup,
detect services with some specific class or method level annotations and take
related actions.
For instance imagine tapestry-quartz integration based on simple declarative
mechanism where it would be possible to use something like this:
public class MyServiceImpl implements MyService {
@Scheduled(cronExpression=0/5 * * * * ?)
public void myMethod() {
...
}
}
and framework would be able, during registry startup, automatically detect
all service methods annotated by @Scheduled annotation and register them in
the scheduler.
I see two possible solutions:
1. Modify ServiceDef to hold information about service implementation class.
2. Service proxy could inherit all annotations from service implementation
class, then we would be able to check annotations directly on service proxy.
But maybe there is another, more elegant solution.
For more details see thread:
http://thread.gmane.org/gmane.comp.java.tapestry.user/67116/focus=67116
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-993) Reorganize ComponentClassTransformWorkers to start moving away from Javassist
[ https://issues.apache.org/jira/browse/TAP5-993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12803748#action_12803748 ] Thiago H. de Paula Figueiredo commented on TAP5-993: Is this issue cover just tapestry-core or it also covers proxy creation in tapestry-ioc? Reorganize ComponentClassTransformWorkers to start moving away from Javassist - Key: TAP5-993 URL: https://issues.apache.org/jira/browse/TAP5-993 Project: Tapestry 5 Issue Type: Improvement Components: tapestry-core Affects Versions: 5.2.0 Reporter: Howard M. Lewis Ship Assignee: Howard M. Lewis Ship Begin moving code into forms that can be implemented without Javassist, by creating new methods on ClassTransformation. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-1032) Reporting validation exceptions by throwing an exception is bad form: allow for returning a value instead
[ https://issues.apache.org/jira/browse/TAP5-1032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12838051#action_12838051 ] Thiago H. de Paula Figueiredo commented on TAP5-1032: - Couldn't we use the approach of creating a Translator and Validator subinterfaces and adding the improved method signatures on them? Reporting validation exceptions by throwing an exception is bad form: allow for returning a value instead - Key: TAP5-1032 URL: https://issues.apache.org/jira/browse/TAP5-1032 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.2.0 Reporter: Howard M. Lewis Ship From the Dept. Of We did this in T4 and didn't know it was brain damaged then. ... various APIs related to translation and validation work by throwing a ValidationException which is nothing more than a wrapper around an error message string. It would be nice to allow, in some compatible way, allow methods to simply return the exception, or even just the string for the exception, rather than throwing an exception, which is very inefficient. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (TAP5-1071) [GsoC] create nifty components (multiple students possible)
[ https://issues.apache.org/jira/browse/TAP5-1071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thiago H. de Paula Figueiredo reassigned TAP5-1071: --- Assignee: Thiago H. de Paula Figueiredo [GsoC] create nifty components (multiple students possible) --- Key: TAP5-1071 URL: https://issues.apache.org/jira/browse/TAP5-1071 Project: Tapestry 5 Issue Type: Task Affects Versions: 5.2 Reporter: Ulrich Stärk Assignee: Thiago H. de Paula Figueiredo Tapestry is lacking some nice-to-have components. We put together a list and students wanting to pursue this task must choose at least two of them for their assignment (the multi select and google maps component count as one). The following components are available: - Google maps - Chart (via JFreeChart, resembling JFreeCharts ChartPanel) - JavaScript-only PDF viewer component - multi select (TAP5-148) - Components or mixins for Scriptaculous effects (show, hide, slide up, slide down etc). - dragdrop Palette - Components wrapping Scriptaculous's Ajax.InPlaceEditor, Ajax.InPlaceCollectionEditor, Autocompleter.Local, and Slider. - A SelectWithAutocomplete component that chooses an object, but uses autocompletion to find them (good for selects with lots of options). - A ListReorder component using Scriptaculous drag and drop. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (TAP5-1073) [GSoC] Create JasperReports integration
[ https://issues.apache.org/jira/browse/TAP5-1073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thiago H. de Paula Figueiredo reassigned TAP5-1073: --- Assignee: Thiago H. de Paula Figueiredo [GSoC] Create JasperReports integration --- Key: TAP5-1073 URL: https://issues.apache.org/jira/browse/TAP5-1073 Project: Tapestry 5 Issue Type: Task Affects Versions: 5.2 Reporter: Ulrich Stärk Assignee: Thiago H. de Paula Figueiredo -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (TAP5-1072) [GSoC] Create EJB3 integration
[ https://issues.apache.org/jira/browse/TAP5-1072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thiago H. de Paula Figueiredo reassigned TAP5-1072: --- Assignee: Thiago H. de Paula Figueiredo [GSoC] Create EJB3 integration -- Key: TAP5-1072 URL: https://issues.apache.org/jira/browse/TAP5-1072 Project: Tapestry 5 Issue Type: Task Affects Versions: 5.2 Reporter: Ulrich Stärk Assignee: Thiago H. de Paula Figueiredo Enable injection of EJB3 beans into services, pages, components. Much like the existing Spring integration. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (TAP5-1082) Integrate existing list: binding sample code
[ https://issues.apache.org/jira/browse/TAP5-1082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thiago H. de Paula Figueiredo closed TAP5-1082. --- Resolution: Invalid The prop binding already supports lists: [property1, methodCall()]. See http://tapestry.apache.org/tapestry5.1/guide/propexp.html. Please post suggestions in the mailing list before posting them here. ;) Integrate existing list: binding sample code Key: TAP5-1082 URL: https://issues.apache.org/jira/browse/TAP5-1082 Project: Tapestry 5 Issue Type: Improvement Affects Versions: 5.2.0 Reporter: Pierce Wetter http://wiki.apache.org/tapestry/Tapestry5HowToAddBindingPrefix list: is very useful. Seems like an obvious thing for inclusion. For the general purpose case of building complex structures, yaml: would be possible, let me know if you want a sample implementation. Pierce -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-857) Exclude recursion detection during initial render on blocks that are used for zone updates.
[ https://issues.apache.org/jira/browse/TAP5-857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12869598#action_12869598 ] Thiago H. de Paula Figueiredo commented on TAP5-857: Page, components and templates int Tapestry have static structure.The recursion check can't be removed because it prevents infinite loops to happen. Instead of using recursion in the template, do that in the component class using methods that handle the rendering events. Exclude recursion detection during initial render on blocks that are used for zone updates. --- Key: TAP5-857 URL: https://issues.apache.org/jira/browse/TAP5-857 Project: Tapestry 5 Issue Type: New Feature Components: tapestry-core Affects Versions: 5.1 Reporter: Seth Call Currently it is not possible to define a t:block that uses a particular component when that component is already above in the hierarchy, because Tapestry will detect this as a recursion. However, if this recursion-causing block is only to be used as responses to a zone update, then ideally it wouldn't cause a recursion to be detected. Say for instance this were possible: t:zoneBlock ... t:zoneBlock Where t:zoneBlock is identical to t:block except it can only be used as the response to a zone update, and assembly of the page would know to exclude the contents of that block when it's a normal full page render to avoid the initial reason the recursion detection was added in the first place (runaway rendering issues). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-857) Exclude recursion detection during initial render on blocks that are used for zone updates.
[ https://issues.apache.org/jira/browse/TAP5-857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12869602#action_12869602 ] Thiago H. de Paula Figueiredo commented on TAP5-857: Seth, Tapestry must be sure that no component has an instance of itself to avoid infinite loops, so the check can't be removed. Have you tried to put the block outside the component? You don't need to put it inside. By the way, please post suggestions in the users mailing list first, as it's a way better place to discuss. Exclude recursion detection during initial render on blocks that are used for zone updates. --- Key: TAP5-857 URL: https://issues.apache.org/jira/browse/TAP5-857 Project: Tapestry 5 Issue Type: New Feature Components: tapestry-core Affects Versions: 5.1 Reporter: Seth Call Currently it is not possible to define a t:block that uses a particular component when that component is already above in the hierarchy, because Tapestry will detect this as a recursion. However, if this recursion-causing block is only to be used as responses to a zone update, then ideally it wouldn't cause a recursion to be detected. Say for instance this were possible: t:zoneBlock ... t:zoneBlock Where t:zoneBlock is identical to t:block except it can only be used as the response to a zone update, and assembly of the page would know to exclude the contents of that block when it's a normal full page render to avoid the initial reason the recursion detection was added in the first place (runaway rendering issues). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TAP5-1172) By default, all URLs that do not exist are homepage aliasses
[ https://issues.apache.org/jira/browse/TAP5-1172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thiago H. de Paula Figueiredo resolved TAP5-1172. - Resolution: Duplicate Duplicate of https://issues.apache.org/jira/browse/TAP5-879. Thanks Christophe for the tip! By default, all URLs that do not exist are homepage aliasses Key: TAP5-1172 URL: https://issues.apache.org/jira/browse/TAP5-1172 Project: Tapestry 5 Issue Type: Improvement Components: tapestry-core Affects Versions: 5.2.0, 5.2, 5.1.0.0, 5.1.0.1, 5.1.0.2, 5.1.0.3, 5.1.0.4, 5.1.0.5, 5.1.0.6, 5.1.0.7, 5.1.0.8, 5.1, 5.0.15, 5.0.16, 5.0.17, 5.0.18, 5.0.19, 5.0.20 Reporter: Tobias Marx By default, URLs that do not exist such as localhost:8080/myapp/somerandomstring are alias pages to the homepage. A 404 should be returned instead. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (TAP5-1243) inPlace Grid component no longer working when creating a displayModel from a beanModelSource in setupRender
[
https://issues.apache.org/jira/browse/TAP5-1243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thiago H. de Paula Figueiredo closed TAP5-1243.
---
Resolution: Invalid
The page's setupRender method and event are not triggered when an AJAX partial
render is done, so the problem is in your code. Just create a getBeanModel()
method to create and return your BeanModel.
In addition, please post a message in the Tapestry users mailing list before
creating an issue here.
inPlace Grid component no longer working when creating a displayModel from a
beanModelSource in setupRender
---
Key: TAP5-1243
URL: https://issues.apache.org/jira/browse/TAP5-1243
Project: Tapestry 5
Issue Type: Bug
Components: tapestry-core
Affects Versions: 5.2
Reporter: Darren Williams
When using the inPlace flag on the Grid Component when using a
beanModelSource an Ajax failure occurs with a render queue error as:
Render queue error in SetupRender[Receipts:receiptgrid]
This works fine if inPlace is set to false.
PAGE
div t:type=Grid t:id=receiptGrid source=licenses inPlace=true
rowsPerPage=10 pagerPosition=bottom row=license model=beanModel
rowIndex=rowIndex rowClass=rowClass
/div
SRC
@Component(id=receiptGrid)
private Grid _grid;
@Inject
private BeanModelSource beanModelSource;
@Property
private BeanModel beanModel;
@Inject
private Messages messages;
public void setupRender() {
logger.warn(Setup);
beanModel=beanModelSource.createDisplayModel(License.class,
messages);
beanModel.include(entered,endDate);
beanModel.add(purchase.orgUnit.name).label(Organization);
beanModel.add(purchase.product.name).label(Product);
beanModel.add(purchase.licenseType.name).label(License);
//sorting
if (_grid.getSortModel().getSortConstraints().isEmpty() ) {
logger.warn(sort constraints);
_grid.getSortModel().updateSort(entered);
//_grid.setSortAscending(false);
}
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAPESTRY-2769) Exception constructing service 'ValueEncoderSource'
[ https://issues.apache.org/jira/browse/TAPESTRY-2769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12909710#action_12909710 ] Thiago H. de Paula Figueiredo commented on TAPESTRY-2769: - This should be posted to the TAP5 project, as TAPESTRY is used to track Tapestry 4. This bug is invalid, as you shouldn't add JARs with Tapestry-IoC modules that you don't use in the classpath. That's how Tapestry-IoC works: you don't need to configure anything for a Tapestry-IoC module to be loaded and be ready to work. Please post your questions in the Tapestry mailing list before posting a JIRA. Exception constructing service 'ValueEncoderSource' --- Key: TAPESTRY-2769 URL: https://issues.apache.org/jira/browse/TAPESTRY-2769 Project: Tapestry Issue Type: Bug Affects Versions: 5.1 Reporter: Tobias Marx Priority: Minor Exception constructing service 'ValueEncoderSource': Error invoking service builder method org.apache.tapestry5.services.TapestryModule.buildValueEncoderSource(Map, InvalidationEventHub) (at TapestryModule.java:1910) (for service 'ValueEncoderSource'): Error invoking service contribution method org.apache.tapestry5.hibernate.HibernateModule.contributeValueEncoderSource(MappedConfiguration, boolean, HibernateSessionSource, Session, TypeCoercer, PropertyAccess, LoggerSource): Exception constructing service 'HibernateSessionSource': Error invoking service builder method org.apache.tapestry5.hibernate.HibernateCoreModule.buildHibernateSessionSource(Logger, List, RegistryShutdownHub) (at HibernateCoreModule.java:123) (for service 'HibernateSessionSource'): JDBC Driver class not found: org.gjt.mm.mysql.Driver. If tapestry-hibernate is added as a dependency - even when not used - Tapestry crashes if no database driver is found - and a nasty server error occurs. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (TAP5-1281) Simplifications for lightweight Tapestry5 projects
[ https://issues.apache.org/jira/browse/TAP5-1281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thiago H. de Paula Figueiredo closed TAP5-1281. --- Resolution: Won't Fix With regard to a global service, Davor Hrg already explained how to achieve that. Having a class per page is one Tapestry architectural decision that was done after analyzing Tapestry 4, which had it. It only increased complexity and made learning Tapestry more complex, not simpler Your example seems to ask for template-driven logic, something that definitely goes against Tapestry's phylosophy. Please post your ideas in the Tapestry dev mailing list before posting here. That is the place to discuss Tapestry features, not here. Simplifications for lightweight Tapestry5 projects -- Key: TAP5-1281 URL: https://issues.apache.org/jira/browse/TAP5-1281 Project: Tapestry 5 Issue Type: New Feature Components: tapestry-core Affects Versions: 5.0.15 Reporter: Tobias Marx Priority: Minor In order to simplify Tapestry5 even further i would like to suggest the following: - auto-creation of empty page and component classes if they don't exist at runtime (to reduce number of lines of code, especially for small projects demos) - being able to reference a global service by default from within the templates where all database queries / persistence queries can be placed This way, you could create quite complex web applications with only a few files: - a layout templates - x template files for all pages (instead of 2*x) - y template files for all components (instead of 2*y) - one global service as an additional file that contains all hibernate/persistance queries This would cater of all users that want to create lightweight websites with only as many lines of code/files as really needed. A lot of website can be implemented just by querying data and displaying them in a template (loop) The idea: - reduce the lines of code for small / medium projects - create even more convincing Tapestry demos (vs. RoR/PHP) - increase acceptance by more users checking Tapestry out for the first time -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-1355) Threading issue with SessionStateObjects
[
https://issues.apache.org/jira/browse/TAP5-1355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12935612#action_12935612
]
Thiago H. de Paula Figueiredo commented on TAP5-1355:
-
Hi, Josh!
Instead of reverting the TAP5-834, which would cause other problems, what about
putting that two statements in a synchronized block?
syncronized (session) {
session.setAttribute(attributeName, null);
session.setAttribute(attributeName, attributeValue);
}
Threading issue with SessionStateObjects
Key: TAP5-1355
URL: https://issues.apache.org/jira/browse/TAP5-1355
Project: Tapestry 5
Issue Type: Bug
Components: tapestry-core
Affects Versions: 5.2.4
Reporter: Moritz Gmelin
Attachments: Screenshot.png.jpg, taptest.tgz
When a page request consists of multiple HTTP request (e.g. page and some
dynamically generated images) and all those requests access a
SessionStateObject, it happens that a new session (with an empty SSO) is
created for some of the request threads.
I was able to create a very simple example to recreate that problem:
-A simple page that displays 20 dynamically generated images in a loop.
-In the page, a SSO, holding a number value is initialized to a random
number.
-Each of the dynamic images read that number and draws it.
-Make sure that a HTTP-Request is made for every image on the page (by
adding some random number to the event link)
The effect that you'll see after some reloads of the page (maybe you need to
reload 30 times) is that some images will draw 0 as SSO value instead of the
number set in the page @BeginRender method. Those fields will be marked in
red in the demo so you can quickly see them.
I definitely beleive that tapestry should take care of this. It is a use case
for SSOs that is probably too common to ignore.
Why can't this be automatically integrated into the ApplicationStateManager?
The demo has been deployed here
http://www.avetana.de/taptest/
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-85) Make Java Class optional for Rendering Pages
[ https://issues.apache.org/jira/browse/TAP5-85?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12935615#action_12935615 ] Thiago H. de Paula Figueiredo commented on TAP5-85: --- I prefer the idea of a Maven plugin that creates the empty classes automatically way more than changing the framework itself, as this would complicate a lot the way pages and components are located. Make Java Class optional for Rendering Pages Key: TAP5-85 URL: https://issues.apache.org/jira/browse/TAP5-85 Project: Tapestry 5 Issue Type: New Feature Affects Versions: 5.0.15 Environment: Microsoft Windows Vista Business Edition, Eclipse 3.3, Maven 2, Jetty 5.5, Tomcat 6 Reporter: Evan M Rawson Priority: Minor You should not need a java class create to view a page. The framework should be able to generate a basic class on the fly. This would aid significantly to the production flow of tapestry applications. Meaning that designers and system architects do not need to setup the basic java class in order to build and test the front end user interface. When a java class representing the page is present then it would override this default generate class that tapestry makes on the fly. EX: right now im creating a pretty decent sized tapestry application (75 to 125 pages). The pages have been mocked up and the interface is being assembled (html/css). I am finding that i am needing to create a bunch of empty java classes in order to view the page to test it; this seems pointless and redundant to me. For example a script in maven could be written to auto generate all of the classes based on the html template dir is stored, saving a few hours of naming and creating. the java developer should not have to create the html pages, technically they should be able to use junit to handle testing their base components which they have created. The backend and frontend should seamlessly integrated with each other. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TAP5-1357) Add ServletException to signature of HttpServletRequestFilter#service
[ https://issues.apache.org/jira/browse/TAP5-1357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thiago H. de Paula Figueiredo updated TAP5-1357: Fix Version/s: (was: 5.2.5) The fix version is only set when a fix is committed to SVN. Add ServletException to signature of HttpServletRequestFilter#service - Key: TAP5-1357 URL: https://issues.apache.org/jira/browse/TAP5-1357 Project: Tapestry 5 Issue Type: Improvement Components: tapestry-core Affects Versions: 5.2.4 Reporter: Alexander Gavrilov It's common practice to wrap some native javax.servlet.Filter implementations into HttpServletRequestFilter and contribute that adapter to HttpServletRequestHandler. Signatures of both Interfaces almost match, but HttpServletRequestFilter does not declare ServletException as possible catched exception in the signature. This means that it's required to wrap ServletExcpetion into some RuntimeException wrapper to rethrow it. As i c there is no propblem to add this kind of ecxeption without break of existig functionality. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] [Closed] (TAP5-1484) update and delete in tapestry framework
[ https://issues.apache.org/jira/browse/TAP5-1484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thiago H. de Paula Figueiredo closed TAP5-1484. --- Resolution: Invalid Questions should be posted in the Tapestry users mailing list, never here. update and delete in tapestry framework --- Key: TAP5-1484 URL: https://issues.apache.org/jira/browse/TAP5-1484 Project: Tapestry 5 Issue Type: Question Components: tapestry-hibernate Affects Versions: 5.2.4 Reporter: Rajendra prakash Priority: Minor I create application in tapestry for inserting some fields in to database with hibernate. I want to know, how to display inserted data in front end and also how to update and delete that inserted data -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (TAP5-1520) ConcurrentModificationException while modify unclaimed private collection from different Threads
[
https://issues.apache.org/jira/browse/TAP5-1520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thiago H. de Paula Figueiredo closed TAP5-1520.
---
Resolution: Invalid
Hi!
The error here is in your code: you should never initialize a field with a
non-atomic value. An event handler like onActivate(), @BeginRender or some
event triggered by Form.
Please post in the user mailing list before posting bugs.
Cheers!
Thiago
ConcurrentModificationException while modify unclaimed private collection
from different Threads
Key: TAP5-1520
URL: https://issues.apache.org/jira/browse/TAP5-1520
Project: Tapestry 5
Issue Type: Bug
Components: tapestry-core
Affects Versions: 5.2.5
Reporter: Maxim Ulanovskiy
TestCase: create two parallel requests to the page bellow
first request to read action - /TestConcurrency.read
second request to write action - /TestConcurrency.write
TestConcurrency.tml:
...
t:actionlink t:id=readread/t:actionlink
t:actionlink t:id=writewrite/t:actionlink
...
public class TestConcurrency {
private ListString testDie = new ArrayListString();
public void onActivate() {
for(int i=0; i1000; i++)
testDie.add(init);
}
void onActionFromRead() {
for(String s : testDie)
System.out.println(s);
}
void onActionFromWrite() {
for(int i=0; i10; i++)
testDie.add(testDie+i);
}
}
From what I've found out with debugger is that direct access to ListString
testDie is replaced with UnclaimedFieldWorker.UnclaimedFieldConduit but when
PerthreadManagerImpl is called it fails to find thread local value in
internal map and returnes default value - the same object for both threads:
public class PerthreadManagerImpl {
T PerThreadValueT createValue(final Object key)
{
return new PerThreadValueT()
{
public T get()
{
return get(null);
}
public T get(T defaultValue)
{
Map map = getPerthreadMap();
// NO SUCH KEY IN map
if (map.containsKey(key))
{
Object storedValue = map.get(key);
if (storedValue == NULL_VALUE)
return null;
return (T) storedValue;
}
return defaultValue;
}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TAP5-999) Implement an agnostic tapestry.js layer + adapters to allow developers to switch from prototype to jquery
[ https://issues.apache.org/jira/browse/TAP5-999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13029911#comment-13029911 ] Thiago H. de Paula Figueiredo commented on TAP5-999: Hi, guys! Have you taken a look in https://github.com/staaky/bridgejs, suggested by Joe Klecko in the dev mailing list? BridgeJS is alpha, but it supports Prototype and jQuery and has a Prototype-like syntax (so it's easier to port the current Tapestry JS code. It could at least provide some inspiration for the Tapestry JavaScript abstraction layer. BridgeJS is licensed under a MIT-style license, so I guess it's compatible with the Apache one. 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 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. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (TAP5-1530) Library of mixins
[
https://issues.apache.org/jira/browse/TAP5-1530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thiago H. de Paula Figueiredo closed TAP5-1530.
---
Resolution: Invalid
Hi!
Please post on the dev or user mailing list before posting a bug.
Since 5.2 it's not possible to add a library with a core mapping.
t:pagelink page=index w:mixins=myMixin.../t:pagelink is wrong: it
should be t:mixins, not w:mixins.
Cheers!
Thiago
Library of mixins
-
Key: TAP5-1530
URL: https://issues.apache.org/jira/browse/TAP5-1530
Project: Tapestry 5
Issue Type: Bug
Components: tapestry-core
Affects Versions: 5.2.5
Reporter: Aleksandar Nikolov
I had developed a library of several mixins in Tapestry v.5.1.0.5. Classes
are packed by maven in a jar file and added to the main project as a maven
dependency. It worked pretty well with Tapestry 5.1.0.5.
I followed the rules at http://tapestry.apache.org/component-libraries.html
and the eldest http://tapestry.apache.org/tapestry5/cookbook/lib.html.
Now I am trying to migrate the library to Tapestry 5.2.5, but found a problem
in loading mixins in the main project:
Case 1: When I use core library mapping in library module class:
public static void
contributeComponentClassResolver(ConfigurationLibraryMapping configuration)
{
configuration.add(new LibraryMapping(core, com.mylib));
}
and template code like this: t:pagelink page=index
t:mixins=myMixin.../t:pagelink then the following exception is thrown:
Caused by: org.apache.tapestry5.ioc.util.UnknownValueException: Unable to
resolve 'myMixin' to a mixin class name.
at
org.apache.tapestry5.internal.services.ComponentClassResolverImpl$7.invoke(ComponentClassResolverImpl.java:516)
at
org.apache.tapestry5.internal.services.ComponentClassResolverImpl$7.invoke(ComponentClassResolverImpl.java:511)
at
org.apache.tapestry5.ioc.internal.util.ConcurrentBarrier.withRead(ConcurrentBarrier.java:85)
at
org.apache.tapestry5.internal.services.ComponentClassResolverImpl.resolveMixinTypeToClassName(ComponentClassResolverImpl.java:509)
at
$ComponentClassResolver_1301a3347ae.resolveMixinTypeToClassName($ComponentClassResolver_1301a3347ae.java)
at
org.apache.tapestry5.internal.pageload.EmbeddedComponentAssemblerImpl.init(EmbeddedComponentAssemblerImpl.java:110)
at
org.apache.tapestry5.internal.pageload.ComponentAssemblerImpl.createEmbeddedAssembler(ComponentAssemblerImpl.java:276)
... 106 more
Case 2: When I use another (my own) library mapping name and template code
like this: t:pagelink page=index w:mixins=myMixin.../t:pagelink
then Tapestry acts as the mixins is not attached to the Pagelink. Just
nothing happens.
The only workaround I found is to move the mixins from the library to the
main project. Then all mixins can be attached. The problem appears only when
the mixins are placed in external library.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (TAP5-1556) Tabs component generates invalid href links (maybe other components too)
[ https://issues.apache.org/jira/browse/TAP5-1556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thiago H. de Paula Figueiredo closed TAP5-1556. --- Resolution: Invalid The URLs mentioned are absolutely valid and they're also needed for supporting users with JavaScript enabled. Please discuss issues in the mailing lists before posting issues in JIRA. Tabs component generates invalid href links (maybe other components too) Key: TAP5-1556 URL: https://issues.apache.org/jira/browse/TAP5-1556 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.2.5 Reporter: Toby Tapestry produces links such as: a id=eventLink_1 onclick=javascript:return Tapestry.waitForPage(event); class=cf_tab href=/index.tabset:clicked/somelink some link /a where the href link contains invalid/non-existent urls. Suggestions are: - in general keep the href empty (href='#') - add (rel=nofollow) (messy solution) - only display hrefs for the case it is enabled (e.g. a deep-link as a fallback for the ajax link is implemented on purpose) Otherwise search engines will index/crawl this urlif an url has no use, it should not be published/linked to. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TAP5-1616) PeriodicExecutor service prevents running T5.3 on GAE
[ https://issues.apache.org/jira/browse/TAP5-1616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13090365#comment-13090365 ] Thiago H. de Paula Figueiredo commented on TAP5-1616: - Hi, Massimo! I'm not sure it would solve the issue: http://code.google.com/appengine/docs/java/runtime.html, section The Sandbox: An App Engine application cannot: (...) * spawn a sub-process or thread. (...) A Java application cannot create a new java.lang.ThreadGroup nor a new java.lang.Thread. These restrictions also apply to JRE classes that make use of threads. For example, an application cannot create a new java.util.concurrent.ThreadPoolExecutor, or a java.util.Timer. An application can perform operations against the current thread, such as Thread.currentThread().dumpStack(). PeriodicExecutor service prevents running T5.3 on GAE - Key: TAP5-1616 URL: https://issues.apache.org/jira/browse/TAP5-1616 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.3 Reporter: Kalle Korhonen Since GAE doesn't allow user-created threads, constructing PeriodicExecutor service fails on GAE, preventing running the whole application on it. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TAP5-1625) RubyonRails-like Asset Pipeline
[ https://issues.apache.org/jira/browse/TAP5-1625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13095407#comment-13095407 ] Thiago H. de Paula Figueiredo commented on TAP5-1625: - Tapestry already combines all JavaScript files in a given page into a single one for a long time. Howard already said he wanted to support something like SCSS in Tapestry. And Tapestry already provides hooks for any asset transformations, so all you're suggesting that isn't provided yet could be provided as a separate project, packaged as a drop-in JAR. RubyonRails-like Asset Pipeline --- Key: TAP5-1625 URL: https://issues.apache.org/jira/browse/TAP5-1625 Project: Tapestry 5 Issue Type: Wish Components: tapestry-core Reporter: Toby Assignee: Howard M. Lewis Ship Priority: Minor see: http://weblog.rubyonrails.org/2011/5/22/rails-3-1-release-candidate The Asset Pipeline The star feature of 3.1 is the asset pipeline powered by Sprockets 2.0. It makes CSS and JavaScript first-class code citizens and enables proper organization, including use in plugins and engines. See my RailsConf keynote for a full tour. This comes with SCSS as the default for stylesheets and CoffeeScript as the default for JavaScript. Much documentation is on the way for this. http://www.youtube.com/watch?v=cGdCI2HhfAU something like this would be nice in Tapestry - at least a way to automatically generate a single JS file to increase load speed would be important as a core-feature. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TAP5-1920) Create old URL rewriter compatibility package for 5.3.4
Thiago H. de Paula Figueiredo created TAP5-1920: --- Summary: Create old URL rewriter compatibility package for 5.3.4 Key: TAP5-1920 URL: https://issues.apache.org/jira/browse/TAP5-1920 Project: Tapestry 5 Issue Type: Improvement Affects Versions: 5.3.4 Reporter: Thiago H. de Paula Figueiredo Priority: Minor Create a separate, optional package so that applications that use the old Tapestry 5.1.0.5 URL rewriter API can be upgraded to T5.3 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TAP5-1920) Create old URL rewriter compatibility package for 5.3.4
[ https://issues.apache.org/jira/browse/TAP5-1920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thiago H. de Paula Figueiredo reassigned TAP5-1920: --- Assignee: Thiago H. de Paula Figueiredo Create old URL rewriter compatibility package for 5.3.4 --- Key: TAP5-1920 URL: https://issues.apache.org/jira/browse/TAP5-1920 Project: Tapestry 5 Issue Type: Improvement Affects Versions: 5.3.4 Reporter: Thiago H. de Paula Figueiredo Assignee: Thiago H. de Paula Figueiredo Priority: Minor Create a separate, optional package so that applications that use the old Tapestry 5.1.0.5 URL rewriter API can be upgraded to T5.3 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TAP5-1932) Exposing the Link in the EventLink component
[
https://issues.apache.org/jira/browse/TAP5-1932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=1327#comment-1327
]
Thiago H. de Paula Figueiredo commented on TAP5-1932:
-
-1 from me. You can use the LinkTransformer API for that or even DOM
rewriting. In addition, protected fields are source of problems are almost
never used in Tapestry code.
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, Ars Machina Tecnologia da Informação Ltda.
http://www.arsmachina.com.br
Exposing the Link in the EventLink component
Key: TAP5-1932
URL: https://issues.apache.org/jira/browse/TAP5-1932
Project: Tapestry 5
Issue Type: Improvement
Components: tapestry-core
Affects Versions: 5.3.3
Reporter: Steve Eynon
Priority: Trivial
I would like to alter the Link in an EventLink via a Mixin - specifically,
remove the LoopBack parameter.
To do this, the AbstractLink.link field needs to be set *before* the link
is rendered and a simple change to
org.apache.tapestry5.corelib.base.AbstractComponentEventLink would accomplish
this:
protected void setupRender() {
super.link = createLink(context);
}
AbstractLink.link would also need to become protected.
I believe the above to be a small yet useful enhancement to the Link
Component API.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (TAP5-1953) Does the cache for resolved page class names grow indefinetly?
[ https://issues.apache.org/jira/browse/TAP5-1953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thiago H. de Paula Figueiredo closed TAP5-1953. --- Resolution: Invalid Please post questions to the Tapestry users mailing list: http://tapestry.apache.org/mailing-lists.html. Does the cache for resolved page class names grow indefinetly? -- Key: TAP5-1953 URL: https://issues.apache.org/jira/browse/TAP5-1953 Project: Tapestry 5 Issue Type: Question Components: tapestry-core Affects Versions: 5.3.3 Reporter: Carsten Klein Having implemented a decorator for the ComponentClassResolver service, I noticed that my advises and the delegates thereof will be called only during initial resolve of the page class name for a given request path. I wonder if the cache, which prevents subsequent calls to the custom resolver between requests, does grow indefinitely, and if so, would it be possible to change it so, as to not consume all of the available memory in situations of both high load and indefinite numbers of available request paths? Also, I have been unable to find the class/method responsible for caching the results from my custom resolver to this point. Could you please point me to where I may find the caching logic? TIA and keep up the great work! -- Carsten -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TAP5-2029) JPA annotations expose implementation details in service interfaces
[
https://issues.apache.org/jira/browse/TAP5-2029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thiago H. de Paula Figueiredo updated TAP5-2029:
Component/s: (was: tapestry-jpa)
tapestry-ioc
Changing the component from tapestry-jpa to tapestry-ioc as this is actually a
shortcoming in Tapestry-IoC.
JPA annotations expose implementation details in service interfaces
---
Key: TAP5-2029
URL: https://issues.apache.org/jira/browse/TAP5-2029
Project: Tapestry 5
Issue Type: Improvement
Components: tapestry-ioc
Affects Versions: 5.3.6
Reporter: John Coleman
Priority: Minor
The commit after and persistence context annotations are required on the
service interface definition thereby exposing internal implementation details
(see below example from docs). Details of implementation should be hidden at
the interface level, both these annotations break the rule.
Perhaps this code could appear in the Impl classes, or be provided in
configuration somehow?
public interface UserDAO {
@CommitAfter
@PersistenceContext(unitName = DemoUnit)
void add(User user);
--
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-2164) Bean validation doesn't work when just min, not max, defined in @Size
Thiago H. de Paula Figueiredo created TAP5-2164: --- Summary: Bean validation doesn't work when just min, not max, defined in @Size Key: TAP5-2164 URL: https://issues.apache.org/jira/browse/TAP5-2164 Project: Tapestry 5 Issue Type: Bug Components: tapestry-beanvalidator Affects Versions: 5.4 Reporter: Thiago H. de Paula Figueiredo If you use @Size defining without defining the max attribute, the max validation isn't added, but the data-range-max isn't added and the call to rangeValue(element, data-range-max, Number.MAX_VALUE) ends up returning NaN instead of Number.MAX_VALUE and the value is always considered invalid. -- 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] [Resolved] (TAP5-2175) Bean Validation fails when @Size(min) is not specified but max is specified
[ https://issues.apache.org/jira/browse/TAP5-2175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thiago H. de Paula Figueiredo resolved TAP5-2175. - Resolution: Duplicate Duplicate of TAP5-2164. Bean Validation fails when @Size(min) is not specified but max is specified --- Key: TAP5-2175 URL: https://issues.apache.org/jira/browse/TAP5-2175 Project: Tapestry 5 Issue Type: Bug Components: tapestry-beanvalidator Affects Versions: 5.4 Reporter: Lenny Primak Priority: Critical beanvalidator-validation.js has a bug in rangeValue() if(v===null) // should be if(v==null) In the current state, it will return undefined if @Size(min) is not present, thus failing for perfectly valid input -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TAP5-2164) Bean validation doesn't work when just min, not max, defined in @Size
[ https://issues.apache.org/jira/browse/TAP5-2164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thiago H. de Paula Figueiredo resolved TAP5-2164. - Resolution: Duplicate Duplicate of TAP5-2158. Bean validation doesn't work when just min, not max, defined in @Size - Key: TAP5-2164 URL: https://issues.apache.org/jira/browse/TAP5-2164 Project: Tapestry 5 Issue Type: Bug Components: tapestry-beanvalidator Affects Versions: 5.4 Reporter: Thiago H. de Paula Figueiredo If you use @Size defining without defining the max attribute, the max validation isn't added, but the data-range-max isn't added and the call to rangeValue(element, data-range-max, Number.MAX_VALUE) ends up returning NaN instead of Number.MAX_VALUE and the value is always considered invalid. -- 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-1767) Making URLRewrite optionally available for smooth upgrading
[ https://issues.apache.org/jira/browse/TAP5-1767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thiago H. de Paula Figueiredo closed TAP5-1767. --- Resolution: Fixed Fix Version/s: 5.3 5.2 5.4 The URL rewriter API code from 5.1.0.5 was copied and adapted for use with Tapestry 5.2+ in a separate package. Sources at https://github.com/thiagohp/tapestry-url-rewriter/, JAR at the Maven Central Repository: dependency groupIdbr.com.arsmachina/groupId artifactIdtapestry-url-rewriter/artifactId version1.0.1/version /dependency Notice version 2.0.0 of tapestry-url-rewriter is not backward-compatible with 1.0.1, as 2.0.0 removes all the outgoing URL support, as LinkTransformer is better at it. 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 Assignee: Thiago H. de Paula Figueiredo Labels: URLrewrie Fix For: 5.4, 5.2, 5.3 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 was sent by Atlassian JIRA (v6.1#6144)
[jira] [Assigned] (TAP5-1767) Making URLRewrite optionally available for smooth upgrading
[ https://issues.apache.org/jira/browse/TAP5-1767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thiago H. de Paula Figueiredo reassigned TAP5-1767: --- Assignee: Thiago H. de Paula Figueiredo 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 Assignee: Thiago H. de Paula Figueiredo 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 was sent by Atlassian JIRA (v6.1#6144)
[jira] [Assigned] (TAP5-2029) JPA annotations expose implementation details in service interfaces
[
https://issues.apache.org/jira/browse/TAP5-2029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thiago H. de Paula Figueiredo reassigned TAP5-2029:
---
Assignee: Thiago H. de Paula Figueiredo
JPA annotations expose implementation details in service interfaces
---
Key: TAP5-2029
URL: https://issues.apache.org/jira/browse/TAP5-2029
Project: Tapestry 5
Issue Type: Improvement
Components: tapestry-ioc
Affects Versions: 5.3.6
Reporter: John Coleman
Assignee: Thiago H. de Paula Figueiredo
Priority: Minor
The commit after and persistence context annotations are required on the
service interface definition thereby exposing internal implementation details
(see below example from docs). Details of implementation should be hidden at
the interface level, both these annotations break the rule.
Perhaps this code could appear in the Impl classes, or be provided in
configuration somehow?
public interface UserDAO {
@CommitAfter
@PersistenceContext(unitName = DemoUnit)
void add(User user);
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Resolved] (TAP5-1951) Allow multiple different service interface implementations to be registered using identical service identifier strings
[ https://issues.apache.org/jira/browse/TAP5-1951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thiago H. de Paula Figueiredo resolved TAP5-1951. - Resolution: Won't Fix The feature suggested here can be better implemented with marker annotations instead of using service id for selecting one implementation from many of the same service interface. Allow multiple different service interface implementations to be registered using identical service identifier strings -- Key: TAP5-1951 URL: https://issues.apache.org/jira/browse/TAP5-1951 Project: Tapestry 5 Issue Type: Improvement Components: tapestry-ioc Affects Versions: 5.3.3 Reporter: Carsten Klein Priority: Minor As of now, tapestry-ioc maintains a global namespace for all of the registered service ids. This makes it impossible to bind different service interfaces and their implementations thereof using the same service identifiers, e.g. binder.bind(IFirstService.class, FirstServiceDefaultImpl.class).withId(default); binder.bind(ISecondService.class, SecondServiceDefaultImpl.class).withId(default); This will result in an exception on container and application startup. I think that, having played around with Plexus for a while, it would be nice to allow duplicate service ids for different service interfaces, as it makes documentation and using one's APIs a lot easier, when one can refer to default instead of for example secondservice.default and so on. As for the performance impact, one could always use the fully qualified name of the service interface class and append to it the service identifier. This is very similar to the user disambiguating the service identifiers by herself, except that tapestry-ioc would use the namespaces provided by the application instead, e.g. when doing binder.bind(...).withId(default); the service binder would then this.registry.registerServiceById(serviceInterfaceClass.getName() + . + serviceId, serviceInterfaceClass, implClass); or something like that. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Assigned] (TAP5-1611) out-of-the-box way in Tapestry for replacing components
[
https://issues.apache.org/jira/browse/TAP5-1611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thiago H. de Paula Figueiredo reassigned TAP5-1611:
---
Assignee: Thiago H. de Paula Figueiredo
out-of-the-box way in Tapestry for replacing components
---
Key: TAP5-1611
URL: https://issues.apache.org/jira/browse/TAP5-1611
Project: Tapestry 5
Issue Type: New Feature
Components: tapestry-ioc
Affects Versions: 5.3
Reporter: Jens Breitenstein
Assignee: Thiago H. de Paula Figueiredo
Priority: Minor
Labels: IOC, component
It would be nice to allow global component replacement by a different
component class (or derived version from the original) compared to the field
type provided. So @InjectComponent would behave more or less like @Inject for
services without the need of Interfaces.
NOTE:
current workaround is decorating ComponentInstantiatorSource
As Thiago outlines my workaround is sub-optimal as it bases on internal
classes which might subject to change without notice. He suggests to have an
Service we can contribute our overrides to. Replaceing components would
introduce a new level of flexibility to change implementations without
touching tml's at all. Naturally ServiceBinder was not my suggested place for
this new kind of binding, seems to be a misunderstanding. From a functional
point of view I was just thinking about something like...
public static void bind(final ComponentBinder binder)
{
binder.bind(ComponentA,class, ComponentBderivedFromA.class);
}
...this, as an example.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (TAP5-64) Support Java Portlet Specification V2 - JSR-286
[ https://issues.apache.org/jira/browse/TAP5-64?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13789143#comment-13789143 ] Thiago H. de Paula Figueiredo commented on TAP5-64: --- Hi, guys! Shouldn't this issue be closed due to the tapestry5-portlet linked above? I haven't used portlets myself, so I'm not the best one to check it. If nobody says no in a couple weeks, I'll close this issue. Support Java Portlet Specification V2 - JSR-286 --- Key: TAP5-64 URL: https://issues.apache.org/jira/browse/TAP5-64 Project: Tapestry 5 Issue Type: New Feature Affects Versions: 5.0.15 Reporter: Jan Vissers Assignee: François Facon Attachments: tapestry_portlet_5.0.15.zip, tapestry_portlet_5.0.18.zip, tapestry_portlet_5.1.0.5.zip Specification will be finished early 2008. We need a framework that allows us to write JSR-286 portlets, would be nice if we could stick with T5 for this. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (TAP5-1624) Add support for overriding default TypeCoercer's coercions
[ https://issues.apache.org/jira/browse/TAP5-1624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13789221#comment-13789221 ] Thiago H. de Paula Figueiredo commented on TAP5-1624: - Denis, is this still an issue? TAP5-1446 is already fixed. Do you still see a need for TypeCoercer coercion overrides? Add support for overriding default TypeCoercer's coercions -- Key: TAP5-1624 URL: https://issues.apache.org/jira/browse/TAP5-1624 Project: Tapestry 5 Issue Type: Improvement Components: tapestry-core Reporter: Denis Stepanov Right now it is imposible to implement TAP5-1446 without changes in Tapestry. It will probably require to add new service TypeCoercerOverride, TyprCoercerImpl will use it to override all tuples with equal sourceType and targetType. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (TAP5-64) Support Java Portlet Specification V2 - JSR-286
[ https://issues.apache.org/jira/browse/TAP5-64?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13789367#comment-13789367 ] Thiago H. de Paula Figueiredo commented on TAP5-64: --- Hello, Pieter! What do you mean by out-of-the-box portlet support? As in tapestry-core itself? I'm sorry, that's not going to happen. Not everybody which uses Tapestry uses portlets, so it doesn't make much sense to put support for it in core. The Tapestry philosophy is to have the basic functionality in tapestry-core and more specific stuff in other JARs, such as tapestry-upload and tapestry-hibernate. If it's about a separate JAR under the Apache Tapestry project, tapestry5-portlet is mostly written by Tapestry committers themselves. In addition, we avoid having too much stuff under the Tapestry project itself because we're all volutaries and we'd need to support that code. I agree with you that tapestry5-porlet should have its JAR in Maven Central Repository. Cheers! Support Java Portlet Specification V2 - JSR-286 --- Key: TAP5-64 URL: https://issues.apache.org/jira/browse/TAP5-64 Project: Tapestry 5 Issue Type: New Feature Affects Versions: 5.0.15 Reporter: Jan Vissers Assignee: François Facon Attachments: tapestry_portlet_5.0.15.zip, tapestry_portlet_5.0.18.zip, tapestry_portlet_5.1.0.5.zip Specification will be finished early 2008. We need a framework that allows us to write JSR-286 portlets, would be nice if we could stick with T5 for this. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (TAP5-1971) HibernateGridDataSource should include some workaround or protection agains wrong Projections.rowCount() result
[ https://issues.apache.org/jira/browse/TAP5-1971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thiago H. de Paula Figueiredo updated TAP5-1971: Priority: Minor (was: Critical) Changing this from critical to minor because the cause of the problem isn't Tapestry, it's Hibernate, and it has an easy workaround. HibernateGridDataSource should include some workaround or protection agains wrong Projections.rowCount() result --- Key: TAP5-1971 URL: https://issues.apache.org/jira/browse/TAP5-1971 Project: Tapestry 5 Issue Type: Improvement Components: tapestry-hibernate Affects Versions: 5.3.3 Reporter: Andrei Arapov Priority: Minor In some cases Hibernate's criteria construction like criteria.setProjection(Projections.rowCount()) returns wrong number of rows. More specifically, for example, if you have some JPA restrictions in you entity annotations (e.g. @ManyToOne @JoinColumn(name = USER_ID, nullable = false) this one! @NonVisual public UserImpl user; ) then such restrictions (for USER_ID is not null) will not be taken in account while building row-count query. Vice-versa hibernate will use such restrictions in query for getting LIST of entities. This behaivour fails, when in entity table appear (e.g. some old) rows with NULL in USER_ID (e.g.) columns. This is known, but not solved problem for Hibernate, see: https://hibernate.onjira.com/browse/HHH-3238 https://hibernate.onjira.com/browse/HHH-2787 https://hibernate.onjira.com/browse/HHH-3206 https://hibernate.onjira.com/browse/HHH-5719 https://hibernate.onjira.com/browse/HHH-4829 https://hibernate.onjira.com/browse/HHH-7438 There by we go into error in HibernateGridDataSource.getRowValue(int index) method: it throws IndexOutOfBoundsException due to row count number is bigger than actual number of selected rows. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (TAP5-64) Support Java Portlet Specification V2 - JSR-286
[ https://issues.apache.org/jira/browse/TAP5-64?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13789439#comment-13789439 ] Thiago H. de Paula Figueiredo commented on TAP5-64: --- Hello, Pieter! If tapestry5-portlet is working and if it had its JARs in the Maven Central Respository, would you be satisfied? As I said in the message above, we cannot have too much stuff under the Tapestry project itself because otherwise we wouldn't have the time to support all that. Cheers! Support Java Portlet Specification V2 - JSR-286 --- Key: TAP5-64 URL: https://issues.apache.org/jira/browse/TAP5-64 Project: Tapestry 5 Issue Type: New Feature Affects Versions: 5.0.15 Reporter: Jan Vissers Assignee: François Facon Attachments: tapestry_portlet_5.0.15.zip, tapestry_portlet_5.0.18.zip, tapestry_portlet_5.1.0.5.zip Specification will be finished early 2008. We need a framework that allows us to write JSR-286 portlets, would be nice if we could stick with T5 for this. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (TAP5-2176) SymbolBeanFactoryPostProcessor breaks property placeholder in spring when using default values
[ https://issues.apache.org/jira/browse/TAP5-2176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thiago H. de Paula Figueiredo updated TAP5-2176: Priority: Minor (was: Major) Priority changed to Minor because it has an easy workaround. SymbolBeanFactoryPostProcessor breaks property placeholder in spring when using default values -- Key: TAP5-2176 URL: https://issues.apache.org/jira/browse/TAP5-2176 Project: Tapestry 5 Issue Type: Bug Reporter: Joris Vanleene Priority: Minor When a property used in a spring config xml has a default value tapestry will set this as the value of the property, then the spring property placeholder will run but he will not replace the property with the correct value from a properties file because it is already set by tapestry with the default value! Tapestry Spring Module SymbolBeanFactoryPostProcessor should only touch properties that start with 'tapestry.' -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (TAP5-1920) Create old URL rewriter compatibility package for 5.3.4
[ https://issues.apache.org/jira/browse/TAP5-1920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13789502#comment-13789502 ] Thiago H. de Paula Figueiredo commented on TAP5-1920: - Implemented in https://github.com/thiagohp/tapestry-url-rewriter. dependency groupIdbr.com.arsmachina/groupId artifactIdtapestry-url-rewriter/artifactId version1.0.1/version /dependency Create old URL rewriter compatibility package for 5.3.4 --- Key: TAP5-1920 URL: https://issues.apache.org/jira/browse/TAP5-1920 Project: Tapestry 5 Issue Type: Improvement Affects Versions: 5.3.4 Reporter: Thiago H. de Paula Figueiredo Assignee: Thiago H. de Paula Figueiredo Priority: Minor Fix For: 5.3.1, 5.4, 5.2.0 Create a separate, optional package so that applications that use the old Tapestry 5.1.0.5 URL rewriter API can be upgraded to T5.3 -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (TAP5-1920) Create old URL rewriter compatibility package for 5.3.4
[ https://issues.apache.org/jira/browse/TAP5-1920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thiago H. de Paula Figueiredo resolved TAP5-1920. - Resolution: Implemented Fix Version/s: 5.3.1 5.2.0 5.4 Create old URL rewriter compatibility package for 5.3.4 --- Key: TAP5-1920 URL: https://issues.apache.org/jira/browse/TAP5-1920 Project: Tapestry 5 Issue Type: Improvement Affects Versions: 5.3.4 Reporter: Thiago H. de Paula Figueiredo Assignee: Thiago H. de Paula Figueiredo Priority: Minor Fix For: 5.4, 5.2.0, 5.3.1 Create a separate, optional package so that applications that use the old Tapestry 5.1.0.5 URL rewriter API can be upgraded to T5.3 -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (TAP5-2029) Copy annotations from service implementation to proxy (was JPA annotations expose implementation details in service interfaces)
[
https://issues.apache.org/jira/browse/TAP5-2029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thiago H. de Paula Figueiredo updated TAP5-2029:
Summary: Copy annotations from service implementation to proxy (was JPA
annotations expose implementation details in service interfaces) (was: JPA
annotations expose implementation details in service interfaces)
Copy annotations from service implementation to proxy (was JPA annotations
expose implementation details in service interfaces)
---
Key: TAP5-2029
URL: https://issues.apache.org/jira/browse/TAP5-2029
Project: Tapestry 5
Issue Type: Improvement
Components: tapestry-ioc
Affects Versions: 5.3.6
Reporter: John Coleman
Assignee: Thiago H. de Paula Figueiredo
Priority: Minor
The commit after and persistence context annotations are required on the
service interface definition thereby exposing internal implementation details
(see below example from docs). Details of implementation should be hidden at
the interface level, both these annotations break the rule.
Perhaps this code could appear in the Impl classes, or be provided in
configuration somehow?
public interface UserDAO {
@CommitAfter
@PersistenceContext(unitName = DemoUnit)
void add(User user);
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (TAP5-64) Support Java Portlet Specification V2 - JSR-286
[ https://issues.apache.org/jira/browse/TAP5-64?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13789511#comment-13789511 ] Thiago H. de Paula Figueiredo commented on TAP5-64: --- What if the Tapestry documentation itself had a Recommended third-party modules section? For example, tapestry-security, the integration with Apache Shiro, isn't part of the Tapestry project itself but it's written by a committer of both Tapestry and Shiro and it's widely trusted. Latest released Tapestry version is 5.3.6 and tapestry5-portlet says it supports them. Support Java Portlet Specification V2 - JSR-286 --- Key: TAP5-64 URL: https://issues.apache.org/jira/browse/TAP5-64 Project: Tapestry 5 Issue Type: New Feature Affects Versions: 5.0.15 Reporter: Jan Vissers Assignee: François Facon Attachments: tapestry_portlet_5.0.15.zip, tapestry_portlet_5.0.18.zip, tapestry_portlet_5.1.0.5.zip Specification will be finished early 2008. We need a framework that allows us to write JSR-286 portlets, would be nice if we could stick with T5 for this. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (TAP5-64) Support Java Portlet Specification V2 - JSR-286
[ https://issues.apache.org/jira/browse/TAP5-64?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13789553#comment-13789553 ] Thiago H. de Paula Figueiredo commented on TAP5-64: --- In addition, Tapestry *does* support portlets, but by using a thirdy-party module. Support Java Portlet Specification V2 - JSR-286 --- Key: TAP5-64 URL: https://issues.apache.org/jira/browse/TAP5-64 Project: Tapestry 5 Issue Type: New Feature Affects Versions: 5.0.15 Reporter: Jan Vissers Assignee: François Facon Attachments: tapestry_portlet_5.0.15.zip, tapestry_portlet_5.0.18.zip, tapestry_portlet_5.1.0.5.zip Specification will be finished early 2008. We need a framework that allows us to write JSR-286 portlets, would be nice if we could stick with T5 for this. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (TAP5-1611) out-of-the-box way in Tapestry for replacing components
[
https://issues.apache.org/jira/browse/TAP5-1611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13795323#comment-13795323
]
Thiago H. de Paula Figueiredo commented on TAP5-1611:
-
I think Barry's suggested additional checks would be quite difficult and
time-consuming to implement, if even feasible. Regarding @InjectContainer and
@InjectComponent, this kind of error can already happen in Tapestry right now,
without component substitution, so I think no added checks are needed. Anyway,
the ideal is to have the field as generic (to the top of the class/interface
hierarchy) as possible, as in pure, non-Tapestry OOP best practices, avoiding
concrete classes and favoring interfaces when possible (Field instead of
TextField, etc).
I agree with Lance's suggestion that the contribution to the service should be
a logical name, not the page/component/mixin class, as the service
(ComponentClassResolver) methods will need to advise take a logical name as a
parameter : resolvePageNameToClassName(String),
resolveComponentTypeToClassName(String), resolveMixinTypeToClassName(String).
out-of-the-box way in Tapestry for replacing components
---
Key: TAP5-1611
URL: https://issues.apache.org/jira/browse/TAP5-1611
Project: Tapestry 5
Issue Type: New Feature
Components: tapestry-ioc
Affects Versions: 5.3
Reporter: Jens Breitenstein
Assignee: Thiago H. de Paula Figueiredo
Priority: Minor
Labels: IOC, component
It would be nice to allow global component replacement by a different
component class (or derived version from the original) compared to the field
type provided. So @InjectComponent would behave more or less like @Inject for
services without the need of Interfaces.
NOTE:
current workaround is decorating ComponentInstantiatorSource
As Thiago outlines my workaround is sub-optimal as it bases on internal
classes which might subject to change without notice. He suggests to have an
Service we can contribute our overrides to. Replaceing components would
introduce a new level of flexibility to change implementations without
touching tml's at all. Naturally ServiceBinder was not my suggested place for
this new kind of binding, seems to be a misunderstanding. From a functional
point of view I was just thinking about something like...
public static void bind(final ComponentBinder binder)
{
binder.bind(ComponentA,class, ComponentBderivedFromA.class);
}
...this, as an example.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (TAP5-1611) out-of-the-box way in Tapestry for replacing components
[
https://issues.apache.org/jira/browse/TAP5-1611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13795324#comment-13795324
]
Thiago H. de Paula Figueiredo commented on TAP5-1611:
-
Barry, I'm also very against the idea of a fallback. I hate silent failures,
and that would be one.
out-of-the-box way in Tapestry for replacing components
---
Key: TAP5-1611
URL: https://issues.apache.org/jira/browse/TAP5-1611
Project: Tapestry 5
Issue Type: New Feature
Components: tapestry-ioc
Affects Versions: 5.3
Reporter: Jens Breitenstein
Assignee: Thiago H. de Paula Figueiredo
Priority: Minor
Labels: IOC, component
It would be nice to allow global component replacement by a different
component class (or derived version from the original) compared to the field
type provided. So @InjectComponent would behave more or less like @Inject for
services without the need of Interfaces.
NOTE:
current workaround is decorating ComponentInstantiatorSource
As Thiago outlines my workaround is sub-optimal as it bases on internal
classes which might subject to change without notice. He suggests to have an
Service we can contribute our overrides to. Replaceing components would
introduce a new level of flexibility to change implementations without
touching tml's at all. Naturally ServiceBinder was not my suggested place for
this new kind of binding, seems to be a misunderstanding. From a functional
point of view I was just thinking about something like...
public static void bind(final ComponentBinder binder)
{
binder.bind(ComponentA,class, ComponentBderivedFromA.class);
}
...this, as an example.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (TAP5-1611) out-of-the-box way in Tapestry for replacing components
[
https://issues.apache.org/jira/browse/TAP5-1611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13795377#comment-13795377
]
Thiago H. de Paula Figueiredo commented on TAP5-1611:
-
Barry, we can change the out-of-the-box property edition blocks so they use
AbstractField or Field instead of TextField, TextArea et al. From a first look,
it doesn't seem that change would cause any problems. If they do, like it may
be the case for DateField. Anyway, you can override the edition block for any
type without much effort. Anyway x2, besides DateField, I don't see this kind
of case happening often.
out-of-the-box way in Tapestry for replacing components
---
Key: TAP5-1611
URL: https://issues.apache.org/jira/browse/TAP5-1611
Project: Tapestry 5
Issue Type: New Feature
Components: tapestry-ioc
Affects Versions: 5.3
Reporter: Jens Breitenstein
Assignee: Thiago H. de Paula Figueiredo
Priority: Minor
Labels: IOC, component
It would be nice to allow global component replacement by a different
component class (or derived version from the original) compared to the field
type provided. So @InjectComponent would behave more or less like @Inject for
services without the need of Interfaces.
NOTE:
current workaround is decorating ComponentInstantiatorSource
As Thiago outlines my workaround is sub-optimal as it bases on internal
classes which might subject to change without notice. He suggests to have an
Service we can contribute our overrides to. Replaceing components would
introduce a new level of flexibility to change implementations without
touching tml's at all. Naturally ServiceBinder was not my suggested place for
this new kind of binding, seems to be a misunderstanding. From a functional
point of view I was just thinking about something like...
public static void bind(final ComponentBinder binder)
{
binder.bind(ComponentA,class, ComponentBderivedFromA.class);
}
...this, as an example.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
