almost all of the root form classes and validation are also not specific to html. while it would be possible to cut and paste this, i wonder if we shouldn't extract an abstraction here too.
Jonathan Locke wrote: > > i'm currently tasked in my job with supporting WML and another internal > markup language in wicket. i think we would like to open source the WML > effort and i'd like to do this in trunk for the next version of wicket if > everyone is okay with that. this work is pretty cool because it will be > an opportunity to iron out any wrinkles we've got that would stand in the > way of adding full support for a markup language other than HTML. > > in looking at the inheritance hierarchy, it strikes me that there are a > number of subclasses of WebMarkupContainer which are pretty (or entirely) > markup-language neutral. this makes me wonder if they shouldn't subclass > MarkupContainer and have MarkupContainer.getMarkupType() return > getPage().getMarkupType() (or something along those lines). in > particular, it seems like these classes are not markup-language dependent: > > Panel, Border, Fragment, AbstractRepeater (and ListView, Loop and > RepeatingView), BorderBodyContainer, Enclosure, HeaderPartContainer, > ListItem, LoopItem > > also, Label is a subclass of WebComponent and doesn't seem to be > markup-language specific either, so it could subclass Component and > Component.getMarkupType() would return getPage().getMarkupType() as well. > > it would seem that this is not a huge breaking change, but i'm not > precisely sure what all would be affected. > > thoughts? > > > -- View this message in context: http://www.nabble.com/wicket-1.4-and-other-markup-languages-tp15833298p15839484.html Sent from the Wicket - Dev mailing list archive at Nabble.com.
