On Thu, Dec 19, 2013 at 11:49 AM, Steve <[email protected]> wrote:
> > Why ModifiableMarkup has to be mutable ?
> > Do you expect that the markup will change at runtime in some conditions ?
> > I think what you need is a new impl of MarkupElement for the expressions.
> > So org.apache.wicket.markup.Markup#markupElements will have more
> elements.
> > Then when rendering starts each element will render itself as
> appropriate.
> > But the list itself won't change once created.
> >
> Yes markup will change at runtime. It is primarily because of
> RawMarkup. It is a final class and there are several examples of: if
> (element instanceof RawMarkup) do something; in wicket so when
> resolving the EL expressions in the markup the only 'safe' way to do it
> and stay completely transparent to wicket is to replace the original
> RawMarkup with a new one... e.g.
>
> in the EL component:
> public void onRender() {
> modifiableMarkup.resolve(some params);
> super.onRender();
> }
>
> What it looks like inside MarkupModifier.resolve() is something like this:
>
> original RawMarkup.toString: "<span>${myProperty}</span>"
> resolved = new RawMarkup("<span>my property value</span>");
> modifiableMarkup.replace(rawMarkupIndex, resolved);
>
My idea is to use something like ElMarkupElement instead of RawMarkup when
there are EL expressions inside.
Then each ElMarkupElement will resolve its value when requested
(org.apache.wicket.markup.MarkupElement#toCharSequence, I think).
You can put the params in the request cycle metadata, or custom thread
local, ...
This way the Markup instance is always the same, its markup elements are
always the same, but the output they produce is different depending on the
context information.
To accomplish this you will need to tweak the MarkupParser though.
The good thing is that Wicket parses the markup just once and then puts it
in the cache.
>
> (actually it's not really relevant to this discussion but the original
> RawMarkup contains a marker token instead of the original expression to
> ensure it's XML legal before it's passed to the markup parser... in this
> case it would be '${#[expressionIndex]}' )
>
> here's a link to ModifiableMarkup
>
> https://bitbucket.org/shadders/wicket-el/src/917bb51f19ddd6e631d8ce537c90915eb21fb01f/src/main/java/org/apache/wicket/markup/ModifiableMarkup.java?at=default
>
> So I can't call makeImmutable() on ModifiableMarkup or it will throw an
> exception whenever replace(index, markupElement) is called. However the
> length of the element list will never change and each element in the
> list will always be the same type.
>
> >If the developer changes the markup then the whole Markup instance is
> >replaced with a new one. As now.
>
> That's the entire purpose of this approach... To avoid that. The
> overhead from continually recreating Markups was enormous.
>
> >So far no one needed to add custom MarkupElements and that's why it is not
> >very easy.
> >You can fork Wicket and create a branch where you can make modifications
> to
> >make it easier and
> >later we can review the needed changes and probably apply them back in
> >Wicket.
>
> I may give that a go. This has been an interesting exercise that's
> forced to spend a lot of time under the hood in wicket getting to know
> the markup sourcing and rendering aspects of it. I must confess I was a
>
I am not the best person to guide you in this part of Wicket.
Because markup handling was relatively bug-free in the last years I haven't
spent much time in this area.
Also there were no many brave souls to do something like you :)
> little concerned the wicket team might not like this project much given
> that it's fairly hefty divergence from the wicket way of doing
> things... Wonderful to hear you are open to considering some minor
> changes to accomodate it.
>
I personally do not like EL per se.
But I see no problem to make it easier for external projects to hook in
every part of Wicket to accomplish whatever is needed, as far as the core
functionality of Wicket is not harmed by this.
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>
