Ah! Eureka! I just realized something that simplifies the entire
situation...
It never makes sense to have a different doctype for the parent and
child page. Why? Previewability!
If I previewed the parent page in one doctype and suddenly the product
page users another who knows what it'll look like? The same applies to a
child page.
Hence we can simplify this entire discussion and do this:
- <wicket:extend> does may not include the doctype
- Wicket enforces the fact that all pages in the inheritance hierarchy
must have the same doctype. If the parent has no doctype, the child may
not have a doctype either (because the lack of a doctype translates into
an implicit doctype chosen by the browser).
I don't think there is a good counter-example which breaks this
design. What do you think?
Gili
Gili wrote:
with the approach I mentioned, you wouldn't be forced as
<wicket:extend> is removed by default. I think that answer all your
remaining point as well, correct?
I didn't mean that it was a chore to strip away <wicket:extend>
tags. I meant that we don't *want* to do it.
In my view, the entire point of debug mode is that you should be
able to see *all* the tags. Now you're telling me that if I choose to
enable this behavior (don't strip away wicket:extend) then suddenly my
page will render different from production mode. That is the fundamental
problem here... stripping the tags by default is pretending the problem
does not exist instead of actually.
Instead of taking this approach maybe we can do the opposite: add a
setOverrideDoctype() method. Thinking out loud, here is what I had in mind:
- To my knowledge, doctype is the only tag we can't wrap with <wicket>
tags. All other tags may be wrapped and the browser will ignore them
with no loss of previewability.
- We can define <wicket:extend> like <wicket:border> -- that is, it
wraps the *body* of the page we want to inject, not the entire page.
This means that doctype does not belong inside <wicket:extend>.
- When the user sets setOverrideDoctype() the doctype from the extending
document clobbers the one in the parent document.
I think more-often-than-not you do not want to override the parent
doctype and furthermore when one extends a page, you mean to extend its
body not its metadata information.
Here is an example from an online shop I am building...
I might have a parent page CustomizeProduct.html that is viewed when
the user chooses a product to order and wishes to specify its size,
color, etc...
I then extend this page with say CustomizeMug.html,
CustomizeShirt.html, etc... which injects HTML into the body of the
parent HTML specific to the product being sold. Regardless of the
product being sold, I expect the same page header, colors, and maybe
even meta-keywords. The only thing being modified is the image used and
the kind of options you might have. For example, if you order a Mug
you'd have "small, large" as an option. If you order a poster, you will
have many possible dimensions to order from. If you order a cup, you
might have the ability to choose it's color, etc...
What do you think?
Gili
--
http://www.desktopbeautifier.com/
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
