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
<juergen.donners...@gmail.com> wrote:
done: https://issues.apache.org/jira/browse/WICKET-3314
-Juergen
On Sun, Jan 9, 2011 at 1:03 AM, Igor Vaynberg<igor.vaynb...@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
<juergen.donners...@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
