You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wicket.apache.org by Jonathan Locke <jo...@gmail.com> on 2008/03/06 02:07:51 UTC
rewire MarkupContainer.getMarkupType() and deprecate
WebMarkupContainer
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.
Re: rewire MarkupContainer.getMarkupType() and deprecate
WebMarkupContainer
Posted by Jonathan Locke <jo...@gmail.com>.
(of the method)
Jonathan Locke wrote:
>
>
> again, no deprecation.
>
>
> Martijn Dashorst wrote:
>>
>> i don't want to deprecate WMC because it is featured in a lot of
>> documentation (books, articles, list examples).
>>
>> I'm not sure about the timing of the deprecation of getMarkupType(). I
>> think that should wait until WNG-M1 (Wicket Next Generation, Milestone
>> 1)
>>
>> Martijn
>>
>> On 3/6/08, Jonathan Locke <jo...@gmail.com> 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.
>>>
>>>
>>
>>
>> --
>> Buy Wicket in Action: http://manning.com/dashorst
>> Apache Wicket 1.3.1 is released
>> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.1
>>
>>
>
>
--
View this message in context: http://www.nabble.com/rewire-MarkupContainer.getMarkupType%28%29-and-deprecate-WebMarkupContainer-tp15864296p15874351.html
Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: rewire MarkupContainer.getMarkupType() and deprecate
WebMarkupContainer
Posted by Jonathan Locke <jo...@gmail.com>.
again, no deprecation.
Martijn Dashorst wrote:
>
> i don't want to deprecate WMC because it is featured in a lot of
> documentation (books, articles, list examples).
>
> I'm not sure about the timing of the deprecation of getMarkupType(). I
> think that should wait until WNG-M1 (Wicket Next Generation, Milestone
> 1)
>
> Martijn
>
> On 3/6/08, Jonathan Locke <jo...@gmail.com> 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.
>>
>>
>
>
> --
> Buy Wicket in Action: http://manning.com/dashorst
> Apache Wicket 1.3.1 is released
> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.1
>
>
--
View this message in context: http://www.nabble.com/rewire-MarkupContainer.getMarkupType%28%29-and-deprecate-WebMarkupContainer-tp15864296p15874155.html
Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: rewire MarkupContainer.getMarkupType() and deprecate WebMarkupContainer
Posted by Martijn Dashorst <ma...@gmail.com>.
i don't want to deprecate WMC because it is featured in a lot of
documentation (books, articles, list examples).
I'm not sure about the timing of the deprecation of getMarkupType(). I
think that should wait until WNG-M1 (Wicket Next Generation, Milestone
1)
Martijn
On 3/6/08, Jonathan Locke <jo...@gmail.com> 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.
>
>
--
Buy Wicket in Action: http://manning.com/dashorst
Apache Wicket 1.3.1 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.1
Re: rewire MarkupContainer.getMarkupType() and deprecate
WebMarkupContainer
Posted by Jonathan Locke <jo...@gmail.com>.
i don't think so. certainly none of our hundreds of tests fail.
the change is checked in.
Johan Compagner wrote:
>
> fine by me, i guess getMarkupType is never ask for before the rendering
> right?
> else this would now throw an exception
>
> On Thu, Mar 6, 2008 at 6:08 PM, Jonathan Locke <jo...@gmail.com>
> wrote:
>
>>
>>
>> the tests all pass with the changes below. is anyone against me checking
>> this into trunk?
>>
>> Index:
>> jdk-1.4
>> /wicket/src/main/java/org/apache/wicket/markup/html/WebMarkupContainer.java
>> ===================================================================
>> ---
>> jdk-1.4
>> /wicket/src/main/java/org/apache/wicket/markup/html/WebMarkupContainer.java
>> (revision 634343)
>> +++
>> jdk-1.4
>> /wicket/src/main/java/org/apache/wicket/markup/html/WebMarkupContainer.java
>> (working copy)
>> @@ -54,7 +54,7 @@
>> */
>> public String getMarkupType()
>> {
>> - return "html";
>> + return getPage().getMarkupType();
>> }
>>
>> /**
>> Index:
>> jdk-1.4/wicket/src/main/java/org/apache/wicket/MarkupContainer.java
>> ===================================================================
>> --- jdk-1.4/wicket/src/main/java/org/apache/wicket/MarkupContainer.java
>> (revision 634343)
>> +++ jdk-1.4/wicket/src/main/java/org/apache/wicket/MarkupContainer.java
>> (working copy)
>> @@ -383,8 +383,7 @@
>> */
>> 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"));
>> + return getPage().getMarkupType();
>> }
>>
>>
>> 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
>> <jonathan.locke@gmail.com
>> >
>> > 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-tp15864296p15878558.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-tp15864296p15882364.html
Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: rewire MarkupContainer.getMarkupType() and deprecate WebMarkupContainer
Posted by Johan Compagner <jc...@gmail.com>.
fine by me, i guess getMarkupType is never ask for before the rendering
right?
else this would now throw an exception
On Thu, Mar 6, 2008 at 6:08 PM, Jonathan Locke <jo...@gmail.com>
wrote:
>
>
> the tests all pass with the changes below. is anyone against me checking
> this into trunk?
>
> Index:
> jdk-1.4
> /wicket/src/main/java/org/apache/wicket/markup/html/WebMarkupContainer.java
> ===================================================================
> ---
> jdk-1.4
> /wicket/src/main/java/org/apache/wicket/markup/html/WebMarkupContainer.java
> (revision 634343)
> +++
> jdk-1.4
> /wicket/src/main/java/org/apache/wicket/markup/html/WebMarkupContainer.java
> (working copy)
> @@ -54,7 +54,7 @@
> */
> public String getMarkupType()
> {
> - return "html";
> + return getPage().getMarkupType();
> }
>
> /**
> Index: jdk-1.4/wicket/src/main/java/org/apache/wicket/MarkupContainer.java
> ===================================================================
> --- jdk-1.4/wicket/src/main/java/org/apache/wicket/MarkupContainer.java
> (revision 634343)
> +++ jdk-1.4/wicket/src/main/java/org/apache/wicket/MarkupContainer.java
> (working copy)
> @@ -383,8 +383,7 @@
> */
> 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"));
> + return getPage().getMarkupType();
> }
>
>
> 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 <jonathan.locke@gmail.com
> >
> > 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-tp15864296p15878558.html
> Sent from the Wicket - Dev mailing list archive at Nabble.com<http://nabble.com/>
> .
>
>
Re: rewire MarkupContainer.getMarkupType() and deprecate
WebMarkupContainer
Posted by Jonathan Locke <jo...@gmail.com>.
the tests all pass with the changes below. is anyone against me checking
this into trunk?
Index:
jdk-1.4/wicket/src/main/java/org/apache/wicket/markup/html/WebMarkupContainer.java
===================================================================
---
jdk-1.4/wicket/src/main/java/org/apache/wicket/markup/html/WebMarkupContainer.java
(revision 634343)
+++
jdk-1.4/wicket/src/main/java/org/apache/wicket/markup/html/WebMarkupContainer.java
(working copy)
@@ -54,7 +54,7 @@
*/
public String getMarkupType()
{
- return "html";
+ return getPage().getMarkupType();
}
/**
Index: jdk-1.4/wicket/src/main/java/org/apache/wicket/MarkupContainer.java
===================================================================
--- jdk-1.4/wicket/src/main/java/org/apache/wicket/MarkupContainer.java
(revision 634343)
+++ jdk-1.4/wicket/src/main/java/org/apache/wicket/MarkupContainer.java
(working copy)
@@ -383,8 +383,7 @@
*/
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"));
+ return getPage().getMarkupType();
}
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 <jo...@gmail.com>
> 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-tp15864296p15878558.html
Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: rewire MarkupContainer.getMarkupType() and deprecate
WebMarkupContainer
Posted by Jonathan Locke <jo...@gmail.com>.
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 <jo...@gmail.com>
> 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
>> <jonathan.locke@gmail.com
>> >
>> > 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.
Re: rewire MarkupContainer.getMarkupType() and deprecate WebMarkupContainer
Posted by Johan Compagner <jc...@gmail.com>.
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 <jo...@gmail.com>
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 <jonathan.locke@gmail.com
> >
> > 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/>
> .
>
>
Re: rewire MarkupContainer.getMarkupType() and deprecate
WebMarkupContainer
Posted by Jonathan Locke <jo...@gmail.com>.
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 <jo...@gmail.com>
> 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-tp15864296p15874057.html
Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: rewire MarkupContainer.getMarkupType() and deprecate
WebMarkupContainer
Posted by Jonathan Locke <jo...@gmail.com>.
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 <jo...@gmail.com>
>> 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.
Re: rewire MarkupContainer.getMarkupType() and deprecate
WebMarkupContainer
Posted by Jonathan Locke <jo...@gmail.com>.
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 <jo...@gmail.com>
> 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-tp15864296p15878018.html
Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: rewire MarkupContainer.getMarkupType() and deprecate WebMarkupContainer
Posted by Johan Compagner <jc...@gmail.com>.
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 <jo...@gmail.com>
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/>
> .
>
>
Wrapped Object Model documentation added to the wiki
Posted by Michael O'Cleirigh <mi...@rivulet.ca>.
Hello,
In a swing based application I worked on for a few years we used a lot
of tables and all the TableModels were implemented in a way very similar
to what I've just written up on the wiki here:
http://cwiki.apache.org/confluence/display/WICKET/Working+with+Wicket+models#WorkingwithWicketmodels-WrappedObjectModels
Basically it is an approach where by a model is created that wraps the
object and then each wicket accessible property is explicitly defined
along with the getter and setter.
I'm not sure about where I located the page, since it describes more of
a pattern to building models then a built in wicket model. If the
location is not suitable I'm more than willing to move it some where else.
Mike
.