MarkupFragments and the vision to create a components in the constructor

[Juergen Donnerstag <ju...@gmail.com>]

In the recent past I've changed markup loading to use MarkupFragment
instead of MarkupStream and I think it is more or less ok. The change
as such don't provide any benefits right now (except Markup Attributes
in the constructor), but is a pre-requisite for the change to the
modified render process to come (probably V3). All changes so far are
more or less invisible for most users.
One vision associated with MarkupFragments is that within a components
constructor the hierarchie of component can be build and that it
remains stable during the render phase (component hierarchy
unmodifiable during the render phase). This requires to replace all
resolvers with I call for now loaders. Loaders are invoked when a
component loads a new markup (via the cache). The various loaders may
scan/analyze the markup and if necessary create and add components.
Headers (<wicket:head>) was what I picked first. I changed the code,
all junit tests are successful and than I started playing with the
form example. Two issues: a) when you change the language the markup
must be reloaded and b) when you click the save button the same page
gets displayed with additional infos at the bottom. What is common to
both use cases is that the component hierarchy remains the same, but
the markup changes. Re-loading the markup from disk is not the
problem, but when does it happen? It happens during the render
process. And because the reloaded markup might have different
wicket:head tags (or any other auto-component), they are removed at
the end of the render process which means they _must_ be rebuild when
the markup gets loaded. Two possible solutions: a) stay with adding
auto components at render time b) make the *Targets responsible to
re-create the autocomponents and only than render the page.
Solution (a) questions a little bit our vision and (b) will end up
with where does the render process start and where does it end.
Solution (a) has another drawback: if we really want to achieve a 1:1
relationship between markup and component hierarchy than there will be
scenarios where components are inside <wicket:head> and when we remove
the wicketHead container at the end of the render cycle, that it
removes the inner component(s) as well.
Any thoughts?

Juergen

Re: MarkupFragments and the vision to create a components in the constructor

[Igor Vaynberg <ig...@gmail.com>]

a couple of notes come to mind,

wicket:message can probably be handled just by writing out the message, but
other tags might require more advanced functionality that is better
encapsulated in components.

for wicket:message we decided to work using existing tools. we had a
component that displays a message, we had a model that looks up i18n keys,
so it was a trivial implementation.

also it is important to note that wicket:message doesnt have a body, but it
is possible to write tags that do - there injecting a webmarkupcontainer
into the hierarchy opens a lot of doors. you can woogle "wicket:enclosure"
or just "enclosure" to see a nontrivial tag which is implemented in 2.0


-igor


On 11/4/06, Petr Sakar <sa...@chare.eu> wrote:
>
> Igor,
> thanx for very nice explanation. Still one more question for part I do not
> understand :
> if I'm in the rendering phase, I would suppose hierarchy is alredy known
> and I'm just creating the response, right? So why i'm adding for the tag
> wicket:message this auto component instead of just rendering the message
> to the response ?
>
> saki
>
> > On 11/4/06, Petr Sakar <sa...@chare.eu> wrote:
> >>
> >> > wicket:message tag attributes are replaced at markup load time, but
> >> > <wicket:message> tags can not be replaced at load time.
> >>
> >> So you are replacing them with actual value at render time ? Than it
> has
> >> no influence with respect to original question:
> >>
> >>   If I undestand it correctly, currently component hierarchy is build
> >>   based on markup. How about to do it other way round ? For component
> >>   hierarchy created in your java code lookup the markup ?
> >
> >
> > no, this is not how it works. the hierarchy is built in both places. the
> > hierarchy you build in your javacode has to match exactly to the
> hierarchy
> > you build in markup.
> >
> > the problem with components like wicket:message is that they have no
> java
> > counterpart, only markup.
> >
> > the render process is driven by scanning markup - because that is the
> only
> > place where the rendering order of components is defined.
> >
> > when we hit a markup component tag ( tag with wicket:id, or wicket
> > namespace
> > ) we try to resolve it to its java counterpart before it is rendered.
> this
> > is done by resolvers. since the default resolver fails to find the java
> > counterpart it delegates to other resolves in the chain. the
> wicketmessage
> > resolver kicks in. what it does is at render time add what we call an
> > "auto"
> > component - these are the only components allowed to be added/modify
> > hierarchy during the render phase. so wicketmessage resolver adds a
> label
> > component to represent the wicket:message tag. then the rendering
> > continues
> > and when wicket tries to resolve wicket:message it now finds the auto
> > component added by the resolver and everything continues as it normally
> > would.
> >
> > -igor
> >
>
>

