You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by Markus Jung <ma...@gmail.com> on 2011/07/27 15:26:06 UTC
Public getter for the map of initializer calls in JavaScriptSupport
Hi,
I found a way to enable mixin based protection of the event links rendered
by an AjaxFormLoop component. If there is access to the inits map of the
JavaScriptSupportImpl class, I can modify the links in the mixin.
I have created a patch and opened an issue. I used the Tapestry 5.3.0
release.
https://issues.apache.org/jira/browse/TAP5-1592
In my local build everything works fine, maybe there are also other use
cases for that. Is it possible to include this modification or are there any
side effects if the inits map is modified?
BR
Markus
--
View this message in context: http://tapestry.1045711.n5.nabble.com/Public-getter-for-the-map-of-initializer-calls-in-JavaScriptSupport-tp4638746p4638746.html
Sent from the Tapestry - Dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Public getter for the map of initializer calls in
JavaScriptSupport
Posted by Markus Jung <ma...@gmail.com>.
Thanks for the feedback, I have updated the issue
https://issues.apache.org/jira/browse/TAP5-1592 with a new solution.
Since it is not a good approach to expose the initializer call map by a
getter I want to explain the background a little bit more. My problem is
that I want to use my CSRF protection mixin for the AjaxFormLoop component,
especially for the RemoveRowLink component.
Problem 1 - RemoveRowLink component does not render itself:
The problem with the current design is, that the AjaxFormLoop provides the
AjaxFormLoopContext to the RemoveRowLink component. Currently the context
contains the logic to create the javascript event link AND it does also the
rendering. So basically the rendering of the RemoveRowLink component does
not happen in that component and all information used for the render process
is stored in the AjaxFormLoop and the AjaxFormLoopContext. I propose to
refactor the design and to provide all information required to render the
javascript event link in the AjaxFormLoopContext. In this way everything
needed to render javascript event links is available in the RemoveRowLink
component. By using AOP this information can later be reused, e.g. for
mixins.
Problem 2 - JavaScriptSupport does not allow update of any JSON objects
In my mixin I would like to update rendered javascript event links. I
propose an update method that allows doing that for a certain functionName.
I have implemented a method that takes a Comparator<JSONObject> object to
identify the JSONObject that should be replaced.
I attached a new patch, that demonstrates a possible solution.
--
View this message in context: http://tapestry.1045711.n5.nabble.com/Public-getter-for-the-map-of-initializer-calls-in-JavaScriptSupport-tp4638746p4640414.html
Sent from the Tapestry - Dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Public getter for the map of initializer calls in
JavaScriptSupport
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
On Wed, 27 Jul 2011 10:26:06 -0300, Markus Jung <ma...@gmail.com>
wrote:
> Hi,
Hi!
> I found a way to enable mixin based protection of the event links
> rendered by an AjaxFormLoop component. If there is access to the inits
> map of the
> JavaScriptSupportImpl class, I can modify the links in the mixin.
Couldn't you find a solution that doesn't involve changing the inits?
Using addScript() isntead of addInit()?
I think adding this getter returning the Map breaks encapsulation too hard
and opens Tapestry for subtle, difficult to track bugs. I'd add add() and
set() methods delegating to the inits fields instead if access to them is
really, really necessary.
--
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org