Implemented for 1.3 (see
http://issues.apache.org/jira/browse/WICKET-169), and added a simple
example that shows this to wicket-examples of that branch (in
FormInput, component Multiply).
Tbd for 2.0 (http://issues.apache.org/jira/browse/WICKET-170) would be
very grateful if someone else could p
With discussed it from day 1... did we ever get a resolution though?
Did any ever do a solid proposal other then 'lets work with interfaces
instead'?
:)
Eelco
On 12/14/06, Johan Compagner <[EMAIL PROTECTED]> wrote:
Didn't we already discuss such an interface before for 2.0?
I get a major déjà
Didn't we already discuss such an interface before for 2.0?
I get a major déjà vu.
johan
On 12/14/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
> > But in
> > future versions, it would be great if you could achieve the same
> > through mixing in rather than extending.
>
>
> my point was that
k
Eelco
On 12/13/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
i am just clarifying, what you said couldve been taken either way
-igor
On 12/13/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
>
> > > But in
> > > future versions, it would be great if you could achieve the same
> > > through mix
i am just clarifying, what you said couldve been taken either way
-igor
On 12/13/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
> > But in
> > future versions, it would be great if you could achieve the same
> > through mixing in rather than extending.
>
>
> my point was that it is the formcom
> But in
> future versions, it would be great if you could achieve the same
> through mixing in rather than extending.
my point was that it is the formcomponent that should be mixed into the
panel and absolutely not the other way around
Do we think in different directions? What I meant is that
On 12/13/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
But in
future versions, it would be great if you could achieve the same
through mixing in rather than extending.
my point was that it is the formcomponent that should be mixed into the
panel and absolutely not the other way around
-igor
for now i accept eelco's hack only because i
think it is a necessity at this point in time.
Exactly. Imo, we need something like FormComponentPanel in 1.3/ 2.0
sooner rather than later. In the past I've had a couple of times where
I just spent too much time trying to work in other ways, while th
this is all heading down a very very slippery slope and i dont like it one
bit. right now we have clear definition of what is what and how things work.
the only usecase that keeps coming up is for simple wrappers around existing
form components when they are used to dynamically generate forms. do
> hmm i do like to separate the components with its own markup and the onces
> that dont
>
> johan
>
I would say the division should be different. Component which needs markup
(markup is provided either by parent component or is their own) and the
ones that don't. Would be very nice if you can eas
> I agree with that remark, and like the idea of components attaching to
> markupfiles whatever kind of component they are. However, what we'd
> gain in flexibility by getting rid of Panel (hypothetically), we'd
> loose in clarity. If you wouldn't explicitly instantiate a panel that
> matches marku
hmm i do like to separate the components with its own markup and the onces
that dont
johan
On 12/13/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
I agree with that remark, and like the idea of components attaching to
markupfiles whatever kind of component they are. However, what we'd
gain in
I agree with that remark, and like the idea of components attaching to
markupfiles whatever kind of component they are. However, what we'd
gain in flexibility by getting rid of Panel (hypothetically), we'd
loose in clarity. If you wouldn't explicitly instantiate a panel that
matches markup, how wo
> On 11/29/06, Johan Compagner <[EMAIL PROTECTED]> wrote:
>> what makes a formcomponent a formcomponent?
>
> That, of course, is the main question :) But not an easy one,
> certainly not to extract a robust interface from it. The component
> like I proposed (but that should have the header stuff in
On 11/29/06, Johan Compagner <[EMAIL PROTECTED]> wrote:
what makes a formcomponent a formcomponent?
That, of course, is the main question :) But not an easy one,
certainly not to extract a robust interface from it. The component
like I proposed (but that should have the header stuff included) w
:)
On 11/29/06, Johan Compagner <[EMAIL PROTECTED]> wrote:
what makes a formcomponent a formcomponent?
If we can extract this info really easy in a interface then that is fine
by
me.
But should that interface impl always be a wicket component? Because then
component also must be an interface?
what makes a formcomponent a formcomponent?
If we can extract this info really easy in a interface then that is fine by
me.
But should that interface impl always be a wicket component? Because then
component also must be an interface?
johan
On 11/29/06, Eelco Hillenius <[EMAIL PROTECTED]> wrot
I only recently put the logic back into
WebMarkupContainerWithAssociatedMarkup. It is easy to put it into a
utlity class.
Juergen
On 11/29/06, Joni Freeman <[EMAIL PROTECTED]> wrote:
On Tue, 2006-11-28 at 21:24 -0800, Eelco Hillenius wrote:
> I've got around the fact that I can't do multiple in
On Tue, 2006-11-28 at 21:24 -0800, Eelco Hillenius wrote:
> I've got around the fact that I can't do multiple inheritance to
> combine a component that is both a panel and a form component (or at
> least acts as one) in many ways now, but I really think we need to
> have a ready-to-use component fo
I've got around the fact that I can't do multiple inheritance to
combine a component that is both a panel and a form component (or at
least acts as one) in many ways now, but I really think we need to
have a ready-to-use component for this now.
This would be the simplified version:
public class
20 matches
Mail list logo