Re: MarkupFragments and the vision to create a components in the constructor

[Petr Sakar <sa...@chare.eu>]

Igor,
thanx for very nice explanation. Still one more question for part I do not
understand :
if I'm in the rendering phase, I would suppose hierarchy is alredy known
and I'm just creating the response, right? So why i'm adding for the tag
wicket:message this auto component instead of just rendering the message
to the response ?

saki

> On 11/4/06, Petr Sakar <sa...@chare.eu> wrote:
>>
>> > wicket:message tag attributes are replaced at markup load time, but
>> > <wicket:message> tags can not be replaced at load time.
>>
>> So you are replacing them with actual value at render time ? Than it has
>> no influence with respect to original question:
>>
>>   If I undestand it correctly, currently component hierarchy is build
>>   based on markup. How about to do it other way round ? For component
>>   hierarchy created in your java code lookup the markup ?
>
>
> no, this is not how it works. the hierarchy is built in both places. the
> hierarchy you build in your javacode has to match exactly to the hierarchy
> you build in markup.
>
> the problem with components like wicket:message is that they have no java
> counterpart, only markup.
>
> the render process is driven by scanning markup - because that is the only
> place where the rendering order of components is defined.
>
> when we hit a markup component tag ( tag with wicket:id, or wicket
> namespace
> ) we try to resolve it to its java counterpart before it is rendered. this
> is done by resolvers. since the default resolver fails to find the java
> counterpart it delegates to other resolves in the chain. the wicketmessage
> resolver kicks in. what it does is at render time add what we call an
> "auto"
> component - these are the only components allowed to be added/modify
> hierarchy during the render phase. so wicketmessage resolver adds a label
> component to represent the wicket:message tag. then the rendering
> continues
> and when wicket tries to resolve wicket:message it now finds the auto
> component added by the resolver and everything continues as it normally
> would.
>
> -igor
>

Re: MarkupFragments and the vision to create a components in the constructor

[Igor Vaynberg <ig...@gmail.com>]

On 11/4/06, Petr Sakar <sa...@chare.eu> wrote:
>
> > wicket:message tag attributes are replaced at markup load time, but
> > <wicket:message> tags can not be replaced at load time.
>
> So you are replacing them with actual value at render time ? Than it has
> no influence with respect to original question:
>
>   If I undestand it correctly, currently component hierarchy is build
>   based on markup. How about to do it other way round ? For component
>   hierarchy created in your java code lookup the markup ?


no, this is not how it works. the hierarchy is built in both places. the
hierarchy you build in your javacode has to match exactly to the hierarchy
you build in markup.

the problem with components like wicket:message is that they have no java
counterpart, only markup.

the render process is driven by scanning markup - because that is the only
place where the rendering order of components is defined.

when we hit a markup component tag ( tag with wicket:id, or wicket namespace
) we try to resolve it to its java counterpart before it is rendered. this
is done by resolvers. since the default resolver fails to find the java
counterpart it delegates to other resolves in the chain. the wicketmessage
resolver kicks in. what it does is at render time add what we call an "auto"
component - these are the only components allowed to be added/modify
hierarchy during the render phase. so wicketmessage resolver adds a label
component to represent the wicket:message tag. then the rendering continues
and when wicket tries to resolve wicket:message it now finds the auto
component added by the resolver and everything continues as it normally
would.

-igor

Re: MarkupFragments and the vision to create a components in the constructor

[Petr Sakar <sa...@chare.eu>]

> wicket:message tag attributes are replaced at markup load time, but
> <wicket:message> tags can not be replaced at load time.

So you are replacing them with actual value at render time ? Than it has
no influence with respect to original question:

  If I undestand it correctly, currently component hierarchy is build
  based on markup. How about to do it other way round ? For component
  hierarchy created in your java code lookup the markup ?


> AttributeModifier must be attached to a Component, but the markup can
> be associated with multiple component instances. Hence it must be
> resolved at render time.
> Just look at all the *Resolver to find out which components are
> automatically added at render time

