hi eelco,
Assume the tag wouldn't be renamed. Then it would only be a new and optional
(!) attribute for the child/extend tags. So isn't it unnecessary to
explicitly turn on/off a feature that you could implicitly turn on as soon
as this attribute is used?
The naming - is abstract/implement
On Nov 7, 2007 5:53 PM, Chris Colman [EMAIL PROTECTED] wrote:
heh, wellyou can be against this, but i think if we take a vote
right now most core-devs with binding votes will vote this down
I still can't see the reason for the negativity of some of the
core-devs: this is an existing
Eelco Hillenius wrote:
On Nov 7, 2007 5:53 PM, Chris Colman [EMAIL PROTECTED] wrote:
heh, wellyou can be against this, but i think if we take a vote
right now most core-devs with binding votes will vote this down
I still can't see the reason for the negativity of some of the
core-devs:
Well, the tags are not new, as they do the perfectly same as extend and
child. Basically, the patch only introduces an id attribute to those tags in
order to make linking of markup more flexible. The new names were only
introduced to keep functionality of the patch separated from the existing
Hey Chris, I would need some lobbying here! ;)
-- stefan
Chris Colman wrote:
Wouldn't this essentially be the same as using wicket:panel
id=header/ and using WebMarkupContainers on the java side?
I.e.:
Base
Structural markup goes here (see below for explanation of this)
ok tell me with 2 examples what is soo different about having 2 panels (or
fragments)
in a page and implement that in a sub page or having 2 wicket childs in a
page
and implement those in a sub page.
A basepage can also have ofcourse an extend area and 2 panels..
johan
On 11/7/07, Chris
Wouldn't this essentially be the same as using wicket:panel
id=header/ and using WebMarkupContainers on the java side?
yes it would be exactly the same thing.
If you think that these are the same then you've missed some vital plot
points of the movie that it child/extend.
On Nov 7, 2007 11:31 AM, Mats Norén [EMAIL PROTECTED] wrote:
Hmm...I'm interested in seeing the difference as well. I would love to
get it but right now I don't.
Chris Colman wrote:
This new feature, or extension of the exiting feature, allows more than
one section of markup to be
Hmmm... more tags? I thought you guys liked Wicket because it's plain
html
support. Now looks like there's a big interest in having more tags. If
this is true, why don't we go back a few years, or move to JSF? Let's
give
Wicket support to Tag Libraries too :)
These aren't just like other
Hey Chris, I would need some lobbying here! ;)
-- stefan
You're doing a great job Stefan - especially now I see that you've implemented
it - excellent job!
Are we both seeing something here that other people can't see? It wouldn't be
the first time in my life I was in that position - only
Hi Mats, let me try to explain what Chris and I see here that others don't -
may it be there or not ;)
You can of course do everything with panels that could be done with multiple
abstract sections (may they be named wicket:child or wicket:abstract).
However, if this is the only argument, you
You are wrong. I have a component (Panel) that has a method to return a
Fragment. This component returns a default implementation of that Fragment,
but pages can override that Fragment.
CRUDFormPanel extends Panel {
protected Fragment newFormFields(String id, Form form) {
if (property
Given these subtle problems with this approach, I admit I'm warming
to
the multiple extend/child idea.
im oposite - if i have X extends in a page, whose extend should be
preferred (e.g: manipulating the head or a part outside of itself) ?
I'm not sure I understand the issue you raise
And if somebody really needs 5 child areas, something else might be
even
messier than the page's constructor. I rather think that 2, 3 or in
rare
cases even 4 ids could make sense.
i must disagree - i have a basepage which defines the default layout
on a
project, i.e. header,
Given these subtle problems with this approach, I admit I'm warming to
the multiple extend/child idea.
im oposite - if i have X extends in a page, whose extend should be
preferred (e.g: manipulating the head or a part outside of itself) ?
my override of onBeforeRender is secure from your
But the number of added panels needn't be the number of abstract section
(though it could).
-- stefan
Jan Kriesten wrote:
hi stefan,
And if somebody really needs 5 child areas, something else might be even
messier than the page's constructor. I rather think that 2, 3 or in rare
On Wed, Nov 07, 2007 at 07:14:01PM +0100, Korbinian Bachl wrote:
Given these subtle problems with this approach, I admit I'm warming to
the multiple extend/child idea.
im oposite - if i have X extends in a page, whose extend should be
preferred (e.g: manipulating the head or a part
i do see your point, but it is not that much different, its just another way
of doing stuff.
Markup inheritance does come from the border stuff. i think i was the one
that proposes it when
we had a meeting here now a few years ago here in Holland so that that we
could border pages.
Then Juergen
huh why would java code define the layout in this example?
you still have the html of the page that does the layout of those panels
and the content of those panels are layout with the markup of those panels.
Layout in java would be something like:
component.setSize()
component.setLayout()
johan
Well, if naming is your only concern, the attribute's name can easily be
replaced with something else than id ... e.g. name
wicket:abstract name=foo /
wicket:implement name=foo
some text
/wicket:implement
and remember that they can be optional as well:
wicket:abstract /
wicket:implement
some
I can see how wicket:abstract and wicket:implements tags could be
a nice enhancement to the current wicket:extend and wicket:child
tags. Do you have a working, or mostly working, patch?
-
To unsubscribe, e-mail: [EMAIL
Let me paste what I commented in WICKET-1134:
*I think this improvement is just more of a way to override components
declared in markups of a super class. Because this is what really happens.
Let's check your example:
In the BasePage, there are two fragments:
- subNavigation
- content
What
How can it get messy when it's not yet possible to do in wicket?
i believe it has been shown multiple times already that it CAN be done
with vanilla wicket...
I didn't like the look of any of those 'coded' solutions. They were not
from the coding elegance book I've read. They also mean I'm
a lot of people are saying that this can be implemented with panels,
and that is true. but actually implementing this with fragments will
make it look very similar to this new strategy and does not have the
id collission problem, because components ARE nested in two different
containers:
Thanks for giving the best overview of my thoughts Igor. Are you reading my
mind?
On Nov 7, 2007 3:50 PM, Igor Vaynberg [EMAIL PROTECTED] wrote:
let me weigh in with my thoughts on this.
a big problem with markup inheritance is the possibility of id collissions
for example
class
just a question: do i start to convince you? ;)
No... you are not... :D far far away from that
But don't take it personal, my opinion is technical... only!
On Nov 7, 2007 11:29 AM, Stefan Fußenegger [EMAIL PROTECTED]
wrote:
Well, if naming is your only concern, the attribute's name can
Presumably the coded work arounds that don't rely on child/extends mean
that the structural markup of each page is used instead of just that of
the base page - and that would spell maintenance issues. Without using
child/extend then ALL the structural markup in each page is used for
each render -
Korbinian Bachl wrote:
you missed solution3:
the real-wicket-way(tm) for multiple content-places in a tied page-area:
Whaaa, I seriously hope this is not the real-wicket-way! My brain hurts!
A framework is supposed to make things easy and readable! The code below
is just way too complicated
On Wed, Nov 07, 2007 at 11:31:12AM +0100, Mats Norén wrote:
Is the above statement really true considering that by adding abstract
methods to your page you defer the creation of the markup in just the
same way as the new proposed solution?
BasePage.java
public BasePage() {
thanks!
I think people become accustomed to how they used wicket up to now.
Therefore, they don't see this weakness as they worked around it countless
times. However, never change a running system isn't an argument to me ...
and it wasn't to the first guy who said that the wheel should be round
Korbinian Bachl wrote:
you missed solution3:
the real-wicket-way(tm) for multiple content-places in a tied
page-area:
Whaaa, I seriously hope this is not the real-wicket-way! My brain
hurts!
A framework is supposed to make things easy and readable! The code
below
is just way too
hi stefan,
And if somebody really needs 5 child areas, something else might be even
messier than the page's constructor. I rather think that 2, 3 or in rare
cases even 4 ids could make sense.
i must disagree - i have a basepage which defines the default layout on a
project, i.e. header,
From the Java-side, it isn't visible, whether a component will be placed in
whatever html part. So you add all components in the constructor, yes.
However, it's as messy as adding 5 components is right now ... they will
just be added at different places.
And if somebody really needs 5 child
hi johan,
Johan Compagner wrote:
1 thing that does bother me a bit (but maybe i have to do a deeper look
into
the patch) how do you separate
the components in the constructor of the sub page.. i guess you just add
all
the components over all the child fragments
in the page itself.
and in extending classes you can easily do this:
protected void initialize() {
addToAnything(new AnyPanel(id));
addToAnything(new AnyPanel2(id2));
}
So now you're proposing the Java code is defining the layout of
components? That's what the markup's job is I
ok tell me with 2 examples what is soo different about having 2 panels
(or
fragments)
in a page and implement that in a sub page or having 2 wicket childs
in a
page and implement those in a sub page.
Ok, here we go... (well one example at least - it's getting late here ;)
)
I'm not sure
you missed solution3:
the real-wicket-way(tm) for multiple content-places in a tied page-area:
eg: html:
...
div wicket:id=anythingPlace to put anything/div
...
java:
public abstract MyPage extends AnyPageExtendingWicketsWebPage {
private boolean initialized = false;
private
Yes!
see: https://issues.apache.org/jira/browse/WICKET-1134
-- stefan
Scott Swank wrote:
I can see how wicket:abstract and wicket:implements tags could be
a nice enhancement to the current wicket:extend and wicket:child
tags. Do you have a working, or mostly working, patch?
On Nov 7, 2007 11:19 AM, Scott Swank [EMAIL PROTECTED] wrote:
I can see how wicket:abstract and wicket:implements tags could be
a nice enhancement to the current wicket:extend and wicket:child
tags. Do you have a working, or mostly working, patch?
What I think we should do with this is make
Chris Colman schrieb:
The beauty of the multiple extend/child idea is that it's not a
completely new concept we're talking about here - it's merely an issue
of supporting n1 instead of arbitrarily fixing n=1 like it is now.
1 Question: Who dominates Who and Why?
If you extend 1 class by
John Krasnay wrote:
You've just illustrated one of the major problems with the
panel-from-a-subclass approach: it's easy to get it wrong. In your
example, addAbstract1 and addAbstract2 will be called in a class whose
constructor has not yet been called. Consider:
public DerivedPage extends
read my previous reply more carefuly, instead of
abstract Component getTemplateOne(String id);
you can simply do: Component getTemplateOne(String id) { return new
EmptyPanel(id); }
now you have a non-required override of any part of markup's template...
-igor
On Nov 7, 2007 10:51 AM, Chris
On Nov 7, 2007 11:22 AM, Chris Colman [EMAIL PROTECTED] wrote:
How can it get messy when it's not yet possible to do in wicket?
i believe it has been shown multiple times already that it CAN be done
with vanilla wicket...
I didn't like the look of any of those 'coded' solutions.
i dont
this cannot be an option. it always has to be enabled. if i write a
component that uses this and someone drops it into application where
this is disabled what should happen?
-igor
On Nov 7, 2007 1:05 PM, Eelco Hillenius [EMAIL PROTECTED] wrote:
On Nov 7, 2007 11:19 AM, Scott Swank [EMAIL
or you can just use a factory that lets you create transparent borders :)
-igor
On Nov 7, 2007 12:05 PM, Chris Colman [EMAIL PROTECTED] wrote:
Presumably the coded work arounds that don't rely on child/extends mean
that the structural markup of each page is used instead of just that of
the
On Nov 7, 2007 1:39 PM, Eelco Hillenius [EMAIL PROTECTED] wrote:
You wouldn't write such a component for general purposes obviously.
ok, that right there i really really dont like. define general
purpose? so now we have features in wicket that are guaranteed to
work and others that arent? this
On Nov 7, 2007 1:32 PM, Igor Vaynberg [EMAIL PROTECTED] wrote:
this cannot be an option. it always has to be enabled. if i write a
component that uses this and someone drops it into application where
this is disabled what should happen?
You wouldn't write such a component for general purposes
On Nov 7, 2007 2:02 PM, Igor Vaynberg [EMAIL PROTECTED] wrote:
On Nov 7, 2007 1:39 PM, Eelco Hillenius [EMAIL PROTECTED] wrote:
You wouldn't write such a component for general purposes obviously.
ok, that right there i really really dont like. define general
purpose? so now we have features
Hi Chris,
i rewinded some part of your idea and the thread and now see bit clearer
what you want - perhaps you shouldnt call i multiple extend/child but
more precisely inheritance with multiple areas as you go:
html-basepage:
...
extend id=foo /
extend id=faa /
wicket:child/
what do we need to refactor to make a plugin like this possible?
-igor
On Nov 7, 2007 2:50 PM, Eelco Hillenius [EMAIL PROTECTED] wrote:
some here like it and others dont like it, so wouldnt be an different
project like wicket-extension the part for this?
That's what I'm arguing. Though
just a question to you Igor and Eelco:
some here like it and others dont like it, so wouldnt be an different
project like wicket-extension the part for this? couldn't this be
applied similar to the wicket-jmx plugin where you just dump the jar
into the classpath and have it registering and
some here like it and others dont like it, so wouldnt be an different
project like wicket-extension the part for this?
That's what I'm arguing. Though thinking about it a little bit longer,
it should probably not even be a core project, but rather a
wicket-stuff one.
couldn't this be
applied
Hi,
I haven't really heard any real arguments against this patch. Basically
it's just relaxing a constraint on the current implementation of
child/extend. It's not so much a new feature as improving the current
feature. I am honestly interested in why people are so against it.
Igor Vaynberg
heh, wellyou can be against this, but i think if we take a vote
right now most core-devs with binding votes will vote this down
I still can't see the reason for the negativity of some of the
core-devs: this is an existing feature.
If the feature sucks so bad why did people have the
Chris Colman wrote:
heh, wellyou can be against this, but i think if we take a vote
right now most core-devs with binding votes will vote this down
I still can't see the reason for the negativity of some of the
core-devs: this is an existing feature.
No offense to anyone involved,
Wouldn't this essentially be the same as using wicket:panel
id=header/ and using WebMarkupContainers on the java side?
I.e.:
Base
Structural markup goes here (see below for explanation of this)
wicket:panel id=header /
More structural markup goes here
wicket:panel id=body /
And
I totally agree with you, having named extension points would be perfect.
However, I am trying to do a quick proof of concept that can be discussed
before I implement all those nice and shiny features. Hopefully this
prototype convinces some of those sceptics out there ;)
I think the anyone
Wouldn't this essentially be the same as using wicket:panel
id=header/ and using WebMarkupContainers on the java side?
yes it would be exactly the same thing.
On Tue, Nov 06, 2007 at 10:23:26PM +1100, Chris Colman wrote:
In the panel example you give you must still provide all of the
structural markup surrounding your panel tags in EVERY page's markup in
your system and if you decide to make a system wide change of this
structural markup you must
The proposed extension would just lead to more convenience, as it saves us
from having to create child pages as page/panel pairs when their are 2
panels needed (assuming no inheritance at all)
John Krasnay wrote:
On Tue, Nov 06, 2007 at 10:23:26PM +1100, Chris Colman wrote:
In the panel
I posted a new message in Wicket - Dev:
http://www.nabble.com/Patch%3A-Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4759260.html
It contains a patch that demonstrates the discussed enhancement. Please
comment!
-- stefan
Stefan Fußenegger wrote:
Hi folks,
I just stumbled
In our app we have a ListView into which we can dump panels for, in
our case, various different filtering options depending on the page.
The base page keeps a List and that's used as the model for the
ListView. If the subclass doesn't add anything, nothing shows up.
But the pages that need them
How would be the Java classes, if multiple wicket:child were supported?!
wicket:extend and wicket:child were build under the base concept of OOP's
inheritance.
looks weird to me. :D
On Nov 4, 2007 9:29 PM, Johan Compagner [EMAIL PROTECTED] wrote:
The only requirement would be that if you do
yes i agree,
i dont think we will change the extend-child 1 on 1 relationship. (thats
just design by inheritance)
what some others want is just do it by composition and that is perfectly
possible by using panels.
And you can mix the 2 just fine.
So
Base.java/Base.html - extend -
Stefan, try first giving us an example of what would you like to do. What I
can see is that you want this:
BasePage.html
html
body
h1BasePage/h1
hr/
h3This is my child:/h3
wicket:child /
hr/
h3This is my OTHER child:/h3
wicket:child /
/body
/html
** Example of a
Well, what I'd like to do is what I explained in my first post. One would
still have a one-one-relationship if it comes to files (Base.html, Base.java
- Sub.html, Sub.java). However, a Base.html might contain more than one
wicket:extend /. So this no longer an exact duplicate of the parent-child
this is done in MarkupCache i believe. when you load a markup file
that has wicket:extend it traverses up the hierarchy and merges all
the markup.
-igor
On 11/5/07, Stefan Fußenegger [EMAIL PROTECTED] wrote:
Eelco Hillenius wrote:
It would be quite feasible to add support for multiple
if i were you i would use tags other then extend and child just so you
dont conflict.
-igor
On 11/5/07, Stefan Fußenegger [EMAIL PROTECTED] wrote:
Well, what I'd like to do is what I explained in my first post. One would
still have a one-one-relationship if it comes to files (Base.html,
thanks for that advise.
hey chris, keep your fingers crossed. finally you could get your
wicket:abstract-wicket:override ;)
stefan
igor.vaynberg wrote:
if i were you i would use tags other then extend and child just so you
dont conflict.
-igor
On 11/5/07, Stefan Fußenegger [EMAIL
the complement to abstract is implement not override... names are important.
-igor
On 11/5/07, Stefan Fußenegger [EMAIL PROTECTED] wrote:
thanks for that advise.
hey chris, keep your fingers crossed. finally you could get your
wicket:abstract-wicket:override ;)
stefan
igor.vaynberg
well, i thought chris' suggestion to use abstract and override in order to
align it with the java keyword/annotation. I don't care whether it is
implement or override (but yes, names are important). i think i'll go for
implement though ... but if it finally becomes part of wicket, it will
become
On 11/5/07, Stefan Fußenegger [EMAIL PROTECTED] wrote:
well, i thought chris' suggestion to use abstract and override in order to
align it with the java keyword/annotation. I don't care whether it is
implement or override (but yes, names are important). i think i'll go for
implement though
but why choose another name? as long as there is only one pair of however
named tags, the behaviour wouldn't change at all. It would only extend the
current functionality for those who place a second extension point in there
html files.
But I am not in the core team, but curious to look under
if i were you i would use tags other then extend and child just so you
dont conflict.
Yes Stefan, I would think that would be a better approach to use a new set of
tags. It also allows you to choose more correct naming (because inheritance
isn't actually a parent/child relationship so the
the complement to abstract is implement not override... names are
important.
Arh, sorry, I made my last post before reading yours Igor. Yes, I agree
abstract/implement make a great complimentary pair.
-
To unsubscribe,
The only requirement would be that if you do choose to support multiple
abstract/overridden sections you would need to provide identifiers (just
like an abstract method has a name) so that the 'compiler' (wicket)
knows which section in a superclass an extended class section is
overriding. In
this has been discussed multiple times on this list, search the
archives. the conclusion has always been that what you want can be
accomplished by factory methods on the basepage that generate panels.
-igor
On 11/2/07, Stefan Fußenegger [EMAIL PROTECTED] wrote:
Hi folks,
I just stumbled on
Thanks for that awesomely fast reply!
I found an excellent thread in the archives that explains this topic very
well - I swear I searched before, but obviously with the wrong keywords ;)
http://www.nabble.com/Multiple-wicket%3Achild-tags-in-the-same-page-tf3775143.html
To sum it up for those
I found an excellent thread in the archives that explains this topic
very
well - I swear I searched before, but obviously with the wrong
keywords ;)
http://www.nabble.com/Multiple-wicket%3Achild-tags-in-the-same-page-tf37
75143.html
Multiple child/extends pairs (where you have to see such a
It would be quite feasible to add support for multiple overridden
sections using the above tag names while remaining backwards compatible
with existing markup by continuing to support the old child/extends
tags working the way they always have.
It's kind of a predictable answer, but the best
It would be quite feasible to add support for multiple overridden
sections using the above tag names while remaining backwards
compatible
with existing markup by continuing to support the old
child/extends
tags working the way they always have.
It's kind of a predictable answer, but the
There's nothing I would love more right now than to have to time to
implement a patch to support multiple overridden sections in a wicket
page but unfortunately time is one thing I don't seem to have much of
these days. I can't believe 2007 is almost over - heck, where did this
year go?
Tell
There's nothing I would love more right now than to have to time to
implement a patch to support multiple overridden sections in a
wicket
page but unfortunately time is one thing I don't seem to have much
of
these days. I can't believe 2007 is almost over - heck, where did
this
year go?
83 matches
Mail list logo
