You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wicket.apache.org by Juergen Donnerstag <ju...@gmail.com> on 2011/01/08 23:54:46 UTC
More flexible Panel, Fragment, etc.
Hi,
currently every component that requires the markup to be in an
associated file must be derived from Panel. Every component that want
it's markup "inline" must be derived from Fragment. I've changed that
and moved the respective source code into something I called markup
sourcing strategy. I'm not sure it's the best name, so feel free to
suggest other names. Such a strategy can be provided to any component
via
public IMarkupSourcingStrategy getMarkupSourcingStrategy();
Obviously it makes sense that only one strategy can be associated with
any component. Each strategy has its own implementations to provide
the correct markup, handle the header contribution, necessary changes
to the open tag and it renders the component body appropriately.
Changing a FormComponent to a FormComponentPanel is now as simple as
subclassing getMarkupSourcingStrategy(). And it easily be changed to
become a "FormComponentFragment"
I've attached a patch (draft) against 1.5 trunk which successfully
passes all tests in core. I wonder what you think about the idea.
-Juergen
Re: More flexible Panel, Fragment, etc.
Posted by Daniel Soneira <da...@joyn-it.at>.
I'm pleased to see this feature included. 1.5 will rock!
Cheers, Daniel
On 13.01.2011 19:13, Juergen Donnerstag wrote:
> An initial version went into rc1 though we are still discussing minor
> changes. The API might change slighty.
>
> -Juergen
>
> On Thu, Jan 13, 2011 at 11:49 AM, Martijn Dashorst
> <ma...@gmail.com> wrote:
>> On Thu, Jan 13, 2011 at 11:42 AM, Daniel Soneira
>> <da...@joyn-it.at> wrote:
>>> Since the release vote for 1.5 RC1 has started I guess that means this
>>> feature will unfortunately not make it into 1.5?
>> According to https://issues.apache.org/jira/browse/WICKET-3314?page=com.atlassian.jira.plugin.ext.subversion%3Asubversion-commits-tabpanel
>> it is in the release.
>>
>> Martijn
>>
Re: More flexible Panel, Fragment, etc.
Posted by Juergen Donnerstag <ju...@gmail.com>.
An initial version went into rc1 though we are still discussing minor
changes. The API might change slighty.
-Juergen
On Thu, Jan 13, 2011 at 11:49 AM, Martijn Dashorst
<ma...@gmail.com> wrote:
> On Thu, Jan 13, 2011 at 11:42 AM, Daniel Soneira
> <da...@joyn-it.at> wrote:
>> Since the release vote for 1.5 RC1 has started I guess that means this
>> feature will unfortunately not make it into 1.5?
>
> According to https://issues.apache.org/jira/browse/WICKET-3314?page=com.atlassian.jira.plugin.ext.subversion%3Asubversion-commits-tabpanel
> it is in the release.
>
> Martijn
>
Re: More flexible Panel, Fragment, etc.
Posted by Martijn Dashorst <ma...@gmail.com>.
On Thu, Jan 13, 2011 at 11:42 AM, Daniel Soneira
<da...@joyn-it.at> wrote:
> Since the release vote for 1.5 RC1 has started I guess that means this
> feature will unfortunately not make it into 1.5?
According to https://issues.apache.org/jira/browse/WICKET-3314?page=com.atlassian.jira.plugin.ext.subversion%3Asubversion-commits-tabpanel
it is in the release.
Martijn
Re: More flexible Panel, Fragment, etc.
Posted by Daniel Soneira <da...@joyn-it.at>.
Since the release vote for 1.5 RC1 has started I guess that means this
feature will unfortunately not make it into 1.5?
Regards,
Daniel Soneira
On 10.01.2011 02:09, Igor Vaynberg wrote:
> i really like this. lets commit it. a couple of notes below:
>
>
> assocatedmarkupsourcingstrategy.oncomponenttag() may have a problem.
> looks like its assuming external markup files begin with wicket:xxx
> tag, but they may begin with
> <html xmlns:wicket>
> <wicket:panel>
> is the html tag stripped before this code executes and the assumption
> is safe to make?
>
>
>
> WebMarkupContainerWithAssociatedMarkup is still there, do we need it?
>
>
>
> it might make sense to merge IMarkupResourceStreamProvider and
> IMarkupCacheKeyProvider into the sourcing interface so we have one
> interface that deals with component-markup relationship rather then
> three. not sure if it makes sense though. if we do this, however, we
> should probably replace getMarkupSourceStrategy() with a
> hasMarkupSourceStategy() and newMarkupSourceStrategy() result of which
> is cached in the metadata - otherwise users have to add another slot
> to do the caching, know to cache it, know to cache it in a transient
> field.
>
>
> cheers,
> -igor
>
>
>
>
> On Sun, Jan 9, 2011 at 12:12 AM, Juergen Donnerstag
> <ju...@gmail.com> wrote:
>> done: https://issues.apache.org/jira/browse/WICKET-3314
>>
>> -Juergen
>>
>> On Sun, Jan 9, 2011 at 1:03 AM, Igor Vaynberg<ig...@gmail.com> wrote:
>>> sounds interesting, but your patch didnt make it. attach to a jira issue?
>>>
>>> -igor
>>>
>>> On Sat, Jan 8, 2011 at 2:54 PM, Juergen Donnerstag
>>> <ju...@gmail.com> wrote:
>>>> Hi,
>>>>
>>>> currently every component that requires the markup to be in an
>>>> associated file must be derived from Panel. Every component that want
>>>> it's markup "inline" must be derived from Fragment. I've changed that
>>>> and moved the respective source code into something I called markup
>>>> sourcing strategy. I'm not sure it's the best name, so feel free to
>>>> suggest other names. Such a strategy can be provided to any component
>>>> via
>>>>
>>>> public IMarkupSourcingStrategy getMarkupSourcingStrategy();
>>>>
>>>> Obviously it makes sense that only one strategy can be associated with
>>>> any component. Each strategy has its own implementations to provide
>>>> the correct markup, handle the header contribution, necessary changes
>>>> to the open tag and it renders the component body appropriately.
>>>>
>>>> Changing a FormComponent to a FormComponentPanel is now as simple as
>>>> subclassing getMarkupSourcingStrategy(). And it easily be changed to
>>>> become a "FormComponentFragment"
>>>>
>>>> I've attached a patch (draft) against 1.5 trunk which successfully
>>>> passes all tests in core. I wonder what you think about the idea.
>>>>
>>>> -Juergen
>>>>
Re: More flexible Panel, Fragment, etc.
Posted by Igor Vaynberg <ig...@gmail.com>.
i really like this. lets commit it. a couple of notes below:
assocatedmarkupsourcingstrategy.oncomponenttag() may have a problem.
looks like its assuming external markup files begin with wicket:xxx
tag, but they may begin with
<html xmlns:wicket>
<wicket:panel>
is the html tag stripped before this code executes and the assumption
is safe to make?
WebMarkupContainerWithAssociatedMarkup is still there, do we need it?
it might make sense to merge IMarkupResourceStreamProvider and
IMarkupCacheKeyProvider into the sourcing interface so we have one
interface that deals with component-markup relationship rather then
three. not sure if it makes sense though. if we do this, however, we
should probably replace getMarkupSourceStrategy() with a
hasMarkupSourceStategy() and newMarkupSourceStrategy() result of which
is cached in the metadata - otherwise users have to add another slot
to do the caching, know to cache it, know to cache it in a transient
field.
cheers,
-igor
On Sun, Jan 9, 2011 at 12:12 AM, Juergen Donnerstag
<ju...@gmail.com> wrote:
> done: https://issues.apache.org/jira/browse/WICKET-3314
>
> -Juergen
>
> On Sun, Jan 9, 2011 at 1:03 AM, Igor Vaynberg <ig...@gmail.com> wrote:
>> sounds interesting, but your patch didnt make it. attach to a jira issue?
>>
>> -igor
>>
>> On Sat, Jan 8, 2011 at 2:54 PM, Juergen Donnerstag
>> <ju...@gmail.com> wrote:
>>> Hi,
>>>
>>> currently every component that requires the markup to be in an
>>> associated file must be derived from Panel. Every component that want
>>> it's markup "inline" must be derived from Fragment. I've changed that
>>> and moved the respective source code into something I called markup
>>> sourcing strategy. I'm not sure it's the best name, so feel free to
>>> suggest other names. Such a strategy can be provided to any component
>>> via
>>>
>>> public IMarkupSourcingStrategy getMarkupSourcingStrategy();
>>>
>>> Obviously it makes sense that only one strategy can be associated with
>>> any component. Each strategy has its own implementations to provide
>>> the correct markup, handle the header contribution, necessary changes
>>> to the open tag and it renders the component body appropriately.
>>>
>>> Changing a FormComponent to a FormComponentPanel is now as simple as
>>> subclassing getMarkupSourcingStrategy(). And it easily be changed to
>>> become a "FormComponentFragment"
>>>
>>> I've attached a patch (draft) against 1.5 trunk which successfully
>>> passes all tests in core. I wonder what you think about the idea.
>>>
>>> -Juergen
>>>
>>
>
Re: More flexible Panel, Fragment, etc.
Posted by Juergen Donnerstag <ju...@gmail.com>.
done: https://issues.apache.org/jira/browse/WICKET-3314
-Juergen
On Sun, Jan 9, 2011 at 1:03 AM, Igor Vaynberg <ig...@gmail.com> wrote:
> sounds interesting, but your patch didnt make it. attach to a jira issue?
>
> -igor
>
> On Sat, Jan 8, 2011 at 2:54 PM, Juergen Donnerstag
> <ju...@gmail.com> wrote:
>> Hi,
>>
>> currently every component that requires the markup to be in an
>> associated file must be derived from Panel. Every component that want
>> it's markup "inline" must be derived from Fragment. I've changed that
>> and moved the respective source code into something I called markup
>> sourcing strategy. I'm not sure it's the best name, so feel free to
>> suggest other names. Such a strategy can be provided to any component
>> via
>>
>> public IMarkupSourcingStrategy getMarkupSourcingStrategy();
>>
>> Obviously it makes sense that only one strategy can be associated with
>> any component. Each strategy has its own implementations to provide
>> the correct markup, handle the header contribution, necessary changes
>> to the open tag and it renders the component body appropriately.
>>
>> Changing a FormComponent to a FormComponentPanel is now as simple as
>> subclassing getMarkupSourcingStrategy(). And it easily be changed to
>> become a "FormComponentFragment"
>>
>> I've attached a patch (draft) against 1.5 trunk which successfully
>> passes all tests in core. I wonder what you think about the idea.
>>
>> -Juergen
>>
>
Re: More flexible Panel, Fragment, etc.
Posted by Igor Vaynberg <ig...@gmail.com>.
sounds interesting, but your patch didnt make it. attach to a jira issue?
-igor
On Sat, Jan 8, 2011 at 2:54 PM, Juergen Donnerstag
<ju...@gmail.com> wrote:
> Hi,
>
> currently every component that requires the markup to be in an
> associated file must be derived from Panel. Every component that want
> it's markup "inline" must be derived from Fragment. I've changed that
> and moved the respective source code into something I called markup
> sourcing strategy. I'm not sure it's the best name, so feel free to
> suggest other names. Such a strategy can be provided to any component
> via
>
> public IMarkupSourcingStrategy getMarkupSourcingStrategy();
>
> Obviously it makes sense that only one strategy can be associated with
> any component. Each strategy has its own implementations to provide
> the correct markup, handle the header contribution, necessary changes
> to the open tag and it renders the component body appropriately.
>
> Changing a FormComponent to a FormComponentPanel is now as simple as
> subclassing getMarkupSourcingStrategy(). And it easily be changed to
> become a "FormComponentFragment"
>
> I've attached a patch (draft) against 1.5 trunk which successfully
> passes all tests in core. I wonder what you think about the idea.
>
> -Juergen
>