[
https://issues.apache.org/jira/browse/CLK-524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12700986#action_12700986
]
Joseph Schmidt commented on CLK-524:
------------------------------------
> Have checked in this change which can be reviewed here:
> http://fisheye6.atlassian.com/changelog/click/?cs=766349
> Would appreciate any feedback.
I just have the feeling this entire ControlRegistry is growing over our heads.
Taking a look at many older applications with older Click releases, I can't
stop thinking that Click was very good for years without it.
I also received a few custom components for maintenance and I don't think this
change (nor ControlRegistry) is of any needed in them (or maybe simply I'm not
getting the entire concept).
Of course, I'm a newbie, but my impression is that most of the advantages you
list are for ClickClick. Is it possible that the problem is with the ClickClick
approach(and that should be changed), not with Click?
Many parts of Click are simple to understand and nice, but this one is not.
Making it even more complex, is just a guarantee that users like me will
understand it even less.
>From what I saw, one of the most important parts of Click is backward
>compatibility. For this however, Click should remain very simple, otherwise it
>will get big and bloated(and it can't afford "published" experiments).
>Tapestry on the other and can do this since with every new version they throw
>aboard the entire compatibility, so "experiments" if go wrong are not that a
>problem - and history shows that complex things always go wrong sooner or
>later (latest one: with T5.2 they'll trow maven away now :) )
My wish is when I look at the Click source code to be able to quickly
understand what's up there - cause only so I have a good feeling when I use it
in applications (otherwise I have that "black box feeling" - and it's not fun
).
I think like this, are most users - those who prefer complex thing have a very
huge choice of concurrent frameworks :).
> Improve ControlRegistry to support custom callback events
> ---------------------------------------------------------
>
> Key: CLK-524
> URL: https://issues.apache.org/jira/browse/CLK-524
> Project: Click
> Issue Type: Improvement
> Reporter: Bob Schellink
> Assignee: Bob Schellink
> Fix For: 2.1.0
>
>
> Improve ControlRegistry to handle callbacks for different events. Currently
> ControlRegistry only supports firing listeners after the onProcess event.
> I have a number of use cases where listeners should fire after the onRender
> event.
> Note: this improvement targets component developers, not users.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