> Magic is something we try to avoid. Magic is difficult to understand
> by users and make the code more difficult to maintain. Simple and
> straight forward is what we should aim for.
>
> Juergen

Sorry for using word 'magic'. I'm trying to find out if such straight
forward approach is possible - to create pages by specifying component
hierarchy only in java code, and have markup only for components where it
is needed.

saki










>
> On 11/4/06, Petr Sakar <sa...@chare.eu> wrote:
>> > that wont work, some components such as <wicket:link> and
>> <wicket:message>
>> > only exist in markup
>>
>> Igor,
>> thank you for your answer.
>>
>> From api doc:
>> wicket:message="value=key" would replace or add the attribute "value"
>> with
>> the message associated with "key".
>>
>> I would expect it is implemented using AttributeModifier, not component.
>>
>> With wicket:link example you are right, but can be solved (you would
>> have
>> to add the component in code (or do some magic).
>>
>> Can you please give me other examples as well - I'm a bit curious and
>> would like to find out if it is really impossible.
>>
>> Thanks
>> saki
>>
>> >
>> > -igor
>> >
>> >
>> > On 11/3/06, Petr Sakar <sa...@chare.eu> wrote:
>> >>
>> >> Question / Idea:
>> >> If I undestand it correctly, currently component hierarchy is build
>> >> based
>> >> on markup. How about to do it other way round ? For component
>> hierarchy
>> >> created in your java code lookup the markup ?
>> >>
>> >> saki
>> >>
>> >>
>> >
>>
>>
>

Re: MarkupFragments and the vision to create a components in the constructor

[Igor Vaynberg <ig...@gmail.com>]

i think you have the most experience in this area, so i would be inclined to
go with whatever your gut feeling is on this.

-igor


On 11/4/06, Juergen Donnerstag <ju...@gmail.com> wrote:
>
> wicket:message tag attributes are replaced at markup load time, but
> <wicket:message> tags can not be replaced at load time.
> AttributeModifier must be attached to a Component, but the markup can
> be associated with multiple component instances. Hence it must be
> resolved at render time.
> Just look at all the *Resolver to find out which components are
> automatically added at render time
> Magic is something we try to avoid. Magic is difficult to understand
> by users and make the code more difficult to maintain. Simple and
> straight forward is what we should aim for.
>
> Juergen
>
> On 11/4/06, Petr Sakar <sa...@chare.eu> wrote:
> > > that wont work, some components such as <wicket:link> and
> <wicket:message>
> > > only exist in markup
> >
> > Igor,
> > thank you for your answer.
> >
> > From api doc:
> > wicket:message="value=key" would replace or add the attribute "value"
> with
> > the message associated with "key".
> >
> > I would expect it is implemented using AttributeModifier, not component.
> >
> > With wicket:link example you are right, but can be solved (you would
> have
> > to add the component in code (or do some magic).
> >
> > Can you please give me other examples as well - I'm a bit curious and
> > would like to find out if it is really impossible.
> >
> > Thanks
> > saki
> >
> > >
> > > -igor
> > >
> > >
> > > On 11/3/06, Petr Sakar <sa...@chare.eu> wrote:
> > >>
> > >> Question / Idea:
> > >> If I undestand it correctly, currently component hierarchy is build
> > >> based
> > >> on markup. How about to do it other way round ? For component
> hierarchy
> > >> created in your java code lookup the markup ?
> > >>
> > >> saki
> > >>
> > >>
> > >
> >
> >
>

Re: MarkupFragments and the vision to create a components in the constructor

[Juergen Donnerstag <ju...@gmail.com>]

wicket:message tag attributes are replaced at markup load time, but
<wicket:message> tags can not be replaced at load time.
AttributeModifier must be attached to a Component, but the markup can
be associated with multiple component instances. Hence it must be
resolved at render time.
Just look at all the *Resolver to find out which components are
automatically added at render time
Magic is something we try to avoid. Magic is difficult to understand
by users and make the code more difficult to maintain. Simple and
straight forward is what we should aim for.

Juergen

On 11/4/06, Petr Sakar <sa...@chare.eu> wrote:
> > that wont work, some components such as <wicket:link> and <wicket:message>
> > only exist in markup
>
> Igor,
> thank you for your answer.
>
> From api doc:
> wicket:message="value=key" would replace or add the attribute "value" with
> the message associated with "key".
>
> I would expect it is implemented using AttributeModifier, not component.
>
> With wicket:link example you are right, but can be solved (you would have
> to add the component in code (or do some magic).
>
> Can you please give me other examples as well - I'm a bit curious and
> would like to find out if it is really impossible.
>
> Thanks
> saki
>
> >
> > -igor
> >
> >
> > On 11/3/06, Petr Sakar <sa...@chare.eu> wrote:
> >>
> >> Question / Idea:
> >> If I undestand it correctly, currently component hierarchy is build
> >> based
> >> on markup. How about to do it other way round ? For component hierarchy
> >> created in your java code lookup the markup ?
> >>
> >> saki
> >>
> >>
> >
>
>

Re: MarkupFragments and the vision to create a components in the constructor

[Petr Sakar <sa...@chare.eu>]

> that wont work, some components such as <wicket:link> and <wicket:message>
> only exist in markup

Igor,
thank you for your answer.

>From api doc:
wicket:message="value=key" would replace or add the attribute "value" with
the message associated with "key".

I would expect it is implemented using AttributeModifier, not component.

With wicket:link example you are right, but can be solved (you would have
to add the component in code (or do some magic).

Can you please give me other examples as well - I'm a bit curious and
would like to find out if it is really impossible.

Thanks
saki

>
> -igor
>
>
> On 11/3/06, Petr Sakar <sa...@chare.eu> wrote:
>>
>> Question / Idea:
>> If I undestand it correctly, currently component hierarchy is build
>> based
>> on markup. How about to do it other way round ? For component hierarchy
>> created in your java code lookup the markup ?
>>
>> saki
>>
>>
>

Re: MarkupFragments and the vision to create a components in the constructor

[Igor Vaynberg <ig...@gmail.com>]

that wont work, some components such as <wicket:link> and <wicket:message>
only exist in markup

-igor


On 11/3/06, Petr Sakar <sa...@chare.eu> wrote:
>
> Question / Idea:
> If I undestand it correctly, currently component hierarchy is build based
> on markup. How about to do it other way round ? For component hierarchy
> created in your java code lookup the markup ?
>
> saki
>
>

Re: MarkupFragments and the vision to create a components in the constructor

[Petr Sakar <sa...@chare.eu>]

Question / Idea:
If I undestand it correctly, currently component hierarchy is build based
on markup. How about to do it other way round ? For component hierarchy
created in your java code lookup the markup ?

saki

Re: MarkupFragments and the vision to create a components in the constructor

[Juergen Donnerstag <ju...@gmail.com>]

You need to re-create them based on the new markup loaded. In case of
the form example e.g. when you hit the save button (same page), or
when you change the locale (again same page). And for the 2nd render
there is no component constructur called any more. Which means markup
gets loaded during the render phase.

Juergen

On 11/3/06, Igor Vaynberg <ig...@gmail.com> wrote:
> but they are auto components, so they get disregarded after the render has
> finished anyways so what is the problem?
>
> -igor
>
>
> On 11/3/06, Juergen Donnerstag <ju...@gmail.com> wrote:
> >
> > It is not only the header component, it is any auto component such as
> > wicket:link, wicket:message etc. If anything is different in the other
> > markup file ...
> >
> > Juergen
> >
> > On 11/3/06, Igor Vaynberg <ig...@gmail.com> wrote:
> > > > the markup gets loaded. Two possible solutions: a) stay with adding
> > > > auto components at render time
> > >
> > >
> > > b) make the *Targets responsible to
> > > > re-create the autocomponents and only than render the page.
> > >
> > >
> > > i dont like this at all. it adds a requirement for targets that cannot
> > be
> > > clearly expressed through the interface.
> > >
> > > Solution (a) questions a little bit our vision
> > >
> > >
> > > thats ok, maybe we can fix it all the way in v3
> > >
> > > and (b) will end up
> > > > with where does the render process start and where does it end.
> > >
> > >
> > > yes, this is bad
> > >
> > > Solution (a) has another drawback: if we really want to achieve a 1:1
> > > > relationship between markup and component hierarchy than there will be
> > > > scenarios where components are inside <wicket:head> and when we remove
> > > > the wicketHead container at the end of the render cycle, that it
> > > > removes the inner component(s) as well.
> > >
> > >
> > > can we somehow get around removing the entire head component?
> > >
> > > -igor
> > >
> > >
> > > > Juergen
> > > >
> > >
> > >
> >
>
>

Re: MarkupFragments and the vision to create a components in the constructor

[Igor Vaynberg <ig...@gmail.com>]

but they are auto components, so they get disregarded after the render has
finished anyways so what is the problem?

-igor


On 11/3/06, Juergen Donnerstag <ju...@gmail.com> wrote:
>
> It is not only the header component, it is any auto component such as
> wicket:link, wicket:message etc. If anything is different in the other
> markup file ...
>
> Juergen
>
> On 11/3/06, Igor Vaynberg <ig...@gmail.com> wrote:
> > > the markup gets loaded. Two possible solutions: a) stay with adding
> > > auto components at render time
> >
> >
> > b) make the *Targets responsible to
> > > re-create the autocomponents and only than render the page.
> >
> >
> > i dont like this at all. it adds a requirement for targets that cannot
> be
> > clearly expressed through the interface.
> >
> > Solution (a) questions a little bit our vision
> >
> >
> > thats ok, maybe we can fix it all the way in v3
> >
> > and (b) will end up
> > > with where does the render process start and where does it end.
> >
> >
> > yes, this is bad
> >
> > Solution (a) has another drawback: if we really want to achieve a 1:1
> > > relationship between markup and component hierarchy than there will be
> > > scenarios where components are inside <wicket:head> and when we remove
> > > the wicketHead container at the end of the render cycle, that it
> > > removes the inner component(s) as well.
> >
> >
> > can we somehow get around removing the entire head component?
> >
> > -igor
> >
> >
> > > Juergen
> > >
> >
> >
>

