rendering is a very complex process that consists of many parts.
a) i doubt any "little programming" will be able to replace the
rendering process
b) delegating to some interface in application would imply that all
components render the same. this is of course completely false,
various component subclasses override certain callbacks of the
rendering process to alter their rendering behavior. this doesnt
really jive with delegating to one place...
c) i was not aware there was any kind of "hierarchy" to replace in
struts applciations
something simple like automatic markupid generation can be moved out
of component into some factory interface, but then you would have to
provide a valid usecase for us to add that additional complexity. eg
suppose we have
IMarkupIdGenerator { String getMarkupForComponent(Component c); }
what would your implementation look like?
-igor
On Thu, Mar 6, 2008 at 1:43 PM, JP Saraceno
<[EMAIL PROTECTED]> wrote:
>
> I ran into the issue described in this topic:
>
> http://www.nabble.com/getMarkupId-doesn%27t-return-the-id-from-the-markup-td11277169i20.html
>
> Basically wicket started to override the markup IDs with auto-generated
> stuff, and I needed to reclaim the ownership of those IDs.
>
> So, as I wait for a solution/patch from the wicket dev team, I was trying to
> figure out a workaround that allows me to adapt my application without the
> need of do lots of setMarkupId() calls or to redefine the whole component
> hierarchy changing the default value of setOutputMarkupId() to true.
>
> Then I digged into the code, looking for a place to change the markup Id
> overriding policy itself. In general when I do that stuff I expect not to
> change the jar itself, but to identify the piece that I want to change and
> build my own extension/implementation of it without touching the code base.
>
> To my dissapointment, I've found that the whole rendering policy is inside
> the very Cojmponent class, so if I want to change it, I need to redefine the
> whole component hierarchy. This made me remember... struts.
>
> What do you guys think of the idea of having this kind of responsibilities
> delegated in separated pieces that we can inject and change? Say, Component
> should rely on a "Renderer", or "RenderedPolicy" interface, and the package
> should provide a default implementation of the interface that one could
> override through some little programming on the WebApplication extension you
> made for the app.
> --
> View this message in context:
> http://www.nabble.com/Start-delegating-stuff-out-of-Component--tp15884385p15884385.html
> Sent from the Wicket - Dev mailing list archive at Nabble.com.
>
>
