Re: Attempted summary of multiple wicket:child / thread
I hope people don't start thinking that this damn newbie comes and wants to change a proven framework without knowing it really. But as owner of the patch I am very interested in this discussion and probably even responsible for it - or maybe eelco was, when he said And hey, maybe some working code convinces us :-) (probably) without being prepared to see working code ;) Nah, that's never a problem. I don't think any of the team cares about who starts discussions, as long as you stick to technical arguments. Threads like these are quite time consuming though, and time is something we all are short on. :-) As long as there is a good JIRA issue for it, it'll stay in our TODO list to look at. Or... you create that wicket-stuff project I talked about and you have it whenever you're ready. Makes it easier for us/ team to look at it later. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Attempted summary of multiple wicket:child / thread
hi bruno,
so we do start to convince you ;)
I hope people don't start thinking that this damn newbie comes and wants
to change a proven framework without knowing it really. But as owner of the
patch I am very interested in this discussion and probably even responsible
for it - or maybe eelco was, when he said And hey, maybe some working code
convinces us :-) (probably) without being prepared to see working code ;)
I don't think that whatever kind of declaration on the java side would help
to make things clearer. merging markup based on child/extend currently is
really trivial. therefore, the outcome is easy to predict for
developers/designers. this could also be beneficial for IDE support:
previewing the outcome would be an easy-to-implement feature for Wicket
Bench (including warnings for duplicate ids in the resulting markup).
-- stefan
Bruno Borges wrote:
I give up. Looks like this enhancement is really receiving positive votes.
:)
So, let me just clarify my opinion, before giving a suggestion (yes, a
suggestion!):
I was (and I still am a little) against this improvement because of some
reasons:
1) new tag: but if we are going to see a deprecation of old ones, fine by
me
2) no declaration in the Java side: I don't like the idea of having markup
containers like wicket:abstract id=foo / not being declared in the
WebPage.
3) existence of other ways to do this: using panels, fragments, whatever.
Now, to change my position from no way dude, this is no good! to
well...
if you can't beat them, join them I'd like to suggest this:
In my second reason, I point to something that is... the _core_ of wicket:
binding Java objects (Components) to HTML tags. So, not having this
binding,
we could lose great features. Seeing from this point of view, my
suggestion
is to allow these new
call-whatever-you-want-here-from-abstract-to-implement-to-default-to-etc
tags only when they have been declared in Java:
BasePage extends WebPage {
BasePage() {
/*
* Abstract markups could only be set with div element
* and their feature is that it can be overridden by specializations,
like sub classes.
*/
addAbstractMarkup(foo); // internally sets setRenderBodyOnly(true)
ALWAYS!! this won't let enclosing div being printed
// this addAbstractMakup method would be a facilitator to
// some AbstractWebMarkupContainer class, controlled by Wicket and
maybe, not even public
}
}
BasePage.html
htmlbody
div wicket:id=fooSome default value here maybe?/div
/body/html
SubPage extends BasePage {}
SubPage.html
htmlbody
div wicket:id=fooOverrides BasePage's foo/div !-- this enclosing
div should also not be printed by Wicket --
/body/html
m2c
regards,
On Nov 9, 2007 10:11 PM, Chris Colman [EMAIL PROTECTED]
wrote:
Hi,
Actually, Wicket already works like this. It does *NOT* require the
wicket:extend, and if it's not present it just renders the contents
of
the wicket:child. (Just tested this with beta4).
Awesome!
[This behaviour must have changed since 1.2.6 because I tried removing
the extend tag in a derived page using this version and the whole of
the derived page got rendered - ie., it did not merge in any markup from
the base page. If later versions have fixed this already then that's
massively awesome indeed]
Furthermore, your patch works exactly the same as far for multilple
child sections (as far as I can tell, or otherwise it should for
backwards compatibility), and does precisely what both you and Chris
want.
Awesome!
So it all sounds like a very low risk improvement of the existing
functionality - cool!
Sorry to all of those who've put up with such a long, sometimes noisy
thread but I think that's just part of the enthusiastic, collaborative
process that popular open source projects such as Wicket have become and
it's what continues to make them great and evolve to become even
greater.
I present to you just one final tweak at the edges for your comment:
The OO puritan in me would love to see wicket:child aliased to
wicket:default so that developers could use either child (deprecated
but still available for backwards compatibility) or default - it won't
break existing pages and lets new people use a more naturally fitting
and more accurate tag:
Which would flow more naturally and be more easily understood by new
users reading the documentation?
A) If you don't 'extend' a 'child' section in a derived page wicket uses
the child section provided in the base page.
(Comment: Extend a child? We're not extending the child section - we're
replacing it!)
B) If you don't 'extend' a 'default' section in a derived page wicket
uses the default section provided in the base page.
(Comment: Extend? It is the page you are extended by overriding one or
more of its default sections. Again you aren't extending a default
section you are replacing it!)
Or even - now I'm really
RE: Attempted summary of multiple wicket:child / thread
I give up. Looks like this enhancement is really receiving positive votes. :) :) :) :) :) :) :) :) :) Just some of the many happy faces! In my second reason, I point to something that is... the _core_ of wicket: binding Java objects (Components) to HTML tags. So, not having this binding, we could lose great features. Seeing from this point of view, my suggestion is to allow these new call-whatever-you-want-here-from-abstract-to-implement-to-default-to-etc tags only when they have been declared in Java: It's great that you're now at the level of suggesting improvements! And I'm already hating myself for my following comments but in the interest of keeping this enhancement simple: My first thoughts about your suggestion are: I wonder if components associated with default/overridden markup should be treated any differently. I have always found Wicket's error detection on missing tags or unbound components to be excellent. It would still continue to work in the exact same way without needing to define, as you suggest, at the Java level, special components that will bind to abstract (default/override) markup sections. I think the elegance of the new feature is that is purely an enablement (I think I just invented a new word!) of multiplicity on an existing feature and some new tags to more accurately define the feature (previous tags are aliased to the new ones for backwards compatibility). If we start having to define overridden or abstract components at the Java level then it turns into a whole 'nuther beast and I worry that we lose some of the genericity of component definition that we have now in wicket. On first glance I believe that your suggestion may create problems for backwards compatibility with existing pages using the current childextend feature. It would mean people would have to add addAbstractMarkup to their existing pages to allow them to work in the new system which would be a bad thing I think. Ok, I can stop hating myself now ;) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Attempted summary of multiple wicket:child / thread
I think it would be a nice feature to define defaults and overrides this way. However, this wouldn't be backwards compatible anymore as the contents are currently ignored. (Ok, you are currently forced to extend them, so you probably wouldn't see the markup from such sections in *old* applications.) My vote on this: - I would love to have multiple sections. - I would appreciate default markup for extendible sections. Kind regards, -- stefan PS: I'm keeping my fingers crossed for RC1! Go, Wicket, go! :) Chris Colman wrote: That is what I'd suggest as well, since it involves the least amount of change. As an added bonus, if no id's are added and 2 wicket:child sections are used, it could throw an exception (which it currently does not do, it just silently ignores the second wicket:child). That would be magic! While we're at this epic moment after spending days thrashing this out could we spend just 3 extra minutes to investigate implementing standard Java method like behavior for this feature? Ie., In the case that no override extend is provided in a derived page, simply use the markup in the child tag in the base page. Then it would work like methods work in Java - and it's probably how most Java developers would naturally expect an OO framework like wicket to work anyway. Intuitively it seems like an easy to implement option in the framework: the child/extend feature is already merging code from the base page anyway - if there is no override extend tag in a derived page then it simply pulls the markup from the base page's child tag. Regards, Sebastiaan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - --- Stefan Fußenegger http://talk-on-tech.blogspot.com // looking for a nicer domain ;) -- View this message in context: http://www.nabble.com/Attempted-summary-of-multiple-%3Cwicket%3Achild--%3E-thread-tf4767718.html#a13662915 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Attempted summary of multiple wicket:child / thread
Hi, Actually, Wicket already works like this. It does *NOT* require the wicket:extend, and if it's not present it just renders the contents of the wicket:child. (Just tested this with beta4). Furthermore, your patch works exactly the same as far for multilple child sections (as far as I can tell, or otherwise it should for backwards compatibility), and does precisely what both you and Chris want. Regards, Sebastiaan Stefan Fußenegger wrote: I think it would be a nice feature to define defaults and overrides this way. However, this wouldn't be backwards compatible anymore as the contents are currently ignored. (Ok, you are currently forced to extend them, so you probably wouldn't see the markup from such sections in *old* applications.) My vote on this: - I would love to have multiple sections. - I would appreciate default markup for extendible sections. Kind regards, -- stefan PS: I'm keeping my fingers crossed for RC1! Go, Wicket, go! :) Chris Colman wrote: That is what I'd suggest as well, since it involves the least amount of change. As an added bonus, if no id's are added and 2 wicket:child sections are used, it could throw an exception (which it currently does not do, it just silently ignores the second wicket:child). That would be magic! While we're at this epic moment after spending days thrashing this out could we spend just 3 extra minutes to investigate implementing standard Java method like behavior for this feature? Ie., In the case that no override extend is provided in a derived page, simply use the markup in the child tag in the base page. Then it would work like methods work in Java - and it's probably how most Java developers would naturally expect an OO framework like wicket to work anyway. Intuitively it seems like an easy to implement option in the framework: the child/extend feature is already merging code from the base page anyway - if there is no override extend tag in a derived page then it simply pulls the markup from the base page's child tag. Regards, Sebastiaan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - --- Stefan Fußenegger http://talk-on-tech.blogspot.com // looking for a nicer domain ;) smime.p7s Description: S/MIME Cryptographic Signature
Re: Attempted summary of multiple wicket:child / thread
Of course, it really is optional. Wicket only checks whether a page has a wicket:extend tag or not to decide if markup merging is needed. (Therefore, my patch does not have any impact on that, as there is no markup merging triggered) Thanks for pointing this out! -- stefan Sebastiaan van Erk wrote: Hi, Actually, Wicket already works like this. It does *NOT* require the wicket:extend, and if it's not present it just renders the contents of the wicket:child. (Just tested this with beta4). Furthermore, your patch works exactly the same as far for multilple child sections (as far as I can tell, or otherwise it should for backwards compatibility), and does precisely what both you and Chris want. Regards, Sebastiaan Stefan Fußenegger wrote: I think it would be a nice feature to define defaults and overrides this way. However, this wouldn't be backwards compatible anymore as the contents are currently ignored. (Ok, you are currently forced to extend them, so you probably wouldn't see the markup from such sections in *old* applications.) My vote on this: - I would love to have multiple sections. - I would appreciate default markup for extendible sections. Kind regards, -- stefan PS: I'm keeping my fingers crossed for RC1! Go, Wicket, go! :) Chris Colman wrote: That is what I'd suggest as well, since it involves the least amount of change. As an added bonus, if no id's are added and 2 wicket:child sections are used, it could throw an exception (which it currently does not do, it just silently ignores the second wicket:child). That would be magic! While we're at this epic moment after spending days thrashing this out could we spend just 3 extra minutes to investigate implementing standard Java method like behavior for this feature? Ie., In the case that no override extend is provided in a derived page, simply use the markup in the child tag in the base page. Then it would work like methods work in Java - and it's probably how most Java developers would naturally expect an OO framework like wicket to work anyway. Intuitively it seems like an easy to implement option in the framework: the child/extend feature is already merging code from the base page anyway - if there is no override extend tag in a derived page then it simply pulls the markup from the base page's child tag. Regards, Sebastiaan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - --- Stefan Fußenegger http://talk-on-tech.blogspot.com // looking for a nicer domain ;) - --- Stefan Fußenegger http://talk-on-tech.blogspot.com // looking for a nicer domain ;) -- View this message in context: http://www.nabble.com/Attempted-summary-of-multiple-%3Cwicket%3Achild--%3E-thread-tf4767718.html#a13666078 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Attempted summary of multiple wicket:child / thread
Hi, Actually, Wicket already works like this. It does *NOT* require the wicket:extend, and if it's not present it just renders the contents of the wicket:child. (Just tested this with beta4). Awesome! [This behaviour must have changed since 1.2.6 because I tried removing the extend tag in a derived page using this version and the whole of the derived page got rendered - ie., it did not merge in any markup from the base page. If later versions have fixed this already then that's massively awesome indeed] Furthermore, your patch works exactly the same as far for multilple child sections (as far as I can tell, or otherwise it should for backwards compatibility), and does precisely what both you and Chris want. Awesome! So it all sounds like a very low risk improvement of the existing functionality - cool! Sorry to all of those who've put up with such a long, sometimes noisy thread but I think that's just part of the enthusiastic, collaborative process that popular open source projects such as Wicket have become and it's what continues to make them great and evolve to become even greater. I present to you just one final tweak at the edges for your comment: The OO puritan in me would love to see wicket:child aliased to wicket:default so that developers could use either child (deprecated but still available for backwards compatibility) or default - it won't break existing pages and lets new people use a more naturally fitting and more accurate tag: Which would flow more naturally and be more easily understood by new users reading the documentation? A) If you don't 'extend' a 'child' section in a derived page wicket uses the child section provided in the base page. (Comment: Extend a child? We're not extending the child section - we're replacing it!) B) If you don't 'extend' a 'default' section in a derived page wicket uses the default section provided in the base page. (Comment: Extend? It is the page you are extended by overriding one or more of its default sections. Again you aren't extending a default section you are replacing it!) Or even - now I'm really pushing my luck asking to provide two aliases ;) C) If you don't 'override' a 'default' section in a derived page wicket uses the 'default' section provided in the base page. (Comment - arrhh beautiful - 100% accurate and natural) At university I remember a lecturer telling a story of an interview with one of the creators of Unix. He was asked if he had any regrets over his illustrious career and he said Yes I do, I regret naming the 'create' function 'creat' instead of 'create' just to save one byte!. How much frustration does a bad name cause? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Attempted summary of multiple wicket:child / thread
Yes that is the solution that also gets my vote for 1.4 if we can implement it nicely and if it is backwards compartible and straightforward to use. johan On Nov 8, 2007 10:37 AM, Jan Kriesten [EMAIL PROTECTED] wrote: hi everyone, actually, i wonder what is wrong with al's suggestion to add id's to wicket:child and wicket:extend? regards, --- jan. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Attempted summary of multiple wicket:child / thread
The advantage of having this separate project is that such inheritance would be available for people who like it, and hey, maybe in the longer term you have something that works so good that you can convince people based on something that works. Executable code works much better than simply words when it comes to that ;-) Having it as a separate project is better than no project at all. I'd be glad to use that if a separate project is the only option on offer. As it's a separate project we'll need different tag names. I'm not sure if you caught my 11th hour submission on your final summary post: Suggested minor modification to the design: Call tags default and override instead of abstract and implements - it's less *techie* plus it allows us to define a default markup section in a base page that can be optionally overridden in any derived pages. That's even more OO and allows even greater simplicity through reusability. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Attempted summary of multiple wicket:child / thread
Eelco wrote: The thing is though, even though it is 100% backwards compatible, it is something we'll have to support. It adds complexity to the implementation, and we'll have to answer questions about it on the list. That would be fine if everyone would have been wildly enthusiastic about it, but that is not the case - whether you think that is justified or not. So, like I propose in the main thread, the best way to go is to implement this as a separate project, using separate tags. We'll be happy to support any internal API changes if that is needed to make the implementation work. The advantage of having this separate project is that such inheritance would be available for people who like it, and hey, maybe in the longer term you have something that works so good that you can convince people based on something that works. Executable code works much better than simply words when it comes to that ;-) Some small questions on doing this as a separate project: 1) If API changes are necessary, is it not adding more complexity that needs to be supported than the change itself? The change is relatively minor change (heck, even mark it experimental/use at own risk/may be removed in a future release). Can the same be said for other API changes yet to be thought of... 2) If other tags are going to have to be used, are tags in the wicket namespace allowed? Would that not be a potential source of future naming conflicts? What is the policy here? Regards, Sebastiaan smime.p7s Description: S/MIME Cryptographic Signature
Re: Attempted summary of multiple wicket:child / thread
In conclusion, the proposed change: - is useful - does not have to be used if you don't like it - is 100% backwards compatible - it introduces no new tags (if using child/extends) The thing is though, even though it is 100% backwards compatible, it is something we'll have to support. It adds complexity to the implementation, and we'll have to answer questions about it on the list. That would be fine if everyone would have been wildly enthusiastic about it, but that is not the case - whether you think that is justified or not. So, like I propose in the main thread, the best way to go is to implement this as a separate project, using separate tags. We'll be happy to support any internal API changes if that is needed to make the implementation work. The advantage of having this separate project is that such inheritance would be available for people who like it, and hey, maybe in the longer term you have something that works so good that you can convince people based on something that works. Executable code works much better than simply words when it comes to that ;-) Do people want to work on this? Regards, Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Attempted summary of multiple wicket:child / thread
Hi eelco. Did you see what I changed in order to make this working? There is nearly no extra complexity. So I think complexity isn't an argument here. best regards -- stefan Eelco Hillenius wrote: In conclusion, the proposed change: - is useful - does not have to be used if you don't like it - is 100% backwards compatible - it introduces no new tags (if using child/extends) The thing is though, even though it is 100% backwards compatible, it is something we'll have to support. It adds complexity to the implementation, and we'll have to answer questions about it on the list. That would be fine if everyone would have been wildly enthusiastic about it, but that is not the case - whether you think that is justified or not. So, like I propose in the main thread, the best way to go is to implement this as a separate project, using separate tags. We'll be happy to support any internal API changes if that is needed to make the implementation work. The advantage of having this separate project is that such inheritance would be available for people who like it, and hey, maybe in the longer term you have something that works so good that you can convince people based on something that works. Executable code works much better than simply words when it comes to that ;-) Do people want to work on this? Regards, Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - --- Stefan Fußenegger http://talk-on-tech.blogspot.com // looking for a nicer domain ;) -- View this message in context: http://www.nabble.com/Attempted-summary-of-multiple-%3Cwicket%3Achild--%3E-thread-tf4767718.html#a13643264 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Attempted summary of multiple wicket:child / thread
Hi, Eelco Hillenius wrote: In conclusion, the proposed change: - is useful - does not have to be used if you don't like it - is 100% backwards compatible - it introduces no new tags (if using child/extends) The thing is though, even though it is 100% backwards compatible, it is something we'll have to support. It adds complexity to the implementation, and we'll have to answer questions about it on the list. That would be fine if everyone would have been wildly enthusiastic about it, but that is not the case - whether you think that is justified or not. The fact that you guys would have to support it and answer questions is fair enough. So, like I propose in the main thread, the best way to go is to implement this as a separate project, using separate tags. We'll be happy to support any internal API changes if that is needed to make the implementation work. The advantage of having this separate project is that such inheritance would be available for people who like it, and hey, maybe in the longer term you have something that works so good that you can convince people based on something that works. Executable code works much better than simply words when it comes to that ;-) Do people want to work on this? Sure, I would like to work on this. It would eliminate my need for wicket:fragment and would allow me to do everything I need consistently with 1 tag pair, as well as eliminate some java code. Regards, Sebastiaan Regards, Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] smime.p7s Description: S/MIME Cryptographic Signature
Re: Attempted summary of multiple wicket:child / thread
hi everyone, actually, i wonder what is wrong with al's suggestion to add id's to wicket:child and wicket:extend? regards, --- jan. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Attempted summary of multiple wicket:child / thread
Jan Kriesten wrote: hi everyone, actually, i wonder what is wrong with al's suggestion to add id's to wicket:child and wicket:extend? regards, --- jan. That is what I'd suggest as well, since it involves the least amount of change. As an added bonus, if no id's are added and 2 wicket:child sections are used, it could throw an exception (which it currently does not do, it just silently ignores the second wicket:child). Regards, Sebastiaan smime.p7s Description: S/MIME Cryptographic Signature
RE: Attempted summary of multiple wicket:child / thread
That is what I'd suggest as well, since it involves the least amount of change. As an added bonus, if no id's are added and 2 wicket:child sections are used, it could throw an exception (which it currently does not do, it just silently ignores the second wicket:child). That would be magic! While we're at this epic moment after spending days thrashing this out could we spend just 3 extra minutes to investigate implementing standard Java method like behavior for this feature? Ie., In the case that no override extend is provided in a derived page, simply use the markup in the child tag in the base page. Then it would work like methods work in Java - and it's probably how most Java developers would naturally expect an OO framework like wicket to work anyway. Intuitively it seems like an easy to implement option in the framework: the child/extend feature is already merging code from the base page anyway - if there is no override extend tag in a derived page then it simply pulls the markup from the base page's child tag. Regards, Sebastiaan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Attempted summary of multiple wicket:child / thread
... 5) Conclusion In conclusion, the proposed change: - is useful - does not have to be used if you don't like it - is 100% backwards compatible - it introduces no new tags (if using child/extends) I also do not see any real issues. This is purely about merging markup when rendering, I think the analogies between this and OO concepts in Java are clouding the issue! Regards, Sebastiaan Great summary Sebastiaan! I just thought of a possible, even more powerful, improvement (whoops!) What if the base page sections (child or abstract tag) were optionally overridden in a derived page. Ie., the section in the derived page markup is used if supplied otherwise Wicket defaults to using that provided in the base page. That's immensely powerful because you could provide some default markup in the base page and that will be used if the derived page does not provide an implementation of that section. A derived page now only needs to provide override sections for sections that it actually needs to override. It makes 'abstract' not a good choice for a tag name because abstract implies there is no implementation in the base page. In this case we could drop the OO language terms and use easy to understand terms for the tags like wicket default id=header / in a base page section and wicket override id=header / in a derived page section. Even my graphic designers could understand a tag pair called default/override! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