Re: MarkupFragments and the vision to create a components in the constructor

[Juergen Donnerstag <ju...@gmail.com>]

It is not only the header component, it is any auto component such as
wicket:link, wicket:message etc. If anything is different in the other
markup file ...

Juergen

On 11/3/06, Igor Vaynberg <ig...@gmail.com> wrote:
> > the markup gets loaded. Two possible solutions: a) stay with adding
> > auto components at render time
>
>
> b) make the *Targets responsible to
> > re-create the autocomponents and only than render the page.
>
>
> i dont like this at all. it adds a requirement for targets that cannot be
> clearly expressed through the interface.
>
> Solution (a) questions a little bit our vision
>
>
> thats ok, maybe we can fix it all the way in v3
>
> and (b) will end up
> > with where does the render process start and where does it end.
>
>
> yes, this is bad
>
> Solution (a) has another drawback: if we really want to achieve a 1:1
> > relationship between markup and component hierarchy than there will be
> > scenarios where components are inside <wicket:head> and when we remove
> > the wicketHead container at the end of the render cycle, that it
> > removes the inner component(s) as well.
>
>
> can we somehow get around removing the entire head component?
>
> -igor
>
>
> > Juergen
> >
>
>

Re: Re: MarkupFragments and the vision to create a components in the constructor

