oh. i thought it would bind to the superclass method.
anyway, let's do what you suggested. it's completely safe that way.
Johan Compagner wrote:
>
> it is compartible but not binary
> if somebody would drop in the jar that called getMarkupType() on
> WebMarkupContainer
> you will get an method not found exception.
>
> johan
>
>
>
> On Thu, Mar 6, 2008 at 4:23 PM, Jonathan Locke <[EMAIL PROTECTED]>
> wrote:
>
>>
>>
>> i'm not proposing a deprecation in 1.3. the change is compatible
>> as WMC would inherit the method from its superclass. i'm happy
>> enough to do what you suggest though.
>>
>>
>> Johan Compagner wrote:
>> >
>> > i dont know about the changes in 1.3.x those are binary changes
>> > If you want to change something in 1.3. Then i propose something else
>> like
>> > not depricating anything in 1.3.2
>> > and let the WebMarkupContainer be what it is except getMarkupType does
>> > return it from the page instead of directly itself.
>> >
>> > in 1.4 we can remove WebMarkupContainer or make it depricate and remove
>> it
>> > in the next
>> >
>> > johan
>> >
>> >
>> >
>> > On Thu, Mar 6, 2008 at 2:07 AM, Jonathan Locke
>> <[EMAIL PROTECTED]
>> >
>> > wrote:
>> >
>> >>
>> >> wml (and other markup languages) could use many of the xhtml
>> components
>> >> we
>> >> already have out of the box, with one major problem: all these
>> reusable
>> >> xhtml components currently extend WebMarkupContainer which is
>> hard-wired
>> >> to
>> >> return "html" for the markup type. this means, for example, there's
>> no
>> >> way
>> >> to provide an html panel and a wml panel (for example). i think the
>> >> markup
>> >> type for any markup container should be the same as the page it's
>> >> contained
>> >> on, so i'd like to propose we do this:
>> >>
>> >> 1. In Wicket 1.3.2: MarkupContainer.getMarkupType() { return
>> >> getPage().getMarkupType() }
>> >>
>> >> 2. In Wicket 1.3.2: Remove WebMarkupContainer.getMarkupType() method
>> and
>> >> let
>> >> it inherit from MarkupContainer, making WebMarkupContainer pretty much
>> a
>> >> NO-OP.
>> >>
>> >> 3. In Wicket 1.4: Deprecate WebMarkupContainer and
>> >> WebMarkupContainerWithAssociatedMarkup, create a neutral
>> >> MarkupContainerWithAssociatedMarkup and rewire all components to
>> extend
>> >> MarkupContainer instead of WebMarkupContainer
>> >>
>> >> 4. In Wicket 1.4: we could reorganize our components in terms of
>> >> packaging
>> >> so that markup-neutral components are in some new package and things
>> that
>> >> are truly XHTML specific are in the html package. organization might
>> >> look
>> >> more like:
>> >>
>> >> org.apache.wicket.markup
>> >> org.apache.wicket.markup.neutral (or push the markup caching and
>> parsing
>> >> stuff into a subpackage and use the markup package itself for neutral
>> >> things
>> >> like Component, Page, MarkupContainer, etc)
>> >> org.apache.wicket.markup.html
>> >> org.apache.wicket.markup.wml
>> >>
>> >> i'd at least like to see 1 and 2 as this seems a lot more elegant to
>> me
>> >> and
>> >> solves a lot of my problems in wml-land without a silly need to mirror
>> >> xhtml
>> >> components that are almost 100% shareable.
>> >>
>> >> thoughts? votes (per issue)?
>> >>
>> >> jon
>> >>
>> >>
>> >> --
>> >> View this message in context:
>> >>
>> http://www.nabble.com/rewire-MarkupContainer.getMarkupType%28%29-and-deprecate-WebMarkupContainer-tp15864296p15864296.html
>> >> Sent from the Wicket - Dev mailing list archive at
>> >> Nabble.com <http://nabble.com/><http://nabble.com/>
>> >> .
>> >>
>> >>
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/rewire-MarkupContainer.getMarkupType%28%29-and-deprecate-WebMarkupContainer-tp15864296p15874057.html
>> Sent from the Wicket - Dev mailing list archive at
>> Nabble.com<http://nabble.com/>
>> .
>>
>>
>
>
--
View this message in context:
http://www.nabble.com/rewire-MarkupContainer.getMarkupType%28%29-and-deprecate-WebMarkupContainer-tp15864296p15877821.html
Sent from the Wicket - Dev mailing list archive at Nabble.com.
