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 <[email protected]> wrote: > done: https://issues.apache.org/jira/browse/WICKET-3314 > > -Juergen > > On Sun, Jan 9, 2011 at 1:03 AM, Igor Vaynberg <[email protected]> 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 >> <[email protected]> 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 >>> >> >