[Juergen Donnerstag <ju...@gmail.com>]

Not sure I understand it. Can a bit more specific. How markups (input
and expected output) look like?

Juergen

On 11/3/06, Martijn Dashorst <ma...@gmail.com> wrote:
> Sorry to hijack the thread, but I think this might be related:
>
> I have an idea for a component that is added to an event handler in
> the markup, without having a 'markup' position in the page.
>
> For instance:
>
> <a href="#" wicket:id="foo" oncontextmenu="">bla</a>
>
> new Link("foo") {}.add(new ContextMenu());
>
> the context menu component would be a mixin between a behavior (it
> attaches itself to the "oncontextmenu" javascript attribute), and
> would include the panel markup.
>
> This is the same as for the modal window. We now have to add some
> markup to the page where the popup div will render itself, and we also
> have to add the popup to the page, and add an event handler to trigger
> the modal window.
>
> Martijn
>
> On 11/3/06, Igor Vaynberg <ig...@gmail.com> wrote:
> > > the markup gets loaded. Two possible solutions: a) stay with adding
> > > auto components at render time
> >
> >
> > b) make the *Targets responsible to
> > > re-create the autocomponents and only than render the page.
> >
> >
> > i dont like this at all. it adds a requirement for targets that cannot be
> > clearly expressed through the interface.
> >
> > Solution (a) questions a little bit our vision
> >
> >
> > thats ok, maybe we can fix it all the way in v3
> >
> > and (b) will end up
> > > with where does the render process start and where does it end.
> >
> >
> > yes, this is bad
> >
> > Solution (a) has another drawback: if we really want to achieve a 1:1
> > > relationship between markup and component hierarchy than there will be
> > > scenarios where components are inside <wicket:head> and when we remove
> > > the wicketHead container at the end of the render cycle, that it
> > > removes the inner component(s) as well.
> >
> >
> > can we somehow get around removing the entire head component?
> >
> > -igor
> >
> >
> > > Juergen
> > >
> >
> >
>
>
> --
> <a href="http://www.thebeststuffintheworld.com/vote_for/wicket">Vote</a>
> for <a href="http://www.thebeststuffintheworld.com/stuff/wicket">Wicket</a>
> at the <a href="http://www.thebeststuffintheworld.com/">Best Stuff in
> the World!</a>
>

