You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wicket.apache.org by JP Saraceno <ju...@teracode.com> on 2008/03/06 22:43:02 UTC
Start delegating stuff out of Component?
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.
Re: Start delegating stuff out of Component?
Posted by JP Saraceno <ju...@teracode.com>.
Ok, I really expressed my idea the wrong way with this.
Don't get me wrong guys, I didn't intend to say that your rendering was not
complex, or that I could override it all with little programming. Call this
"Rendering" was actually unhappy, as you point out.
What I was saying is that I could override a specific thing (the generation
of markup Ids, in this case). But if I look for a place to do that I found
it con the very Component class, leaving me with only 2 choices:
* Change Component itself and rebuild the jar: not desirable for obvious
reasons.
* subclass Component: not desirable because it means also subclassing every
component class under Component. That was my analogy with struts where there
is no way to customize specific parts of the building pieces (Actions,
Forms, the RequestProcessor) without subclassing the whole thing.
Matej Knopp-2 wrote:
>
> Our rendering is "little" more complicated than that. Also the markup
> id assignment is not really part of rendering process, it takes place
> sooner. There are technical reasons why it is not possible to preserve
> markup id for components with setOutputMarkupId(true). It's been
> discussed before.
>
--
View this message in context: http://www.nabble.com/Start-delegating-stuff-out-of-Component--tp15884385p15891158.html
Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: Start delegating stuff out of Component?
Posted by Matej Knopp <ma...@gmail.com>.
Our rendering is "little" more complicated than that. Also the markup
id assignment is not really part of rendering process, it takes place
sooner. There are technical reasons why it is not possible to preserve
markup id for components with setOutputMarkupId(true). It's been
discussed before.
-Matej
On Thu, Mar 6, 2008 at 10:43 PM, JP Saraceno
<ju...@teracode.com> 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.
>
>
--
Resizable and reorderable grid components.
http://www.inmethod.com
Re: Start delegating stuff out of Component?
Posted by JP Saraceno <ju...@teracode.com>.
Sure, I'm glad to contribute.
I will start working on a code patch to implement this.
Any doc I should look for coding/testing standards within wicket
development?
igor.vaynberg wrote:
>
> like i said in the previous thread, your idea looks good on paper.
> lets suppose the interface i specified is real, could you show us an
> example implementation?
>
--
View this message in context: http://www.nabble.com/Start-delegating-stuff-out-of-Component--tp15884385p15902133.html
Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: Start delegating stuff out of Component?
Posted by Igor Vaynberg <ig...@gmail.com>.
like i said in the previous thread, your idea looks good on paper.
lets suppose the interface i specified is real, could you show us an
example implementation?
-igor
On Fri, Mar 7, 2008 at 3:26 AM, JP Saraceno
<ju...@teracode.com> wrote:
>
> What I was proposing was pretty much in the line of this interface you
> described. For a valid use case, this is triggered by the issue on the
> thread I referenced above.
>
> So I would be able to develop different implementations of
> IMarkupIdGenerator (for different kinds of Components) to do stuff that can
> be more meaningful to my application than just a generic counter all across
> the page. E.g.
> * For simple stuff than can't be repeated, maybe just copy over the
> wicket-id without any counter
> * For panels, add a counter on the number of instances of that specific
> panel on the page
> * For repeaters, use a the iteration index + the container Id.
> * etc, etc.
>
>
>
>
> igor.vaynberg wrote:
> >
> > 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); }
> >
>
> --
> View this message in context: http://www.nabble.com/Start-delegating-stuff-out-of-Component--tp15884385p15891161.html
>
>
> Sent from the Wicket - Dev mailing list archive at Nabble.com.
>
>
Re: Start delegating stuff out of Component?
Posted by JP Saraceno <ju...@teracode.com>.
What I was proposing was pretty much in the line of this interface you
described. For a valid use case, this is triggered by the issue on the
thread I referenced above.
So I would be able to develop different implementations of
IMarkupIdGenerator (for different kinds of Components) to do stuff that can
be more meaningful to my application than just a generic counter all across
the page. E.g.
* For simple stuff than can't be repeated, maybe just copy over the
wicket-id without any counter
* For panels, add a counter on the number of instances of that specific
panel on the page
* For repeaters, use a the iteration index + the container Id.
* etc, etc.
igor.vaynberg wrote:
>
> 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); }
>
--
View this message in context: http://www.nabble.com/Start-delegating-stuff-out-of-Component--tp15884385p15891161.html
Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: Start delegating stuff out of Component?
Posted by Igor Vaynberg <ig...@gmail.com>.
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
<ju...@teracode.com> 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.
>
>