so both WebMarkupContainer AND MarkupContainer would use page markup type.
we get binary compatibility and relax the constraint on MarkupContainer so
it can be used directly (without deprecating it, to make Martijn happy).
Jonathan Locke wrote:
>
>
> it seems like we could also change MarkupContainer.getMarkupType():
>
> public String getMarkupType()
> {
> throw new IllegalStateException(
> exceptionMessage("You cannot directly subclass Page or
> MarkupContainer.
> Instead, subclass a markup-specific class, such as WebPage or
> WebMarkupContainer"));
> }
>
> to
>
> public String getMarkupType()
> {
> return getPage().getMarkupType();
> }
>
> in 1.3.x. this would open the ability to subclass MarkupContainer and
> should not break anything.
>
>
> 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/>
>>> .
>>>
>>>
>>
>>
>
>
--
View this message in context:
http://www.nabble.com/rewire-MarkupContainer.getMarkupType%28%29-and-deprecate-WebMarkupContainer-tp15864296p15878019.html
Sent from the Wicket - Dev mailing list archive at Nabble.com.