Re: Re: MarkupFragments and the vision to create a components in the constructor

[Martijn Dashorst <ma...@gmail.com>]

Sorry to hijack the thread, but I think this might be related:

I have an idea for a component that is added to an event handler in
the markup, without having a 'markup' position in the page.

For instance:

<a href="#" wicket:id="foo" oncontextmenu="">bla</a>

new Link("foo") {}.add(new ContextMenu());

the context menu component would be a mixin between a behavior (it
attaches itself to the "oncontextmenu" javascript attribute), and
would include the panel markup.

This is the same as for the modal window. We now have to add some
markup to the page where the popup div will render itself, and we also
have to add the popup to the page, and add an event handler to trigger
the modal window.

Martijn

On 11/3/06, Igor Vaynberg <ig...@gmail.com> wrote:
> > the markup gets loaded. Two possible solutions: a) stay with adding
> > auto components at render time
>
>
> b) make the *Targets responsible to
> > re-create the autocomponents and only than render the page.
>
>
> i dont like this at all. it adds a requirement for targets that cannot be
> clearly expressed through the interface.
>
> Solution (a) questions a little bit our vision
>
>
> thats ok, maybe we can fix it all the way in v3
>
> and (b) will end up
> > with where does the render process start and where does it end.
>
>
> yes, this is bad
>
> Solution (a) has another drawback: if we really want to achieve a 1:1
> > relationship between markup and component hierarchy than there will be
> > scenarios where components are inside <wicket:head> and when we remove
> > the wicketHead container at the end of the render cycle, that it
> > removes the inner component(s) as well.
>
>
> can we somehow get around removing the entire head component?
>
> -igor
>
>
> > Juergen
> >
>
>


-- 
<a href="http://www.thebeststuffintheworld.com/vote_for/wicket">Vote</a>
for <a href="http://www.thebeststuffintheworld.com/stuff/wicket">Wicket</a>
at the <a href="http://www.thebeststuffintheworld.com/">Best Stuff in
the World!</a>

Re: MarkupFragments and the vision to create a components in the constructor

[Igor Vaynberg <ig...@gmail.com>]

> the markup gets loaded. Two possible solutions: a) stay with adding
> auto components at render time


b) make the *Targets responsible to
> re-create the autocomponents and only than render the page.


i dont like this at all. it adds a requirement for targets that cannot be
clearly expressed through the interface.

Solution (a) questions a little bit our vision


thats ok, maybe we can fix it all the way in v3

and (b) will end up
> with where does the render process start and where does it end.


yes, this is bad

Solution (a) has another drawback: if we really want to achieve a 1:1
> relationship between markup and component hierarchy than there will be
> scenarios where components are inside <wicket:head> and when we remove
> the wicketHead container at the end of the render cycle, that it
> removes the inner component(s) as well.


can we somehow get around removing the entire head component?

-igor


> Juergen
>